Network Working Group Keith Moore Internet-Draft University of Tennessee Expires: 25 March 1998 25 September 1997 Requirements for IETF Mailing Lists draft-moore-maillist-req-01.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. 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. NOTE: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in Moore Expires 25 March 1998 [Page 1] IETF Mailing List Requirements 25 September 1997 this document, when written in all upper-case, are to be interpreted as described in [RFC-2119]. When these words are written using lower-case letters, they are to be interpreted as in ordinary English usage. 4. Administration Each IETF mailing list SHALL have a human who is directly responsible for maintaining the list. The list maintainer shall be responsible for routine administrative requests (e.g. subscribe, unsubscribe, or change- of-address), deleting subscribers for whom mail is persistently undeliverable, thwarting mail loops due to broken subscriber software, and taking other action as necessary to assure continued operation of the mailing list. Each IETF mailing list SHALL have (at least) two addresses: one for submissions to be redistributed to the list subscribers, 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 . This address SHALL be the primary point-of-contact for administrative requests. It is NOT sufficient for a list to respond to all mail sent to the -REQUEST address, with instructions to use a list server at a different address. Administrative requests which are sent to the -REQUEST address SHOULD be honored, or at least answered, within two working days of receipt. For the purpose of this requirement, days on which IETF meetings are held are not considered working days. All administrative requests SHOULD be acknowledged by sending an electronic mail "reply" to the requestor. Automatic list server software MAY be used to handle routine administrative requests sent to the -REQUEST address. If such software is used, it MUST forward unrecognized requests to the list maintainer. Requests thus forwarded SHOULD be answered within two working days. The address SHALL also be valid, though this address SHOULD NOT normally be used for routine administrative requests associated with the mailing list. Mail sent to the Postmaster of the list server SHOULD be answered within two working days. A subscriber SHOULD be removed by the list maintainer if mail from the list for that subscriber is returned as undeliverable on more than three separate days within a thirty-day period. If a subscriber is removed for this reason, the list maintainer SHOULD attempt to send a message to that (former) subscriber notifying him/her that he/she has been removed Moore Expires 25 March 1998 [Page 2] IETF Mailing List Requirements 25 September 1997 from the list. A subscriber SHALL be removed by the list maintainer, + if that subscriber's email software automatically returns any kind of response message to the entire mailing list (be it a nondelivery notification, delivery notification, delay notification, receipt notification, vacation notification, change-of-address notifica- tion, or any other kind of automatic response), OR + if the subscriber's mailer sends an automatic response messages to the addresses on the To field, Cc field, or any Resent-* field of a message sent to the list, OR + if the subscriber's mailer causes forwarding loops or repeatedly spews messages to the list. If a subscriber is removed from the list for one of the above reasons, the list maintainer SHALL immediately inform the subscriber of the reason for the removal. The subscription SHALL NOT be restored to the list until the list maintainer has assurance that the subscriber has taken appropriate corrective action. 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 list subscribers. Instead, it SHOULD be returned to the originator with instructions to send that message to the correct list submission address. 5. Header munging Two types of lists are considered here: Non-digest lists forward each message individually to list subscribers. Digest lists collect inbound messages until some number of messages have been received or some time interval has elapsed, and bundle those collected messages into a single message which is then sent to list subscribers. A single discussion may be available in both non-digest and digest form; however, every IETF list SHALL be available in non-digest form. 5.1. Header munging for non-digest lists In general, a non-digest list is expected to preserve all header fields in the input message when redistributing that message to list subscribers. In particular: Moore Expires 25 March 1998 [Page 3] IETF Mailing List Requirements 25 September 1997 + A list MUST NOT alter the To, Cc, Sender, From, Reply-To, Message- Id, In-Reply-To, References, Date, or Received fields of a message redistributed to list subscribers. + A list MUST NOT alter or delete a header field without specific instructions to do so, or simply because it does not recognize the field name. Exceptions and/or clarifications for specific cases appear below. 5.1.1. Reply-To A list MUST NOT remove or alter a Reply-To field supplied by the originator of the message. A list SHOULD NOT add a Reply-To field to a message that lacks one. For a working group mailing list, exceptions to this rule SHALL be approved by the Area Director responsible for that group. DISCUSSION: On most IETF lists it is highly desirable to allow extended conversations between one or more mailing lists and one or more parties who may not be subscribers of such lists. A list which supplies its own Reply-To field defeats that functionality. 5.1.2. Subject field A list MUST NOT alter the Subject field of a message redistributed to list subscribers. EXCEPTION: A list MAY prepend a short name of the mailing list to the Subject line. The short name MUST be the same for all messages sent to that list -- for example, it MUST NOT contain a sequence number. For any list which prepends the short name of the list: + The short name MUST be enclosed in square brackets. + The list MUST remove its short name from the Subject field of any inbound replies, before prepending the short name. Example: For a list named "XYZ", a message containing the header field Subject: foo would have that rewritten to read Moore Expires 25 March 1998 [Page 4] IETF Mailing List Requirements 25 September 1997 Subject: [XYZ] foo before being sent to the list. A reply to that message might contain the header field Subject: Re: [XYZ] foo Rather than simply prepending "[XYZ] " to that subject, the list MUST first remove the "[XYZ] " from the reply (yielding "Re: foo"). The list may then prepend its name to the result, producing Subject: [XYZ] Re: foo 5.1.3. Sender field A list MUST NOT add a Sender header field to a message redistributed to list subscribers. A list MUST NOT alter or remove a Sender field which was originally present in the message. DISCUSSION: Many lists add a Sender field of some kind which indicates either the address of the list maintainer, or the software which handles the mailing list, and this field is widely used by subscribers of those lists (e.g. for collation of mail from different lists). Such use defeats the original purpose of Sender, which is to identify the person who originated the message. (RFC 822 says "person, system, or process", but neither systems nor processes should be sending messages to IETF lists.) Automatic collation of mail can be accomplished using the Return-Path field. Collation may also be accomplished using one of the List-* fields, or a tag in the Subject field, if the list supports either of these features. 5.1.4. Message Disposition Notification processing A list MAY issue a Message Disposition Notification [MDN] on behalf of the list if it receives a message with a Disposition-Notification-To field. If such a notification is issued, the list MUST remove the Disposition-Notification-To field from the message before it is redistributed to list subscribers. Moore Expires 25 March 1998 [Page 5] IETF Mailing List Requirements 25 September 1997 5.1.5. List-* fields A list MAY add one or more List-* fields such as those defined in [LISTSPEC] or future standards-track RFCs. 5.1.6. Other fields commonly added by mailing lists A list MUST NOT add an Errors-To field to messages distributed to list subscribers. This practice can interfere with normal error handling. A list SHOULD NOT add a Precedence header field to a message redistributed to the list subscribers. Due to a wide variation in the handling of the Precedence field, inclusion of this field can result in message delivery failures. 5.1.7. Removal of undesirable fields A list SHOULD remove any of the following header fields from any message redistributed to a list: + Content-Length (nonstandard, ill-defined, and probably inaccurate), + Errors-To (conflicts with SMTP MAIL FROM and Return-Path), + Precedence (nonstandard, use varies widely and causes some mail software to break), + Return-Path (should not be present in a message before final deliv- ery). + Disposition-Notification-To, Return-Receipt-To, X-Confirm-Reading- To, or any other field which is intended to cause the recipient's mail system to send a receipt notification or delivery report. + Any List-* header fields present in the original message. (However a list is allowed to add its own List-* header fields.) 5.2. Format of digest messages Digests SHOULD be in MIME format, as in the example in [RFC-2046], section 5.1.5. In particular, the structure of a digest message SHOULD be: Moore Expires 25 March 1998 [Page 6] IETF Mailing List Requirements 25 September 1997 multipart/mixed text/plain (table of contents) multipart/digest message/rfc822 (message 1) message/rfc822 (message 2) message/rfc822 (message 3) ... NOTE: Some MIME mail readers, and some foreign mail systems which are gatewayed to MIME, do not effectively present multipart/digest format. Participants who are stuck using such mail readers should subscribe to the non-digest version of the list. For some degree of compatibility with mail readers that understand [RFC-1153], the "boundary" parameter of the inner multipart/digest MAY be specified as 28 "-" characters. NOTE: the actual boundary marker consists of 2 "-" characters plus the value of the "boundary" parameter, thus messages will actually be separated by 30 "-" characters as per RFC 1153. If this boundary marker is used, a line in the message text beginning with 30 "-" characters MUST be altered in some way to prevent its confu- sion with a boundary marker, but which does not change the meaning of the message. This MAY be accomplished by changing the first "-" to a SPACE. The top-level header of a digest message MAY have a Sender field containing an address for the list maintainer. This address MAY be an alias (say owner-FOO-DIGEST@somehost.org), but it MUST NOT be the address used for posting. The top-level header of a digest message MAY have one or more List-* fields such as defined in [LISTSPEC] or future standards-track RFCs. The top-level header MUST NOT contain an Errors-to field, and SHOULD NOT contain a Precedence field. 5.2.1 Header munging for component messages For the component messages, the following header fields MUST be retained if present in the original message: MIME-Version, Content-Type, Content- Transfer-Encoding, In-Reply-To, Date, Sender, From, Reply-To, To, Cc, Subject, Message-Id, Keywords. It is RECOMMENDED that the fields be included in this order. These fields MUST NOT be modified from the original message. Other fields SHOULD be omitted. Moore Expires 25 March 1998 [Page 7] IETF Mailing List Requirements 25 September 1997 Exceptions: + A Content-Type field specifying "text/plain; charset=US-ASCII", with no other parameters, MAY be omitted. + A Content-Transfer-Encoding of 7BIT MAY be omitted. + If neither Content-Type nor Content-Transfer-Encoding are present, the MIME-Version field MAY be omitted. + The Content-Transfer-Encoding of a component message MAY be changed, for example, to allow transmission of the digest over 7-bit only channels. 6. Envelope munging A 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 list subscribers. This address MUST NOT be the same as the list submission address, and mail to this address MUST be processed separately from normal submissions to the list. For a list submission address of , a suggested MAIL FROM address is . DISCUSSION: Some list handling software attempts to heuristically distinguish between list submissions, administrative requests, and automatically generaeted responses such as nondelivery reports. While such heuristics can sometimes identify misdirected subscribe messages, or thwart mail loops caused by certainly especially brain-damaged mailers, experience has shown that they are not sufficiently reliable to obviate the need for a separate address, and separate processing of each of these categories of mail. The MAIL FROM address SHOULD be fixed for any particular list; a separate MAIL FROM address SHOULD NOT be assigned on a per-recipient or per-delivery basis. DISCUSSION: Some list handling software assigns a separate MAIL FROM address for each subscriber, so that nondelivery reports sent to the MAIL FROM address automatically identify the subscriber for whom delivery has failed. While this technique is useful in some cases, it is not recommended for mailing lists because it requires that the message be transmitted separately to each subscriber. It may also interfere with other uses of MAIL FROM and Return-Path. Even if this technique is used, it is still necessary to interpret messages returned to that address, because MAIL FROM and Return-Path are Moore Expires 25 March 1998 [Page 8] IETF Mailing List Requirements 25 September 1997 used for other kinds of mail besides permanent nondelivery reports. 7. Filtering A list MAY attempt to automatically filter out administrative requests ("subscribe", "help", etc.), to prevent such messages from being sent to the list subscribers. Mail with an invalid sender address (e.g. illegal address syntax, or domain not listed in DNS) MAY also be filtered. A list MAY attempt to automatically filter out mass mailed commercial or political advertisements, chain letters, messages describing "make money fast" schemes, requests to send postcards to a dying child, or other traffic whose content is obviously inappropriate for, and not specifically intended for, the discussion on the list. Such automatically filtered traffic MUST be sent to the list administrator or an appropriate moderator for review and possible resubmission to the list, just in case it was mistakenly selected by the filter. Ordinary misdirected messages SHOULD be returned to the sender to inform the sender that the message was not delivered. However, messages which are inappropriate and obviously not specifically intended for the list, SHOULD NOT be returned to the sender. Most IETF mailing lists (including all working group lists) are public and open to any individual who wishes to contribute to the discussion. While effective contribution to a list discussion generally requires that the contributor read the list traffic, some contributors may prefer to do so by other means than being subscribed to the list - say by perusing the list archives. In addition, some subscribers may receive their list mail at one address (perhaps one specifically dedicated to traffic from that list) but send mail to the list using a different From address. Public IETF mailing lists therefore SHOULD NOT reject a message (i.e. refuse to distribute it to the list subscribers) simply because the sender's address does not appear on the list of subscribers. Any public IETF list that performs such filtering: + MUST forward filtered messages to the list administrator or an appointed moderator for review and possible resubmission to the list (rather than simply bouncing the message), + MUST provide a mechanism to allow nonsubscribers to be added to a list of addresses which are allowed to post messages to the list (thus bypassing the nonsubscriber filter) Moore Expires 25 March 1998 [Page 9] IETF Mailing List Requirements 25 September 1997 + MUST notify a nonsubscriber sender of such a message that his mail is being forwarded to the moderator for review, along with an explanation of how the sender may request to be added to the "non- subscribers who are allowed to post" list. A list MAY attempt to filter out malformed messages which are likely to cause problems with recipients' mail software. Examples include messages with non-ASCII characters in the message header, illegal RFC 2047 encoded-words in the message header, illegal MIME boundary markers, or 8bit messages labelled as 7bit. Such messages SHOULD be immediately returned to the sender as nondeliverable. 8. Responsibilities of a list subscriber List subscribers are expected to send administrative requests to the -REQUEST address and not to the list submission address. List subscribers are expected to send submissions to the primary list submission address, rather than to any other address. List subscribers SHOULD NOT send submissions to any of: + an "alias" for the list submission address, + the list maintainer, + 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. (This could happen if the sub- scriber's Internet access is via a mail gateway which derives its notion of "From" or "Sender" from SMTP.) List subscribers are expected to choose descriptive Subject lines for messages (including replies) that they submit to the list. This is especially important for a list member who subscribes to the digest version of a list, where the top-level Subject is often "XXX-Digest, issue YYY". List subscribers are expected to prevent robots which automatically send notifications on their behalf, from responding to messages from mailing lists. (e.g., automatically generated "vacation" notices, receipt Moore Expires 25 March 1998 [Page 10] IETF Mailing List Requirements 25 September 1997 notifications, message disposition notifications, change-of-address notices, or "I'm behind in reading my mail" notices) Autoresponders used by list subscribers SHOULD send responses to the envelope return address or the address in the Return-Path header field. Autoresponders MUST NOT send responses to any address obtained from a To, Cc, Resent-To, Resent-Cc, or Reply-To field. (NOTE: the MUST NOT prohibition against use of Reply-To is necessary to prevent loops for lists which put the list submission address in the Reply-To field.) If a list subscriber receives a nondelivery report as a result of submitting a message to the list, say from a list subscriber whose address is no longer valid, the originator SHOULD forward that nondelivery report to the list maintainer. (This shouldn't happen, but it happens anyway due to broken mail software.) There are other requirements on the content of messages sent to an IETF list, e.g., the sender should be civil to other list participants, IETF lists should not be used for advertising, etc. Such requirements are not within the scope of this memo, and their omission from this memo should not be taken to mean that they do not exist. 9. List archives According to IETF standards procedures, each working group mailing list MUST maintain an archive of messages sent to that list. Archived messages MUST be available in the format sent to subscribers of the non- digested list, so that they may be downloaded into one's private message store. The archives may be accessible using FTP or HTTP or both. If there is no FTP-accessible archive, the HTTP archive MUST permit downloading of all messages to the list in a small number of transfers. Other means of accessing list archives MAY be provided, for instance, via IMAP or as hypertext. A useful format for archives is: + a single directory contains all of the archived mail for a particu- lar list, and the directory only contains mail for that list. + Within that directory, archived mail for a particular year and month is collected in a single file named for that year and month. The year should appear first, so that the individual files will appear in time order when sorted by name. Four digits MUST be used to represent the year. (e.g. "1997-09"). File names SHOULD be short. + Within a file, messages are concatenated together in the order they are received, each message preceded by a line of the form: Moore Expires 25 March 1998 [Page 11] IETF Mailing List Requirements 25 September 1997 From sender@some.domain Wed Sep 25 00:01:34 1997 which is immediately followed by the RFC 822 message header. A blank line is appended to the message body. If this format is used, it will be necessary to "escape" messages containing "From " at the beginning of a line. This may be accomplished by changing "From " to ">From ", or (preferably) by changing the content-trans- fer-encoding of the message so that "From " never appears. While not a standard, this format is understood by many user agents. MIME digest format is also acceptable, but the digests used for archiving SHOULD contain all message header fields which were sent to the non-digest list. 10. Security Considerations This section discusses known attacks on mailing lists, some possible effects of such attacks, and suggested countermeasures. 10.1. Forged requests It is possible to forge administrative requests (subscribe, unsubscribe, change address) on behalf of unsuspecting parties. A malicious forgery might be used to deny a subscriber access to the list traffic, or to send list traffic to someone who did not wish to receive it. All successful administrative requests MUST be acknowledged to both the requester (i.e. the user whose address appears in the From header field of the request), and the subscriber address(es) affected by the request (if different from that in the From field). For a change-of-address request, acknowledgement MUST be sent to both the old and new subscriber addresses, in addition to the addresses in the header From field. To prevent some kinds of loops, unsuccessful administrative requests SHOULD NOT be acknowledged to other than the single address of the requestor. 10.2. Unsolicited mass mailings Even small amounts of bulk mail, (consisting of content which is neither appropriate for the list, nor specifically intended for the list), can disrupt the normal functioning of a list. In extreme cases, mass mailings can be indistinguishable from a denial-of-service attack. A variety of heuristics can be employed to discourage such attack, including: Moore Expires 25 March 1998 [Page 12] IETF Mailing List Requirements 25 September 1997 + Sending a confirmation message to first-time or occasional posters, requiring a reply before their submission will be forwarded to the list. + Verification of the From address of the subject message (e.g. syn- tax, domain listed in DNS) + Verification that the From address is a subscriber of the list, or on the list's "allow postings from" list. As attacks on lists are becoming more sophisticated, countermeasures will necessarily also become more sophisticated. It would therefore be inappropriate for this memo to specify which countermeasures should be used, or to limit use of such countermeasures. 10.3. Mail loops and flooding Malicious or clueless individuals can create mail loops by causing list submissions to be sent back to the list. While accidental loops can often be detected by examining message content, deliberate attacks may not contain such clues. Lists SHOULD therefore employ mechanisms such as rate limiting to limit the effect of loops and flooding attacks. 10.4. Automatic probing of list subscribers Some list exploders provide commands which allow attackers to obtain the addresses of list subscribers. Attackers may use such commands, for instance, to gather lists of addresses for unsolicited mass mailings, or to automatically compile lists of people interested in certain topics. The list of subscribers SHOULD NOT be available without human intervention -- either via the SMTP VRFY or EXPN commands, or otherwise from the list processor. DISCUSSION: This supersedes the rule in [RFC-2026] requiring that mailing lists be accessable. EXPN and similar mechanisms are increasingly used by hostile parties, to collect lists of addresses to be used as targets of unsolicited bulk mailing. Requests for the membership of any official IETF mailing list (for instance that of an active working group) SHOULD be sent to the list maintainer, or to the IETF Secretariat. Moore Expires 25 March 1998 [Page 13] IETF Mailing List Requirements 25 September 1997 11. Acknowledgements The author wishes to thank Harald Alvestrand, Ad Bresser, Ned Freed, Randall Gellens, John Klensin, Chip Rosenthal, Bonnie Scott, and Klaus Weide for their comments in response to earlier drafts of this memo. 12. References [LISTSPEC] Neufeld, Grant, and Joshua D. Baer. "The Use of URLs as Meta-Syn- tax for Core Mail List Commands and their Transport through Message Header Fields". Internet-Draft , 22 March 1997. [MDN] Fajman, Roger. "An Extensible Message Format for Message Disposi- tion Notifications". Internet-Draft , 29 July 1997. [RFC-1153] Wancho, F. "Digest Message Format". RFC 1153, April 1990. [RFC-2026] Bradner, S. "The Internet Standards Process -- Revision 3". RFC 2026, BCP 9, October 1996. [RFC-2046] Freed, N., and N. Borenstein. "Multipurpose Internet Mail Exten- sions (MIME) Part Two: Media Types". RFC 2046, November 1996. [RFC-2119] Bradner, S. "Key words for use in RFCs to Indicate Requirements Levels", RFC 2119, BCP 14, March 1997. 13. Author's Address Keith Moore Moore Expires 25 March 1998 [Page 14]