Reading between the lines

Reading between the lines an important skill in deliverability.
Why? Over the last few years there’s been an increasing amount of collaboration between deliverability folks at ESPs and ISPs. This is great. It’s a vast improvement on how things were 10 years ago. However, there are still ongoing complaints from both sides. There probably always will be. And it’s not like a blog post from me is going to fix anything. But I see value in talking a bit about how we can improve our ability to collaborate with one another.

Can’t say officially

When we’re addressing deliverability issues, we’re often dealing with representatives of large corporate entities. Most of the widely used filters and blocklists are subsidiaries of large companies. The big exception is Spamhaus, but even they have rules and processes on releasing data.  Every participant in the conversation has internal processes and directives to follow.
In some cases an employee is not authorized to release information even though that information isn’t secret or private. We often have meetings, where some employees are sharing data about how filters work without their PR department approving every bit of the statement. A few years ago I asked someone who’d just finished on a panel if the information they shared could be shared outside the room. They looked me in the eye and said, “I really wish you wouldn’t ask me that, as I have to then go talk to people if you do.”
OK. Message Received. Loud and Clear.
This is only one example, in a long line of examples, where ISP reps have made statements about their systems without direct attribution. I’m sure astute readers read between my lines in these kinds of cases.

Lawyers are involved

Twenty years ago, when I first started fighting spam, there was a community of folks who fought spam. Many of them, like me, started because we were trying to defend our inboxes. Other folks in the community actually handled abuse@ for some of the ISPs. Brian Williams wrote about a lot of the personalities in Spam Kings. There wasn’t anything called deliverability then. There weren’t postmaster pages and FBLs. We were just a group of people trying to fight spam and protect our mailboxes.
Things are significantly different now. Filtering is a formal part of ISP product development. Twenty years of case history proves filtering is legal, but some folks will still sue for filtering. How an ISP communicates their filtering has legal implications. Thus, the lawyers stepped in.
In practical terms the legal oversight restrains responses. I know that legal teams participate in complaint and customer handling processes a ESPs and ISPs. There is a process and process must be followed. In some companies, legal approves communications individually. In other companies they dictate language and boilerplates.
Legal oversight means we sometimes have to read between the lines on boilerplates and responses. The ISP reps may not be able to give us the actual information, but they may also drop broad hints that can lead us to the right solution. Sometimes the boilerplates specifically say things like “we see no problems with your mail delivery.” Often senders read this and wonder why the mail is going to bulk. Deliverability experts must read between the lines and know this means more work to get to the inbox.

Privacy policies apply

Sharing customer information is a violation of most privacy policies. This includes an abuse desk explaining the actions taken against a customer. Back in the community era, abuse@ often sent personal replies to complaints. One abuse person, in particular, was famous for entertaining descriptions of how the spammer was handled. There’s no way they could do this now. I kinda miss the community, but the change reflects how critical the Internet is and how important it for commercial use.
As abuse@ I often dealt with complainants who asked for the full legal information of a customer. I know that current abuse@ reps still get those requests. I couldn’t, and they can’t, give out customer information to third parties. In many cases this is good, we don’t want random employees deciding that customer privacy isn’t important. Doxxing is an issue and is a problem, and we don’t want to contribute to that. On the other hand, when I’m vetting a customer, contact data and history are useful bits of information.
The struggle between sharing warnings and protecting customer privacy is real. Many of us in the deliverability and abuse spaces are good at leaving hints and bread crumbs. If a company or spammer comes up in discussion we might find a couple public sources of information and share them. We have to write between the lines, as well as read between them.

Silence is an answer

The biggest challenge with reading between the lines is when there are no lines, when there is no answer at all. Silence is an answer. Actually, silence is many answers, depending on context.
For instance, sometimes the answer is no. The ISP can’t provide all the information you’re asking for, so they just don’t answer at all. It’s a defensive mechanism. Too many people think a no answer is the start of a negotiation. It’s not.
In other cases the asker has worn out their welcome. What typically happens is a client demands specifics and the deliverability rep reaches out. The client keeps pushing back on deliverability. Deliverability keeps reaching out to the ISP. Eventually, the ISP doesn’t answer. No one is happy. The client’s upset. Deliverability is stuck. The ISP is irritated.
Silence happens to me, as well. Clients want to hear the problems and solutions directly from the ISP or filtering company. But if the ISP isn’t answering, it’s my job to interpret that silence. I contextualize the lack of a response and provide action items for the client.

It’s a skill

Reading between the lines is a skill we can all learn. It’s also something we need to practice regularly. This post doesn’t cover all the ways we speak in code to each other. But I hope it helps readers realize how critical it is in our industry.

Related Posts

You can't always get what you want

It’s a problem anyone who has done any delivery work has faced. There’s a client who is having blocklist problems or ISP delivery problems and they won’t pay any attention to what you say. They insist that you talk to the blocklist or the ISP or hand over contacts directly so they can “dialog with” someone internally. They don’t like what they’re hearing, and they hope that the answer will be different if they find a new person to talk to.
The reality is many of the people at ISPs and blocklists don’t want to talk to these types of senders. They may answer a friendly question from someone they know and trust, but sometimes not even then.
Some very large ISPs and major blocklists don’t even take sender questions. They won’t communicate with anyone about any delivery issues.
I’ve had to tell more than a few clients recently that various ISPs and blocklists weren’t interested in helping those clients with their delivery problems. There are two classes of reactions I get from clients. Some clients focus on moving forward. “OK, now what? How can we identify the issue, what data do we have and how can we figure out what the problem is?”
Other clients continue to look for ways to talk to whomever is blocking their mail. They’re convinced if they can just “explain their business model” or be told what they’re doing wrong, that all their delivery problems will magically disappear.
Needless to say those clients who focus on moving forward and looking at the information they do have have much better success resolving their delivery problems. What many senders don’t understand is the wealth of data they have that will help them resolve the issue. And even if they know it’s buried in their files, they don’t always know where to start looking or even what they’re looking for.
But that is, of course, why you hire someone like me who understands spamfiltering and email. I help senders understand how email filters work and identify what parts of their programs are likely to be responsible for delivery issues. I often find the most valuable service I provide to clients is a fresh set of eyes that can see the forest. With my help, they manage to stop obsessing unproductively about one particular symptom and focus on the underlying problems.
Senders who think the holy grail of problem resolution is speaking to the right person at an ISP or blocklist generally are disappointed, even when they hire someone who knows all the right people at the ISPs.  They can’t always get what they want. But I can often help them get what they need.
 
 
 

Read More

iOS List Unsubscribe Functionality

Al did a great post over on Spamresource about the how the new list unsubscribe function in the default mail client from iOS10. What’s been interesting to me is how much I’m hearing from ESP folks about how their customers want it gone.
If you don’t know what we’re talking about, in the default mail client on iOS10, Apple is now offering a way to unsubscribe from list mail by placing an unsubscribe link at the top of the message.
ListUnsub
As you can see, this isn’t just for commercial mail, it’s in place for every mailing list that has a List-Unsubscribe header. (This is a screenshot from something I posted to OI this morning). For me, it’s somewhat intrusive. I’m on a lot of discussion lists – technical, marketing, business and even a couple social ones. Reading them on my phone has become a challenge, as every email in a thread contains the “unsubscribe” button now.
Luckily, you can dismiss the message for all posts to that mailing list by hitting the ⮾⮾⮾⮾x. Interestingly, once you’ve turned it off there seems to be no way to turn it back on for that list.
Senders have different complaints, however, they do not have to do with intrusiveness or usability issues.
I’ve heard complaints about placement and about how easy it makes it to unsubscribe. One person even stated that everyone knows the place for an unsubscribe is at the bottom of a message and it should never be at the top of a message. I find these arguments unpersuasive. Unsubscribing should be easy. Unsubscribing should be trivial. People should be able to stop getting mail on a whim. Particularly here in the US, where unsolicited mail is legal, being able to quickly opt-out is the only thing keeping some of our mailboxes useful.
I’ve also heard some concerns that are a little more understandable. One company was concerned that unsubscribes go directly to their ESP rather than directly to them. This is a somewhat more understandable concern. Good senders use unsubscribes as part of their KPIs and as part of their campaign metrics. They know how much an unsubscribe costs them and will use that as part of their metrics for defining a successful campaign. Still, though, it’s not that big a concern. ESPs are already handling these kinds of unsubscribes from providers like gmail and hotmail.
Almost 7 years ago I blogged about a sender who wanted an unsubscribe link in the email client. It was a bit of snark on my part. The interesting part, though, is that some senders want unsubscribe mediated in the client and others things it’s horrible. I think this tells me that there’s no universal right answer. It Depends might be the most hated statement in deliverability, but it is the absolutely the reality of the situation.
 
 

Read More

Naming Names

One of the things that regularly happens at email conferences is a bunch of representatives from various ISPs and sometimes deliverability companies get up on stage and entertain questions from the audience about how to get email to the inbox. I’ve sat in many of these sessions – on both sides of the stage. The questions are completely predictable.
Almost invariably, someone asks if they can quote the ISP representative, because there is this belief that if you connect a statement with an employee name that will give the statement more weight. Except it doesn’t really. People who aren’t going to listen to the advice won’t listen to it even if there are names attached.
A lot of what I publish here is based on things the ISP reps have said. In some cases the reps actually review and comment on the post before I publish it. I don’t really believe attaching names to these posts will make them any more accurate. In fact, it will decrease the amount of information I can share and will increase the amount of time it takes to get posts out.
Last night I was joking with some folks that I should just make up names for attribution. Al did that many years ago, coining the pseudonym Barry for ISP reps. Even better, many of the ISP employees adopted Barry personas and used them to participate in different online spaces. Barry A. says X.  Barry B. says Y.  Barry C. says W. Barry D.
It doesn’t matter what names I attach.
I think I’m going to start adding this disclaimer to the appropriate blog posts:
Any resemblance to persons living or dead should be plainly apparent to them and those that know them. All events described herein actually happened, though on occasion the author has taken certain, very small, liberties with narrative.
Because, really.
 

Read More