Bounce handling should be designed to appropriately manage your subscriber base. Delivery problems are the consequence if you don’t do that. They shouldn’t be the reason you bounce handle, though.

Context matters.

My experience tells me that senders that think about the impact of their sends can do things that “break the rules” while still being respectful of their subscribers and still see good delivery.

The server hosting that mail system has been flakey lately, and needs to be hard power cycled to make it come back. We had a major power glitch this morning and so ended up down at the colo and power cycled that box while we were there.

This box was last working February 4th. It’s been off the internet for almost 2 months now. It wasn’t answering on port 25. It was dead. No mail here. And, yet, a bunch of legitimate email marketers are still attempting to send those addresses mail.

Really. Dead for 2 months and the senders keep trying to mail to those addresses. The server came back about 2 1/2 hours ago. I already have 6 emails from two different senders.

Seriously. If you can’t deliver a mail to someone for TWO MONTHS just give it up already. I am sad that even companies that get the best advice I can give them still can’t get the simple things right.

And, really, don’t argue “but it came back! Clearly we should keep trying!” Yes, it came back. But in all the years I’ve had this disposable email system I have not opened a single image. I’ve not purchased a single thing. I’ve never shown any sign of life on any of those addresses. The mailserver has been down for months at a time. There is no value to continuing to send mail to those addresses. And, yet, people still do it.

Why? WHY!?

This is something broken at AOL’s end, and the guys with the magic fingers that keep the system running are working to fix it. Right now there doesn’t seem to be an ETA on a fix, though.

Even if you are a sender who is able to stop the retries, you may see some congestion and delays when sending to AOL for the time being. Senders who don’t get the message, or who are unable to stop their MTAs from retrying 4xx mail will continue to attempt delivery of these messages until their servers time out. This may cause congestion for everyone and a noticeable  slowdown on the AOL MTAs.

AOL blog post on the issue

HT: Annalivia

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.