2010/07/07 by Maarten Oelering.

On the classification of bounces

Delivering large volumes of email can be difficult. Properly handing the bounces can be even more challenging. To decode, analyze and classify the hundredths of different bounce mail formats is a complex task. To give you an idea what you might encounter, here are some examples of bounces:

421 4.7.1 Intrusion prevention active for [X.X.X.X] 451 qq read error (#4.3.0)
452 Message for would exceed mailbox quota
530 Authentication required
550 5.1.1 Not our Customer
550 Mailbox unavailable or access denied –
550 Administrative prohibition
550 Envelope blocked – User Entry
550 no such address here
550 5.7.1 e-mail address access denied
550 not valid
550 failedaddressrouter router forced verify failure
553 sorry, that domain isn’t in my list of allowed rcpthosts (#5.7.1)
554 5.7.1 UBE Not Welcome Here!
554 5.3.0 rewrite: map parse not found

In order to process bounces in the right way they first need to be classified. After classification we can apply bounce rules to them. A good rule is that invalid email addresses are immediately disabled and excluded from further mailings. Other bounce types should be removed as soon as it is clear that the problem is permanent. Spam related bounces should be detected and require action from the sender to resolve them.

The famous two categories, “hard” and “soft”, for which many use different definitions, is vague concept and a generalization which should not be used to base any business logic on. All decent mail servers will retry the delivery when it encounters an error that starts with the code ’4xx’, indicating a temporary failure. So when the email bounces, it has been retried many times so there’s nothing “soft” about it.

If you think that the three digit code in the bounce can be used for classification, you are wrong. Even the enhanced status codes as described in RFC 3463 are often ambiguous or used wrongly. Moreover, the status classes described in this and other RFCs are not really useful from the perspective of email list management. For example a 5.7.1 “relay access denied” is not really a security issue, but often caused by an invalid email domain that resolves to a host.

So what is a good classification then? After thinking about for a very long time and analyzing many bounces I came up with the following:

• recipient related
  • user unknown
  • mailbox inactive
  • quota exceeded
• domain related
  • invalid domain
  • no mail host
  • relay/access denied
• spam related
  • sender blocked
  • content blocked
  • policy issue
• system related
  • system issue
  • protocol issue
  • connection issue

With these four main categories, it is more clear where the source of the problem is. Using the subcategories, you make your bounce rules aggressive or relaxed. For example by changing the behaviour on mailbox inactive or quota exceeded bounces.

With some programming I was able to parse and classify hundreds of thousands of bounces into the categories mentioned above. Using some ingenious text pattern matching I ended up having a list of almost 400 different patterns. More on that in a future post.

It is astonishing to see how even large ISPs obfuscate a simple “user unknown” with descriptions such as “unrouteable address”, “no such mail drop defined” or “unsupported mail destination”. This makes it almost impossible to automatically classify bounces without frequent adaptation to newly encountered descriptions. How can these ISPs expect senders to properly maintain their database that way?

More information?
If you would like to know more about how we can help you, just send us a message via our contact page.