RFC 1211 (rfc1211) - Page 2 of 54
Problems with the maintenance of large mailing lists
Alternative Format: Original Text Document
RFC 1211 Problems with Mailing Lists March 1991
about 20 messages a day requesting changes to the lists.
We also receive about 300 error messages a month due to mail delivery
problems. Many of these are duplicates, but the net result is that
about 10 cases per day need to be investigated.
Many of the error reports are for "soft errors", primarily delayed
delivery notices, such as "not delivered for 2 days, will try for 3
more days". These just waste the list maintainer's time and are
otherwise ignored. This is especially wasteful when such messages
are repeated every day. However, if the same host is a cause of such
messages for many days in a row, the list maintainer may investigate.
Please note that ignoring the soft errors is not always easy, since
error messages often contain error reports on several mailboxes,
requiring the error message to be read carefully to pick out the hard
errors.
The error reports that indicate hard errors, such as "no such user"
require the list maintainer to take action. In many cases the
appropriate action is to simply delete the user mailbox from the
list. However, if the mailbox in question is someone known to be
active as a working group chair, or such, further investigation is
necessary. The more general case of "no such host" may be a
temporary condition, but if it continues for several days it must be
investigated.
Since the error conditions do not have standardized names (for
example, "no such user" vs. "user unknown") it is sometimes difficult
to understand whether a soft or hard error is being reported, and
what one should do about it. For example, what does "Can't Find Mail
Center!" mean, or what should one do about "mailll:%MAIL-E-OPENOUT,
error opening SYS$USER2:[STGEORGE.LONGMAIL]MAIL$00040093BE236612.MAI;
as outputI)"?
The first step in investigating a problem with a user mailbox is to
see if it is on the list. If so, the next step is to see if there
really is a problem with it. This is done by using the SMTP VRFY and
EXPN features, Finger, or Whois. This often develops information
suggesting that the user has recently changed his address. This has
to be confirmed through an exchange of messages (with the postmaster)
and then the mailing list must be updated.
If the user is not on the list, then it is likely the mail is sent
via an exploder or sublist. So the investigation focuses on finding
which exploder may be involved, usually this is found by looking at
the path (from the received lines) of the error report. The exploder
that is the source of the error can sometimes be checked using the
Westine & Postel