If an email cannot be delivered, it is returned to the sender, or "bounced." Email delivery can fail for any number of reasons, and the failure may be permanent or temporary.

When an MTA receives an error message during an attempt to transfer an email, it repeats the attempt if the error message indicates the failure is temporary. If the MTA receives a fatal error message or is unable to complete the transfer after repeated attempts, it wraps the message with a warning and bounces it back to the sender. For more information on the email delivery process, see How Email Works.

The most common reason email bounces is that the address of the intended recipient isn't valid. Email addresses change frequently as users migrate to new ISPs, create new accounts, move to new companies, etc., and users don't always update their mailing list subscriptions when their email addresses change. This is a significant maintenance issue for large mailing lists that may have thousands of subscribers. At any given moment, a mailing list probably has some bad email addresses on the subscriber list and this number tends to increase over time. This phenomena is known as "list decay."

Even if an address is valid, a mailbox may be temporarily unavailable because the owner has exceeded its allotted disk space, or a mail server may be temporarily unavailable because it is processing a large volume of mail.

If the address doesn't exist, the failure will be permanent.

When a message is posted to a mailing list, an email is generated for every subscriber, then passed to an MTA for transfer to an MTA that receives email for the domain to which the message is addressed. Large mailing lists may generate more than ten thousand email messages to send to their subscribers every time a message is posted.

The mail queue has a limited number of slots available (e.g., 100) to process outgoing messages. Each of these slots is filled with an email and the remains occupied until the message is transferred successfully or is deferred (i.e., fails).

When an MTA encounters problems transferring an email, the email continues to occupy the slot while the MTA makes repeated attempts to transfer it. Eventually the MTA will give up and defer delivery, adding an error message to the mail logs and freeing up the slot for the next message in the mail queue. If there are many bad addresses on a mailing list, the average rate at which email clears the queue can drop significantly, as shown in the following diagram.

Figure 15.1. Mail queue

Automated bounce handling is the mailing list's answer to list decay. When an email bounces, it is returned to the envelope header's 'Reply-To' address, which has been set to the address of an automated bounce handler. The ezmlm bounce handler sends a series of bounce messages to the addressed that bounced to test whether the bounce was temporary or permanent. The bounce handler tracks what happens to the messages it sends and responds accordingly.

The bounce handler uses the subscriber address and message number (encoded within the sender address) to track which messages have bounced for which address. Since messages can bounce for a variety of reasons, the ezmlm bounce handler does not remove a subscriber from the list immediately. Instead, it waits approximately 10 days after the first bounce (the actual default value is 1 million seconds), then sends a warning message to the subscriber. The warning message lists the numbers of the messages missed. The user can retrieve these from the raw archives, assuming this feature has been enabled. If the warning message bounces, too, ezmlm waits another 10 days, then sends a probe message. If this probe message bounces, the email address is removed from the subscriber list. This process guarantees that a subscriber will not be removed due to a temporary error, while assuring that all nonexistent or permanently failing addresses are removed.

There are different kinds of bounce-related error messages. The discussion so far has focussed on bounce warnings and probes sent to test whether a delivery failure is permanent or transitory, but

When email delivery fails, the sending MTA returns error messages to the sender by email, and the server also records an error message in the mail logs. Both of these types of messages indicate whether the failure was temporary or fatal, and describe the type of failure.

Email bounce messages are wonderfully self-explanatory for the most part, but if you aren't completely sure how to identify what type of failure occurred, you can look up the error message in the troubleshooting flowchart What does this message mean?

Even though all bounces would be monitored by humans in an ideal world, in reality it is seldom practical, since organizations tend to be inundated with bounced messages. In the real world, bounces are usually handled automatically, with no human intervention and no notification of administrators unless they happen to be the sender. It is generally up to users to contact support about bounces and other problems that appear to be bounce-related.