Automatic bounce handling

Contents

1. Abstract
2. Bounces, the bane of all list owners
3. The solution
4. Footnotes

Abstract

lists.darkspire.net has implemented bouncefilter to automatically handle bounces in a sane and fair fashion.

Bounces, the bane of all list owners

Bounces are annoying to both the list owners and the subscribers. Not only are they incredibly frustrating to list owners, but they also cause considerable delay in mail delivery and clog up the queue on the outbound email servers.

Bounces are normally delivered to the list owner for inspection. He or she will need have to deal with them as they see fit. This is a huge hassle, especially on high-volume lists where one can expect several hundred bounces. Many bounces are caused by transient failures, the rest are permanent. This is a dilemma for the list owner as it is unfair to blindly unsubscribe a perfectly valid subscriber. This becomes more of an issue on mission critical lists such as internal staff lists, development lists, incident reports, and so forth.

The solution

Every 10 days majordomo sends out a message posted to the list using a specially encoded envelope-from in each email. This "tags" each message with the user's email address and the mailing list this message is coming from. This allows bouncefilter to determine the recipient and the mailing list from a bounce even if the DSN¹ delivered by the MTA² does not conform to rfc 1894. (unfortunately there are a lot like this) They are called bouncefilter+ envelopes because they begin with bouncefilter+ and follow with the encoded information.

When a bounce comes in, and is rfc 1894 compliant (the proposed Internet standard for the format of DSNs) bouncefilter can parse that and figure out the address that failed, the mailing list it belongs to, and if it is a permanent or transient failure. The above mentioned bouncefilter+ envelopes are a way to get this information from poorly designed MTAs. It is especially effective for users who forward their email to another address, the destination address is bouncing, and the returned DSN does not conform to rfc 1894.

Since there is a lot more overhead using bouncefilter+ envelopes, these are normally only used every 10 days, unless it is reset manually for some reason (usually to track down bounces from broken MTAs).

When a bounce is received bouncefilter stores their address, the mailing list, and the DSN. Every day for 5 days the user will be notified that their email and bouncing and the reason. If the bounces stop, so do the notices.

If the user's email bounces for more than 5 days, the user is unsubscribed from this mailing list and any other mailing lists they are subscribed to. Every day for 25 days they are notified that this happened, normally they will continue to bounce. If the bounces stop, so do the notices. Contained in this notice is an explanation of everything that has happened, and what they need to do in order to get back on the mailing lists they were removed from. They can then get back in the mailing list(s) if they desire.

Email services on many providers is flaky and can bounce for many reasons, often times these are transient failures, many times they are not. Using these grace periods and daily notification allows bounces to be handled in a nice sane, and automatic way that is both good for the list owner as well as the subscribers.

Footnotes

1. DSN: Delivery Status Notification
2. MTA: Message/mail transfer agent

$Revision: 1.3 $
$Date: 2001/10/07 04:10:25 $