Why Deliverability Matters to Me

Welcome to deliverability week. I want to especially thank Al for doing a lot of work behind the scenes herding this group of cats. He’s an invaluable asset to the community.

The topic today is why deliverability matters to me. Until I started writing this, I hadn’t really thought about it much. Like most folks, I kinda fell into deliverability. I still describe myself as a scientist by training.

I think that to figure out why it matters, I need to start at the beginning and talk about the impact of email on my life and at why email matters to me. Email matters because it’s a communication tool and introduced me to thousands of people I would have never been able to interact with. Deliverability matters because it’s the key to keeping email as a viable and practical communication tool.

Ancient History (pre-2000)

My first job out of high school was interning in a molecular biology research lab at the FDA on Capitol Hill. That was where I had my first exposure to BITNET and then later the Internet. My interest in email actually started then. My boyfriend at the time stayed down in Blackburg for the summer, while I was up in DC. We tried to email each other, but couldn’t.

When I moved to grad school, I got a non .gov email address. When I got my first spam, sometime in 94 or 95, I used tracking spammers down as a way to understand email and learn about the internet. Throughout the 90s fighting spam was a hobby I did between experiments. I started participating in the news.admin.net-abuse USENET groups, anti-spam mailing lists like spam-l and some anti-spam related IRC channels. Many of the folks I met then are still friends and colleagues – including Al. This is also where Steve and I met even though we were living and working in two different time zones.

By 2000 Steve and I were married and living in California where he was working for UltraDNS. I was looking for jobs in the booming Bay Area biotech scene, but couldn’t find quite the right position. After a few months some of the other folks I met on USENET were working for MAPS and recruiting me to come work with them.

The job that really interested me was not on the blocklist side of things, but rather the education and compliance side of things. We were the carrot backed up by the blocklist stick. My first position there was managing a team of folks handling abuse complaints for a major network provider. As the company grew, I moved over to head up client services. I was tasked with developing an outsourced abuse desk product for MAPS to sell to third parties. I’d just made our first sale back in early 2001 when the company laid off most of us not on the blocklist side of things.

The start (early 00’s)

I mentioned Steve was working at UltraDNS at the time. The company was founded by Rodney Joffe who I talked about when he won the Mary Litynski Award. He started recommending me to his friends and colleagues to help them solve their MAPS blocklisting problems.

Deliverability wasn’t really a thing when I started consulting for companies. Mostly I would go into a company and look at their processes and explain to them how to comply with MAPS requirements to get delisted. It wasn’t about inbox or not inbox. It was solving the immediate blocking problem.

Spam filters were very primitive. They blocked by IPs and sometimes domains. There were the vague beginnings of spam folders at some mailbox providers, but they weren’t what we think of today. People were still manually writing rules to block spam.

The infrastructure we now rely on for deliverability just didn’t exist.

  • FBLs didn’t exist.
  • Gmail didn’t exist
  • Authentication didn’t exist.
  • CAN SPAM didn’t exist.
  • Report Spam buttons didn’t exist.
  • Best Practice recommendations consisted of “use confirmed opt-in”.

We were all flying by the seat of our pants and trying to navigate wholly unknown terrain. We were fighting to preserve an email ecosystem without the tools or the knowledge or the community that we have today.

What it means to me

At the end of the day, I still consider myself an anti-spammer. What I do is all about stopping spam. Many of those USENET colleagues and friends ended up founding or building filtering companies. Others work for blocklists or abuse or postmaster desks. I took a different path. Instead of going down the blocking route, I stayed on the side of the carrot. My anti-spam work is teaching companies ways to send email that are respectful of the recipient. They can make money from an opt-in model and they can be effective even if they’re not blasting out email to every address they can find.

To me, email is magical. It gave me a way to get to know and connect with people I would otherwise never have met. It let me continue relationships that spanned the globe. I’ve gotten multiple jobs due to the relationships I’ve created through email. My first post-grad school research job was for someone I met on an discussion list. My job at MAPS was definitely due to my online activities. I even met the guy I’ve been married to for 25 years (this July!) because of email and specifically spam.

Email is special. Email deserves to be protected because it’s valuable. It’s important. Filters and blocklists have their place. But someone needs to be the carrot. Someone needs to show marketers and companies how to use email non-destructively. How to make email work for everyone. That’s the path I chose so long ago when MAPS was courting me. It’s the path I’ve traveled for years now. It’s a path I’m proud of.

Deliverability is important because we are the protectors and the caretakers of the email ecosystem.

Related Posts

Troubleshooting delivery is hard, but doable

Even for those of us who’ve been around for a while, and who have a lot of experience troubleshooting delivery problems things are getting harder. It used to be we could identify some thing about an email and if that thing was removed then the email would get to the inbox. Often this was a domain or a URL in the message that was triggering bulk foldering.
Filters aren’t so simple now. And we can’t just randomly send a list of URLs to a test account and discover which URL is causing the problem. Sure, one of the URLs could be the issue, but that’s typically in context with other things. It’s rare that I can identify the bad URLs sending mail through my own server these days.
There are also a lot more “hey, help” questions on some of the deliverability mailing lists. Most of these questions are sticky problems that don’t map well onto IP or domain reputation.
One of my long term clients recently had a bad mail that caused some warnings at Gmail.
We tried a couple of different things to try and isolate the problem, but never could discover what was triggering the warnings. Even more importantly, we weren’t getting the same results for identical tests done hours apart. After about 3 days, all the warnings went away and all their mail was back in the inbox.
It seemed that one mailing was really bad and resulted in a bad reputation, temporarily. But as the client fixed the problem and kept mailing their reputation recovered.
Deliverability troubleshooting is complicated and this flowchart sums up what it’s like.

Here at Word to the Wise, we get a lot of clients who have gone through the troubleshooting available through their ESPs and sometimes even other deliverability consultants. We get the tough cases that aren’t easy to figure out.
What we do is start from the beginning. First thing is to confirm that there aren’t technical problems, and generally we’ll find some minor problems that should be fixed, but aren’t enough to cause delivery problems. Then we look at the client’s data. How do they collect it? How do they maintain it? What are they doing that allows false addresses on their list?
Once we have a feel for their data processes, we move on to how do we fix those processes. What can we do to collect better, cleaner data in the future? How can we improve their processes so all their recipients tell the ISP that this is wanted mail?
The challenging part is what to do with existing data, but we work with clients individually to make sure that bad addresses are expunged and good addresses are kept.
Our solutions aren’t simple. They’re not easy. But for clients who listen to us and implement our recommendations it’s worth it. Their mail gets into the inbox and deliverability becomes a solved problem.

Read More

The Case of the 500-mile Email

I stumbled across this story again this morning, and it’s such a lovely delivery yarn I thought I’d share it.

Read More

Want some history?

I was doing some research today for an article I’m working on. The research led me to a San Francisco Law Review article from 2001 written by David E. Sorkin. Technical and Legal Approaches to Unsolicited Electronic Mail (.pdf link). The text itself is a little outdated, although not as much as I expected. There’s quite a good discussion of various ways to control spam, most of which are still true and even relevant.

From a historical perspective, the footnotes are the real meat of the document. Professor Sorkin discusses many different cases that together establish the rights of ISPs to filter mail, some of which I wasn’t aware of. He also includes links to then-current news articles about filtering and spam. He also mentions different websites and articles written by colleagues and friends from ‘back in the day’ discussing spam on a more theoretical level.
CNET articles on spam and filtering was heavily referenced by Professor Sorkin. One describes the first Yahoo spam folder. Some things never change, such as Yahoo representatives refusing to discuss how their system works. There were other articles discussing Hotmail deploying the MAPS RBL (now a part of Trend Micro) and then adding additional filters into the mix a few weeks later.
We were all a little naive back then. We thought the volumes of email and spam were out of control. One article investigated the effectiveness of filters at Yahoo and Hotmail, and quoted a user who said the filters were working well.

Read More