Recent Posts

Timeliness of email

There’s been an interesting discussion in the comments from yesterday’s post about temp failing. My position is that email is not a 100% reliable medium for transmitting time sensitive information.
Two things happened today to reinforce that.

20% of email doesn't make it to the inbox

Return Path released their global delivery report for the second half of 2009. To put together the report, they look at mail delivery to the Mailbox Monitor accounts at 131 different ISPs for 600,000+ sends. In the US, 20% of the email sent by Mailbox Monitor customers to Return Path seed accounts doesn’t make it to the inbox. In fact, 16% of the email just disappears.
I’ve blogged in the past about previous Return Path deliverability studies. The recommendations and comments in those previous posts still apply. Senders must pay attention to engagement, permission, complaints and other policy issues. But none of those things really explain why email is missing.
Why is so much mail disappearing? It doesn’t match with the philosophy of the ISPs. Most ISPs do their best to deliver email that they accept and I don’t really expect that ISPs are starting to hard block so many Return Path customers in the middle of a send. The real clue came looking at the Yahoo numbers. Yahoo is one of those ISPs that does not delete mail they have accepted, but does slow down senders. Other ISPs are following Yahoo’s lead and using temporary failures as a way to regulate and limit email sent by senders with poor to inadequate reputations. They aren’t blocking the senders outright, but they are issuing lots of 4xx “come back later” messages.
What is supposed to happen when an ISP issues a 4xx message during the SMTP transaction is that email should be queued and retried. Modern bulk MTAs (MessageSystems, Port25, Strongmail) allow senders to fine tune bounce handling, and designate how many times an email is retried, even allowing no retries on a temporary failure.
What if the missing mail is a result of senders aggressively handling 4xx messages? Some of the companies I’ve consulted for delete email addresses from mailing lists after 2 or 3 4xx responses. Other companies only retry for 12 – 24 hours and then the email is treated as hard bounced.
Return Path is reporting this as a delivery failure, and the tone of discussion I’m seeing seems to be blaming ISPs for overly aggressive spamfiltering. I don’t really think it’s entirely an ISP problem, though. I think it is indicative of poor practices on the part of senders. Not just the obvious permission and engagement issues that many senders deal with, but also poor policy on handling bounces. Perhaps the policy is fine, but the implementation doesn’t reflect the stated policy. Maybe they’re relying on defaults from their MTA vendor.
In any case, this is yet another example of how senders are in control of their delivery problems. Better bounce handling for temporary failures would lower the amount of email that never makes it to the ISP. This isn’t sufficient for 100% inbox placement, but if the email is never handed off to the ISP it is impossible for that email to make it to the inbox.

iContact lists compromised

iContact has acknowledged that (some) of their customer lists were compromised and that they are investigating. As iContact has chosen not to allow comments on that post, feel free to share comments here.
HT: @aliverson

Delivery reference site

Over the years I’ve picked up a lot of useful and relevant information about email delivery. I’ve shared a lot of information here on the blog, and while that’s great, a blog is not a great format for a reference. The ISP information page was an initial pass at creating a reference. I realized that just linking to the ISP provided information didn’t communicate very much about how to deliver email even to those ISPs that were explicitly mentioned.
Enter the Word to the Wise Delivery Wiki to fill the need for a publicly accessible reference on email delivery. The cornerstone of the site is the ISP Information page. This page contains summary information about a number of ISPs, including known connection and sending limits. Each ISP mentioned on that page also has a individual page with more detailed information on delivering to that ISP. The information is as accurate as I could make it, and in many cases have been reviewed by representatives of the ISPs.
I welcome contributions from the general community. I will also be continuing to add content. My goal is to have a community resource for people handling email and delivery issues.

Yahoo and Goodmail

The industry has been abuzz the last few days with the news that of Feb 1, Yahoo will no longer be supporting Goodmail in their interface. I did get a chance to get a response from someone at Yahoo, but didn’t get a chance to talk to anyone from Goodmail. Look for a post next week discussing the breakup, what impact it has on the industry and what this may mean for other ISPs.

Protecting customer data

There have been a number of reports recently about customer lists leaking out through ESPs. In one case, the ESP attributed the leak to an outside hack. In other cases, the ESPs and companies involved have kept the information very quiet and not told anyone that data was leaked. People do notice, though, when they use single use addresses or tagged addresses and know to whom each address was submitted. Data security is not something that can be glossed over and ignored.
Most of the cases I am aware of have actually been inside jobs. Data has been stolen either by employees or by subcontractors that had access to it and then sold to spammers. There are steps that companies can take to prevent leaks and identify the source when or if they do happen.

Project Omnivore

Ben at Mailchimp has posted some information about Project Omnivore. This is a predictive system that not only predicts potential abuse, but can also be used to predict poor campaigns. Steve and I had a chance to see Omnivore in action when we were in Atlanta last fall, and were impressed by the accuracy for bad stuff. It seems, however, that Omnivore is useful to predict good behaviour as well.

ESPs leaking email addresses

Two of my tagged email addresses started getting identical pharma spam over the weekend. It is annoying me because I am now getting spam in a mailbox that was previously spam free. The spam is overwhelming the real traffic and I am having to make some decisions about what to do with the email addresses and their associated accounts with the companies I gave them to.
One thing I did notice, though, is that both companies use iContact as their ESP. A cursory check of my other mailboxes shows that none of my other tagged addresses are mailed through iContact. I don’t think it’s very likely that these two individual, unrelated companies made deals with the same spammers to sell address lists at the same time. It’s much more likely that there was a compromise somewhere and address lists were stolen.
Edit: Checked my other account and, likewise, I’m getting the same spam to a 3rd address serviced by iContact. I’ve sent mail to all 3 companies involved and we’ll see how they react.
And, as I was thinking about this, iContact just laid off a bunch of staff about the same time they announced their partnership with Goodmail. Based on past history with companies in this situation, it seems possible this is a disgruntled former employee. I’ve also seen reports from other people noticing spam to addresses given to iContact customers.

Spammers aren't who you think they are

Shady direct marketers exploit CAN SPAM to continue spamming but protect themselves from the law. This is something I’ve been talking about for a while (TWSD), and it’s nice to see the mainstream press noticing the same thing.
HT: Box of Meat

It doesn't matter what you say

“What should we tell the ISP?” is a frequent question from my customers. The answer is pretty simple. It doesn’t usually matter what you tell the ISP. What matters are your actions.
If a sender is having delivery problems then the solution is not to call the ISP and talk to them about why the sender’s mail should not be delivered to the bulk folder. Instead, the solution is to evaluate the email and the address acquisition process and the list hygiene process. Identify where potential problems are and then resolve those problems.
Typically, the ISPs won’t need to be contacted. The changes to the email will register and delivery will improve. In some cases, particularly when there’s been some major mistake, contacting the ISP and explaining the mistake and what steps have been taken to stop the mistake from happening in the future may help resolve the issue faster. But if nothing has changed, then there’s no reason for the ISP to expect anything to change.
It doesn’t matter what you say. It matters what you do.