Network Working Group Keith Moore Internet-Draft University of Tennessee Expires: 19 January 1997 19 July 1996 Requirements for IETF Mailing Lists draft-moore-maillist-req-00.txt 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Following review by interested parties, the author intends to submit this document to the IESG for consideration as a Best Current Practice. Comments should be sent to moore@cs.utk.edu. 2. Abstract This document describes requirements for all IETF official mailing lists, including (but not limited to) mailing lists used for working group discussion. 3. Introduction There is a wide variety of practice in the administration and processing of mailing lists, and there are several existing software packages which enforce or encourage different practices. In the interest of uniformity of user interfaces across IETF discussions, and of robust handling of mailing list anomalies, this memo outlines practices which are required for all IETF mailing lists. Moore Expires 19 January 1997 [Page 1] IETF Mailing List Requirements 19 July 1996 4. Administration All IETF mailing lists shall have (at least) two addresses: one for submissions to be redistributed to the list membership, and another for administrative requests (e.g. subscription requests, deletions, address changes). A mailing list MAY have other addresses, for instance, to access a mail-based robot which provides back issues of the list. If the address used for subscriptions is of the form , the address used for administrative requests shall be . The address MUST also be valid, though this address should not normally be used for routine administrative requests. Administrative requests shall be handled within two working days. For the purpose of this requirement, days on which IETF conferences are held shall not be considered working days. All administrative requests shall be acknowledged by sending an electronic mail "reply" to the requestor. Mail sent to the Postmaster of the list server MUST also be answered within two working days. Every IETF mailing list shall have a sentient human being as list maintainer, who is directly responsible for maintaining the list. The list maintainer shall be responsible for routine administrative requests, deleting recipients for whom mail is persistently undeliverable, and thwarting mail loops due to broken subscriber software. Automatic list server software MAY be used to handle routine administrative requests for IETF lists, and such software MAY be used to handle mail sent to the -REQUEST address. However, if such software is used, it MUST be able to recognize when it does not understand a request, and tell the requestor how to send mail to the human being who is responsible for maintaining the list. Requests sent to that human being must be answered within two working days. A recipient SHOULD be removed by the list maintainer if mail for that recipient is returned as undeliverable on more than three separate days within a thirty-day period. If a recipient is removed for this reason, the list maintainer MUST attempt to send a message to that recipient notifying him/her that he/she has been deleted from the list. + A recipient MUST be removed by the list maintainer, if that recipient's email software automatically returns any kind of response message (be it a nondelivery report, delivery report, delay notification, receipt notification, vacation notification, Moore Expires 19 January 1997 [Page 2] IETF Mailing List Requirements 19 July 1996 change-of-address notification, or any other kind of automatic response) to the entire mailing list; or if the recipient's mailer sends an automatic response messages to the addresses on the To or Cc header field of a message sent to the list; or in general if the recipient's mailer causes forwarding loops or repeatedly spews messages to the list. When the list administrator receives a message which is obviously intended as a submission to the list, and which was sent to either the -REQUEST address or to the SMTP MAIL FROM address used to redistribute messages (see section 6), it SHOULD NOT be forwarded to the list membership. Instead, it should be returned to the originator with a instructions to send that message to the correct list submission address. 5. Header munging In general, a list is expected to preserve all header fields in the input message when redistributing that message to the list membership. Specific exceptions and/or clarifications appear below. The list MAY, when redistributing a message to the list membership, add a Reply-To header field to a message that lacks one, in an attempt to cause replies to go back to the list. This practice is neither recommended nor forbidden. However, the list MUST NOT remove or alter a Reply-To header supplied by the originator of the message. The list SHOULD remove any of the following header fields from any message redistributed to a list: Content-Length (nonstandard, misleading), Errors-To (violates RFC 821 and RFC 1123), Precedence (nonstandard, use varies widely and causes some mail software to break), Return-Path (should not be in a message except at final delivery), Return-Receipt-To (nonstandard, layering violation), X-Confirm-Reading- To, or any other header which is intended to cause the recipient's mail system to send a receipt notification or delivery report. The list MUST NOT add an Errors-To or Return-Receipt-To header field to a message redistributed to the list membership. The list SHOULD NOT add a Precedence header field to a message redistributed to the list membership. The list MUST NOT alter the To, Cc, From, Reply-To, Subject, Message-Id, In-Reply-To, References, or Date fields of a message redistributed to the list membership. The list MUST NOT alter or delete Received fields of messages redistributed to the list membership. Moore Expires 19 January 1997 [Page 3] IETF Mailing List Requirements 19 July 1996 The list MUST NOT delete a header field without specific instructions to do so. (In other words, a list MUST NOT delete a header field simply because it does not recognize it.) 6. Envelope munging The list MUST set the SMTP MAIL FROM address to point to the address of the list maintainer (or a robot acting on his or her behalf) on all messages redistributed to the list membership. This address MUST NOT be the same as the list submission address (even if the software handling the list thinks it can distinguish list submissions from nondelivery reports and other automatic responses). For a list submission address is , a suggested MAIL FROM address is . 7. Responsibilities of a list member List members are expected to send administrative requests to the -REQUEST address and not to the list submission address. List members are expected to send submissions to the list submission address. List members SHOULD NOT send submissions to any of: + the -REQUEST address + the address in the Return-Path header field + the address in the Sender header field (if any) + the so-called "From " address (on systems that use the UNIX "mbox" format), or + the SMTP envelope return address. List members are expected to keep their mail software in working order such that it does not do harm to the list. Members may be removed from the list if their mail software causes harm to the list. There are other requirements on the content of messages sent to an IETF list, e.g. the sender should be civil to other list members, IETF lists should not be used for advertising, etc. Such requirements exist but are not within the scope of this memo. 8. Security Considerations Security Considerations are not addressed in this memo. Moore Expires 19 January 1997 [Page 4] IETF Mailing List Requirements 19 July 1996 9. Author's Address Keith Moore Moore Expires 19 January 1997 [Page 5]