Problems with the maintenance of large mailing lists
RFC 1211

Document Type RFC - Informational (March 1991; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1211 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         A. Westine
Request for Comments:  1211                                    J. Postel
                                                                     ISI
                                                              March 1991

          Problems with the Maintenance of Large Mailing Lists

Status of this Memo

   This RFC discusses problems with maintaining large mailing lists,
   especially the processing of error reports.  This memo provides
   information for the Internet community.  It does not specify an
   Internet standard.  Distribution of this memo is unlimited.

Table of Contents

   1.   Introduction..............................................   1
   2.   Discussion................................................   1
   3.   Typical Problems..........................................   3
   3.1. Misdirected Error Reports.................................   3
   3.2. Sublists..................................................   3
   3.3. Misdirected Requests......................................   5
   3.4. Misdirected Messages......................................   5
   4.   Summary...................................................   5
   APPENDIX A - I used to be on the List..........................   6
   APPENDIX B - Changing Addresses and Sublists...................   8
   APPENDIX C - Sublists and Other Protocol Worlds................   9
   APPENDIX D - Errors from Hidden Hosts..........................  10
   APPENDIX E - No Postmaster.....................................  12
   APPENDIX F - Examples of Error Messages........................  14
   5.   Security Considerations...................................  53
   6.   Authors' Addresses........................................  54

1.  Introduction

   Maintaining large mailing lists, especially the processing of error
   reports, poses many problems.  Most of the examples come from the
   experience of managing the Internet Engineering Task Force (IETF)
   mailing list.  Many examples are presented in this memo.  Most of the
   specific problems shown have already been corrected.

2. Discussion

   At USC - Information Sciences Institute (ISI) we maintain mailing
   lists for the Internet Research Groups, the IETF, and other Internet
   groups; about 25 lists altogether.  We receive about 400 messages a
   month requesting additions or deletions to these lists.  There are

Westine & Postel                                                [Page 1]
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
Show full document text