Reading between the lines

laura
Industry
July 1, 2017

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.

How many blocklists do we need?

There’s been a discussion on the mailop list about the number of different blocklists out there. There are discussions about whether we need so many lists, and how difficult the different lists make it to run a small mail system (80K or so users). This discussion wandered around a little bit, but started me thinking about how we got to a place where there are hundreds of different blocklists, and why we need them.

There is a lot of history of blocklists, and it’s long, complicated and involves many strong and passionate personalities. Some of that history is quite personal to me. Not only do I remember email before spam, I was one of MAPS’ first few employees, albeit not handling listings. I’ve talked with folks creating lists, I’ve argued with folks running lists. For a while I was the voice behind a blocklist’s phone number.
The need, desire and demand for different lists has come up over the years. The answer is pretty simple: there are many different types of abuse. One list cannot effectively address all abusive traffic nor have policies that minimize false positives.
Lists need different policies and different delisting criteria. The SBL lists based on volume of email to addresses that are known to have not opted in to receive mail. The PBL lists IPs where the IP owner (usually an ISP) says that the IPs are not supposed to be sending mail by their policy. URIBL and SURBL list domains, not IPs. Some lists have delisting requirements, some let listees remove themselves.
The policies of listing and delisting are not one size fits all, nor should they be.
There are two widely used lists that have significantly different delisting policies: the SBL and the CBL.
The SBL focuses on IP addresses they believe are under the control of or supporting the services of spammers. They measure this by primarily relying on spamtraps, but they also accept forwarded mail from some trusted individuals. Getting delisted from the SBL means explaining to Spamhaus what steps were taken to stop the spam from coming. It’s a manual process with humans in the loop and can require significant business process changes for listees. (We’ve helped dozens of companies resolve SBL listings over the years, contact us if you need help.)
On the other hand, the CBL is a mostly automated list. It lists ources of mail that aren’t real mail servers sending real mail, but are sending a lot of stuff. As they describe it:

January 2017: The Month in Email

Between client work and our national political climate, it’s been a very busy month around here and blogging has been light. Things show no sign of slowing down in February, so we’d love to hear from you with questions and suggestions of what you’d most like to see us focus on in our limited blogging time this month. We got a great question about how senders can access their Google Postmaster tools, and I wrote up a guide that you might find useful.

We’re also revisiting some older posts on often-requested topics, such as spamtraps, so feel free to comment below if there are topics you’d like us to address or update. One topic that comes up frequently, both on the blog and in our consulting practice, is about what to do when you’re on a blocklist. I revisited an old-but-still-relevant post on that topic as well.
On the Best Practices front, I wrote about how brands can use multiple channels to connect with customers and prospective customers to promote and enhance email delivery. I also took a moment to look back over 2016 and forward to 2017 in the realm of email security.
I continue to be annoyed by B2B spam, and have started responding to those “requests” for my time directly. Steve also wrote a long post about B2B spam, focusing on how these spammers are using Google and Amazon to try to work around reputation issues.
In case you missed it, I contributed some thoughts to a discussion on 2017 email trends over at Freshmail with my exhortation to “Make 2017 the year you turn deliverability into a KPI.”
I’m also still in the process of completing my 2017 speaking schedule, so I’m looking for any can’t-miss conferences and events you’d recommend. Thanks for keeping in touch!

Purchased lists aren't always purchased

Spamhaus has listed a number of domains belonging to French politicians recently. In their blog post about it, they mention that the listings are directly related to address lists provided to candidates by the French government.