BLOG

Thoughts on bounce handling

This week’s Wednesday question comes from D.

What are your thoughts on bounce handling

There’s no specific standard for bounce handling as we often talk about it. While a lot of people will mention the RFCs, the RFCs only say what to do with a single email that gets a 4xy or a 5xy during the SMTP transaction. If the message gets a 5xy during the SMTP transaction, then the email MUST NOT be retried. If the message gets a 4xy during the SMTP transaction then it can be retried.

What the RFCs don’t mention is what to do with future emails to that email address. In context, this makes sense. When the RFCs were originally written there weren’t lists of tens or hundreds of thousands of addresses. At that time, every email was sent by a person and the bounces came directly back to that person. The person could decide, based on the bounce, what to do about future emails.

Volume, however, means we have to automate bounce handling and parse hundreds of different rejection messages.

I’m somewhat agnostic on exactly how someone should bounce handle. As long as a sender is making a good faith effort to remove undeliverable addresses within a reasonable time frame, I don’t think the details are critical. Removing after 4 bounces or after 5 bounces isn’t going to make a huge difference in delivery.

I don’t advocate bounce handling for 4xx messages. If you have a compliant MTA, then it will retry mail rejected with a 4xx. If that mail cannot be delivered over your retry period (usually over 3 – 5 days) then it should “hard bounce” with a 5xx error and that will be measured as a hard bounce.

The handshake standard that those ISPs and ESPs in the room agreed to back in 2002(ish) was 3 consecutive bounces in more than 14 days meant an address should be removed. It basically gives the senders mailing daily get 14 chances to mail to a non existent addresses. Mailers that send weekly get 3 attempts.

Sometimes ISPs do have issues. Very rarely they’ll lose some sync between their MTA and their backend database and indicate addresses are invalid when they really aren’t. Giving a minimum 2 weeks and a minimum number of bounces keeps these (again, VERY RARE) happenings from removing all the addresses off a list.

I don’t think spamblocks should be necessarily used to purge addresses, only unknown user 5xy responses (usually 500 or 550).

For some of my clients with more configurable systems, I will often have them purge addresses on the first bounce *if* that is also the first time they’ve mailed that address. It’s a statistics thing: the chance of a valid address getting on a list the same day as an ISP falls over is fairly low. Therefore, being aggressive in bounce handling on the first mailing is a good idea. Also, if a company is trying to re-engage users or start mailing a segment that hasn’t been mailed recently, then they should consider removing on a single bounce.

Don’t forget there are times when mail will fail even before the start of a SMTP session. This means that you WILL NOT get a 5xy or 4xy message on many MTAs (some of the commercial ones manage this for you, most of the open source ones don’t). These failures are typically DNS failures; things like no MX, a MX of “.”, or NXDomain are all signs that address is undeliverable and should be handled as an unknown user response. MX . or NXdomain should be purged immediately.

1 comment

  1. Atro Tossavainen says

    What do you mean by “most of the open source ones don’t”?

    : Host or domain name not found. Name service
    error for name=slkdfjdaoisfjdoiafds.com type=A: Host not found

    (That’s Postfix)

    That’s an immediate bounce on the sending server. There clearly aren’t any RFC 3463 status codes – there never was a SMTP conversation that could have resulted in any. What did I miss?

Comment:

Your email address will not be published. Required fields are marked *

  • AOL compromise

    Lots of reports today of a security problem at AOL where accounts are sending spam, or are being spoofed in spam runs or something. Details are hazy, but there seems to be quite a bit of noise surrounding this incident. AOL hasn't provided any information as of yet as to what is going on.4 Comments


  • ReturnPath on DMARC+Yahoo

    Over at ReturnPath Christine has an excellent non-technical summary of the DMARC+Yahoo situation, along with some solid recommendations for what actions you might take to avoid the operational problems it can cause.No Comments


  • AOL problems

    Lots of people are reporting ongoing (RTR:GE) messages from AOL today.  This indicates the AOL mail servers are having problems and can't accept mail. This has nothing to do with spam, filtering or malicious email. This is simply their servers aren't functioning as well as they should be and so AOL can't accept all the mail thrown at them. These types of blocks resolve themselves. 1 Comment


Archives