4xx
Thoughts on bounce handling
This week’s Wednesday question comes from D.
What are your thoughts on bounce handling
Read More
Changes at Gmail
As I’ve said before, I can usually tell when some ISP changes their filtering algorithm because I start getting tons and tons of calls about delivery problems at that ISP. This past month it’s been Gmail.
There have been two symptoms I’ve been hearing about. One is an increase in bulk folder delivery for mail that previously was reliably hitting the inbox. The other is a bit more interesting. I’ve heard of 3 different mailers, with good reputations and very clean lists, that are seeing 4xx delays on some of their mail. The only consistency I, and my colleagues at some ESPs, have identified is that the mail is “bursty.”
The senders affected by this do send out mail daily, but the daily mail is primarily order confirmations or receipts or other transactional mails. They send bi-weekly newsletters, though, exploding their volume from a few tens of thousands up to hundreds of thousands. This seems to trigger Gmail to defer mail. It does get delivered eventually. It’s frustrating to try and deal with because neither side is really doing anything wrong, but good senders are seeing delivery delays.
For the bulk foldering, Bronto has a good blog post talking about the changes and offering some solid suggestions for how to deal with them. I’m also hearing from some folks who are reliable that Gmail may be rolling back some of the bulk foldering changes based on feedback from their users.
So if you’re seeing changes at Gmail, it’s not just you.
AOL transmitting 4xx error for user unknown
AOL is currently returning “451 4.3.0 <invaliduser@aol.com>: Temporary lookup failure” in some cases when they really mean “550 user unknown.” This message from AOL should be treated as 5xx failure and the message should not be retried (if at all possible) and the failure should be counted as a hard bounce for list management purposes.
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
Soft bounces and rate limiting
What is your policy for handling soft bounces? What do you consider a soft bounce? What is the right thing to do about soft bounces?
The first step in talking about soft bounces is to define them. When I talk about soft bounces, I mean mail that has been rejected with a 4xx response during the SMTP transaction. As described by RFC5321, when a recipient MTA responds with a 4xx it is telling the sending MTA “Wait! I can’t take this mail right now. Come back a little later and try again.” The sending MTA will then continue to attempt to deliver the message until either it is delivered or until it hits the max delivery time, usually 3 – 5 days.
In a well behaved and RFC compliant MTA, messages that have reached the maximum time without delivery due to 4xx rejections will be converted to permanent rejections (5xx). With a correct MTA, this means too many emails in a row timing out shoud result in an email address being removed from future mailings.
For a number of reasons some ISPs, notably Yahoo, are using 4xx responses to slow down mail from some senders. Many senders treat this as a inconvenience and a frustration and try to figure out how to get around the rate limiting. The UK DMA published an article on soft bounces with the following words of wisdom.