D. J. Bernstein
Internet mail

Some bounces handled by ezmlm

Date: 19970804.

This is an analysis of ezmlm's bounce handling for the qmail mailing list.

Basic statistics

The mailing list has 736 subscribers. Many of the subscribers are sublists, redistributing messages to more subscribers. I don't have to worry about bounces for sublist subscribers as long as each sublist sets its own Return-Path.

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.

Bounces of mailing list messages

ezmlm is currently monitoring 61 addresses from which a mailing list message has bounced in the last ten days.

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.

Bounces of warning messages

ezmlm is monitoring 7 addresses from which a warning message has bounced in the last ten days.

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.