rfc1211.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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
   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                                                [Page 2]

RFC 1211              Problems with Mailing Lists             March 1991


   SMTP EXPN feature.  Then the postmaster is notified.

   If the error report is about a host being unknown, the programs
   "whathost", "dig", "ping", and "traceroute" may be used to find the
   problem.  However, getting the problem fixed may require
   communication with host and domain administrators.

   What to do if problems can't be resolved: Delete the offending entry
   from the list that may eventually cause the following response: "I
   used to be on the ietf list, how come I am not getting the messages
   any more?" (See Appendix A.)

3.  Typical Problems

   In this section we discuss typical and frequent problems that occur
   with large mailing lists.

3.1  Misdirected Error Reports

   The most frequent problem is that error reports are sent to the
   author of the message rather than the list owner.  One way this can
   happen is when there is trouble with the author's host not connecting
   to another host along the route before it reaches ISI where the
   mailing list is.

   At ISI the SMTP "from" information is added when the message is
   distributed to the list so that hosts following the SMTP protocol
   will send their error reports to the list owner.  However, not all
   hosts do this properly.

   Another problem is that some machines do not pay attention to the
   SMTP information about where to send error reports.

3.2  Sublists

   What is a sublist?  It is a mailbox with an alias-name that expands
   to a mailing-list or group of recipients.  There are many sublists on
   our mailing lists.

   When a user requests that a mailbox be added to a list that looks
   like an exploder, the following message is sent:

      We ask that all list maintainters of exploder mailboxes (an
      alias-name that expands to a mailing-list or group of recipients)
      set up some sort of ownership at their site, for their list.  What
      this means is, is any mailbox on your list is invalid, the error
      message will go to you (the list owner), and you can delete that
      mailbox from your list.



Westine & Postel                                                [Page 3]

RFC 1211              Problems with Mailing Lists             March 1991


      An example of an entry in your aliases file would be:

         owner-ietf-local:  [e-mail],

            (or your list maintainer/postmaster)

   It appears that few people understand the concept of list ownership,
   or they do not set it up correctly.  There is ample evidence of
   problems in this area.

   When investigating "user unknown" messages it is often the case that
   the user is not individually listed on our list.  The next step is to
   check received lines and hunt for an exploder list with a host
   similar to the one that the error came from or points to.  At that
   point we attempt to use SMTP EXPN or VRFY to check that the user is
   on a sublist.  Since many hosts do not implement EXPN or VRFY, the
   result of our check is inconclusive.  We then contact the list
   maintainer and ask him to delete the invalid mailbox if it is on his
   sublist.

   Another problem occurs when someone on a sublist wants to change the
   name of his mailbox.  We look through the main list to make the
   correction and if that mailbox is not on the list we check the
   received lines and look for clues to determine which host this user
   may be on.  More than likely it is a sublist.  (See Appendix B.)

   When the mailbox is in another protocol world (like UUCP or BITNET)
   there are often problems with the handling and direction of error
   reports. (See Appendix C.)

   Sometimes we are unable to find the addresses reported in the error
   message on the mailing list in question.  In such a case we check the
   mailing list for a host name also named in the received lines of a
   message in error.  If we find a match then we look for an exploder on
   that host and expand the sublist there to see if the mailbox in
   question is on that sublist.  (See Appendix D.)

   At the time a sublist is entered into our list we record the name of
   the requestor and consider him the sublist owner.  As people change
   roles or companies this contact sometimes fails, in that case we fall
   back to contacting the postmaster.  However, not every site has a
   "postmaster" mailbox. (See Appendix E.)

   Most users send their requests and changes to the IETF-Request
   mailbox, when they are on, in fact, a sublist, usually at their own
   company.  This creates a problem for us trying to determine which
   exploder they're on.




Westine & Postel                                                [Page 4]

RFC 1211              Problems with Mailing Lists             March 1991


   In this case, the request message is forwarded to the sublist owner
   so he can make changes to his list.  However, sometimes hosts may be
   somewhat similar in name (from the same organization, but in a
   different department, in a different building, off campus, etc.) and
   it's hard to know if this person should really be on that particular
   sublist, or listed individually.  Occasionally, we examine the main
   file to see if there are individual addresses that could be
   incorporated in a sublist.

3.3  Misdirected Requests

   Some users don't know that mailing lists usually have a "request"
   mailbox, so they mistakenly send their requests to the main list.
   When this happens, several people will resend the request to the list
   maintainer and then want to know if the request was completed.

3.4  Misdirected Messages

   There are also messages that go to the request mailbox when they are
   intended for the main list.  These messages get forwarded to the main
   list and a message is sent to the user notifying him of the
   correction and the proper way to address his message.

4.  Summary

   Running a mailing list should be easy, and with small lists it is.
   The number of changes and errors are small and infrequent.  But when
   lists get large and traffic gets heavy, the number of changes and
   errors grow to many a day.  The level of effort to manage a mailing
   list of substantial size and use becomes significant.

   An additional problem is the creativity shown by mail program
   developers in inventing numerous different error reports.  We present
   a large sample of such messages in Appendix F.  We hope that these
   examples will be of help to other mailing list maintainers.

   Our experience with maintaining large lists suggests the following:

   Users:  Please be considerate and try to work problems out locally.

   Sublist owners:  Please do everything you can to get the error
   messages related to your sublist to go to you.  Please try to get
   users on your system to talk to you about additions and deletions.








Westine & Postel                                                [Page 5]

RFC 1211              Problems with Mailing Lists             March 1991


                                APPENDIX A

A.1.  Inquiry Message From User Regarding His Mailbox

   Date: Tue, 6 Nov 90 03:02:09 PST
   From: "Stewart Bryant, RE02-G/H2, DTN: 830 4682"
         <[e-mail]>
   To: [e-mail]
   Subject: dist list

   Please will you check that I have not been deleted from this
   distribution list.

   My email address is : [e-mail]

   Thanks

   Stewart

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A.2.  Message To User - His Mailbox Was Re-added

   To: "Stewart Bryant, RE02-G/H2,
       DTN: 830 4682" <[e-mail]>
   cc: [e-mail]
   Reply-To: [e-mail]
   Subject: Re: dist list
   In-reply-to: Your message of Tue, 06 Nov 90 03:02:09 -0800.
                <[e-mail]>
   Date: Tue, 06 Nov 90 13:54:23 PST
   From: Ann Westine <[e-mail]>

   Hi Stewart,

   > Please will you check that I have not been deleted from this
   > distribution. list.
   >
   > My email address is:  [e-mail]

           I readded you to the list.

   --Ann

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






Westine & Postel                                                [Page 6]

RFC 1211              Problems with Mailing Lists             March 1991


A.3.  User Name Readded and It Bounced

   Date:    Tue, 06 Nov 90 17:25:15 -0800
   From:    [e-mail] (Mail Delivery Subsystem)
   To:      [e-mail]
   Subject: Returned mail: User unknown

       ----- Transcript of session follows -----
   mail11: Error from DECnet MAIL object on node "janus",
            during mail delivery to <JANUS::BRYANT>.
            Remote error code is 0x7e81d2, message is:
   %MAIL-E-ERRACTRNS, error activating transport NM
            (can't decypher error code)
   550 <[e-mail]>... User unknown

      ----- Recipients of this delivery -----
   <[e-mail]> (bounced)

      ----- Unsent message follows -----
   Received: by decpa.pa.dec.com; id AA21747; Tue, 6 Nov 90 13:54:38
   Received: from LOCALHOST by venera.isi.edu (5.61/5.61+local)
            id <AA24660>; Tue, 6 Nov 90 13:54:25 -0800
   To: "Stewart Bryant, RE02-G/H2,
        DTN: 830 4682" <[e-mail]>
   Cc: [e-mail]
   Reply-To: [e-mail]
   Subject: Re: dist list
   In-Reply-To: Your message of Tue, 06 Nov 90 03:02:09 -0800.
         <[e-mail]>
   Date: Tue, 06 Nov 90 13:54:23 PST
   From: Ann Westine <[e-mail]>

   Hi Stewart,

   > Please will you check that I have not been deleted from this
   > distribution list.
   >
   > My email address is
   >
   > [e-mail]

   I readded you to the list.

   --Ann

************************************************************************





Westine & Postel                                                [Page 7]

RFC 1211              Problems with Mailing Lists             March 1991


                               APPENDIX B

In this example, the old mailbox "[e-mail]" was to
be deleted and the new mailbox "[e-mail]" was to
be added.  However, when checking the mailing list the old address was
not found.  Further checking for anything that resembled the hostname