A number of people have mentioned over the last couple weeks that they’re seeing a spike in Yahoo rejecting mail with
554 delivery error: dd Requested mail action aborted
Discussions on various mailing lists indicate these messages are related to inactive accounts. Addresses that bounce at Yahoo with these codes should be handled as inactive addresses and removed from future mailings.
It should be easy, right? Except it’s not. So why is it so hard?
With one-on-one or one-to-few email it’s pretty simple. The rejections typically go back to a human who reads the text part of the rejection message and adapt and makes the decision about future messages. The software handles what to do with the undeliverable message based on the SMTP response code.
In the case of a 5xy response the server stops attempting delivery and alerts the original sender the mail failed. One example from helping a client troubleshoot a delivery problem recently.
There’s useful information in the text portion of this email from my mail server. It says there was a permanent failure (550) and that my message won’t be delivered. It also says the email is quarantined in reply to the end of DATA. That’s actually a critical piece of information. It means Barracuda saw the entire message before deciding to reject it. It’s likely a problem with the content of the email and so I need to look at links in the message.
This type of plain text explanation is great for a human to read and act on. But it’s not that simple for list handling software to identify the relevant information in the text message and act on future emails to that recipient. Different MTA vendors and ESPs have done a lot of work to try and correctly parse bounce messages to pull out relevant information.
ISPs have tried to help the situation by giving more descriptive rejection messages. They’re still using the SMTP required 3 digit numbers, but they include short, parseable codes in the text portion of the message. In many cases they also include URLs and links that open up webpages explaining the meaning of the code. They even post a list of the most common codes on their postmaster webpages.
All of these things make it somewhat easier to handle bounces automatically. Kinda.
I’ve been working on some bounce handling recommendations for a client using a few different ESPs. I spent a good few days digging into the bounces returned by their different ESPs. It was an interesting exercise as it demonstrated how very differently ESPs handle bounces. But it also clarified for me that there are a lot of different kinds of bounces.
A few years ago I wrote a series of blog posts about zombie email addresses. Zombie addresses are those that someone owned and used and interacted with, but for whatever reason stopped logging into and checking. This series started with the time before the zombies, and moved on to the zombie uprising. Then discussed how they don’t eat brains, but they do love to take a bite out of deliverability. Smart marketers, however, can defeat zombies by the judicious application of the double tap.
Since that series of blog posts a few things have changed. The biggest thing is that the webmail providers are being much more aggressive about disabling email reception at addresses where folks don’t log in. I have a few addresses on different providers I use for testing purposes. I have to remember, though, that I need to log into them before sending test messages. If I don’t, they generally bounce.
This doesn’t completely remove the challenge of zombie addresses but it does make it easier for regular senders to purge their lists of zombies just through their normal bounce handling. No double-taps needed.
Today it was revealed that Yahoo has been scanning people’s email for the federal government.
Read More