This is an analysis of ezmlm's bounce handling for the qmail mailing list.
Volume was fairly low this past weekend; 70 messages were delivered to the mailing list over 75 hours. Those messages generated a few hundred immediate bounces. Meanwhile, a few hundred more bounces arrived for older messages.
Some of the failing addresses are continuing to fail; ezmlm will eventually kick them off the mailing list. Most, however, were victims of configuration problems, fixed a few days later; ezmlm will send each address a list of the message numbers that bounced. The rest are sporadic problems, indicating that after twenty years the Internet still can't deliver mail reliably.
Nonexistent hosts: 18 addresses were rejected because the host wasn't in DNS, the DNS server was persistently unreachable, the host was persistently unreachable, etc.
Nonexistent users: 15 addresses were permanently rejected because the target mailbox didn't exist.
Misconfigured hosts: 16 addresses were rejected because of MTA misconfiguration: 8 because the host didn't accept mail for itself; 2 because a message had (legitimately) taken 13 hops; 1 because a message did not have a Message-ID; 1 because a message had an unusual header field; 1 because the SMTP client's IP address didn't match the envelope sender address; 1 because the user demanded a particular token in the Subject line (even from mailing lists!); 1 because the MTA could not handle a return path containing an equals sign; and 1 because a delivery agent was installed improperly (and ignored by the system administrator despite repeatedly signaling temporary failures).
Temporary errors incorrectly classified as permanent: 8 addresses were rejected because of poor MTA programming. For example, one SMTP server ended a very slow connection with a permanent failure code (``554 DATA timeout''). Two delivery agents exited with codes that the MTA did not recognize; the MTA incorrectly assumed that the errors were permanent. Two MTAs handled temporary DNS errors incorrectly.
Deferral notices: 3 addresses returned errors that ezmlm didn't recognize as deferral notices. (I suggest that MTA implementors use ``Subject: deferral notice'' for deferral notices and ``Subject: success notice'' for success notices.)
Confused MUAs: One user attempted to reply to a mailing list message, but his MUA, Z-Mail, sent the reply to the Return-Path address.
5 addresses are at hosts that have been removed from DNS or from the network.
1 address is a user that was removed.
1 address is at a host whose MTA was incorrectly configured to bounce 8-bit messages. A mailing list message included 8-bit data, and bounced; ezmlm's warning included a copy of the message, and bounced; soon ezmlm will send a probe that includes a copy of the warning, and the address will be kicked off the mailing list. 7-bit MTAs are a disease that could easily have been stamped out years ago.