Network Working Group RJ Atkinson, Editor INTERNET DRAFT Not Organised draft-rja-mail-lists-00.txt 6 September 2001 IETF Mailing List Conventions STATUS OF THIS MEMO This document is an Internet-Draft and is subject to all provisions in Section 10 of RFC-2026. 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 inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/1id-abstracts.html. The list of current Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. ABSTRACT This document describes proposed conventions for use on IETF-related mailing lists. Subject to normal processes and procedures, this draft might some day be published as an RFC with status of Best Current Practice (BCP). This document supplements both [RFC-2418] and [RFC-3005]. Comments on this draft may be sent directly to the editor or to the <ietf-process@lists.elistx.com> mailing list. To subscribe to that list, send an email request to ietf-process- request@lists.elistx.com Atkinson Expires in 6 months [Page 1]
Internet Draft IETF Mailing List Conventions 6 September 2001 1. Introduction The IETF uses mailing lists as its primary method for accomplishing work. In normal practice, each IETF Working Group has at least one mailing list that is used principally for discussions within that Working Group's charter. In the 1970s and 1980s, there was broader consensus on appropriate network etiquette, for example unsolicited email solicitations ("spam") was uncommon and was widely viewed as inappropriate. As the network has grown and as the set of IETF participants has broadened, unsolicited email solicitations ("spam") have become more common. Also, the usual processes whereby newcomers get oriented to existing customs have not scaled as well as the community might have liked. Newcomers are strongly encouraged to read The Tao of the IETF. [RFC-1718] Originally, the IETF was more loosly organised than at present. So in the early days, each IETF list was hosted at some non-IETF site, most usually an academic or research site. More recently, commercial sites have become a very common location for hosting an IETF mailing list. In the past few years, the IETF Secretariat has developed the capability to host and automatically archive an IETF mailing list. In the case of some particular lists, the rate of incoming off-topic postings has become so high that the IESG has authorised human moderation of the list. This document proposes a set of mailing list conventions that are applicable to IETF-related mailing lists. It is believed that these proposed conventions are already in wide, but not necessarily universal, use as of this writing. 2. Current Issues with IETF Mailing Lists A major issue on current IETF mailing lists is the currently variable signal/noise ratio. A major source of noise is "spam", the sending of commercial advertisements or similar solicitations to IETF mailing lists. Another flavour of the same basic issue is the posting of promotional/marketing material on IETF mailing lists by list participants. Off-topic discussions on lists can also be a significant source of noise. It is important that postings to any IETF list keep on-topic for that particular list so that participants do not have to wade through other postings in order to actively participate in the Working Group via email. It is important to retain the long-standing practice of Atkinson Expires in 6 months [Page 2]
Internet Draft IETF Mailing List Conventions 6 September 2001 remote folks and those otherwise unable to travel (e.g. university students and faculty) being able to participate in all Working Group business via email (i.e. attendance at meetings is not required to have an impact). It is also important that IETF list archives are complete, are backed up regularly, are easily located, and are readily accessed by anyone who wishes to read them. While this is true for most IETF lists today, the quality of the archives, the quality of backup arrangements, and ease of location for IETF mailing lists vary widely today. Some current postings are larger than they need to be due to use of fancy formatting (e.g. MIME RichText, HTML) or binary attachments (e.g. proprietary word processor formats, proprietary viewgraph formats). This impedes the ability of folks behind lower bandwidth Internet connections (e.g. folks in less fibre-rich parts of the world than the US) to actively participate in IETF discussions. Also, some folks don't have a mail reader that can handle anything more complex than the MIME text/plain attachment type. Postings that can't be read by all readers often hinder rather than advance the Working Group's progress on its mailing list. Some current postings use non-standard character set encodings or otherwise do not conform with the IETF standards for email format. Postings that do not strictly comply with the IETF standards for mail format cannot be read by many folks who using standards-compliant mail tools. Hence, such postings generally impede the ability of a Working Group to make progress rather than advancing the work. An increasing number of subscribers to IETF mailing lists have misconfigured mail software (e.g. "vacation" programs) that send "Out of Office" replies to everyone who posts to the given IETF mailing list during the period that subscriber is out of the office. This can be highly annoying to other participants and is entirely gratuitous, since a properly configured "vacation" program will know not to send such messages in response to a received mailing list message. While this problem can happen with several kinds of systems and many users, PC-based users appear to have more trouble with this than non-PC-based users. A small number of current IETF mailing lists automatically add a "Reply-to:" mail message header to each posting. This is problematic because it forces replies to go only back to that one mailing list. It is desirable that a reader of an IETF list can easily reply privately to the poster without the message being sent to the entire list (to optimise the signal/noise ratio of the list). Atkinson Expires in 6 months [Page 3]
Internet Draft IETF Mailing List Conventions 6 September 2001 It is equally desirable that a postings to multiple IETF WGs not have all replies forced to any subset of the original set of IETF WG lists. Hence, the automatic addition of the "Reply-to:" header with IETF mailing lists creates problems. 4. IETF Mailing List Conventions IETF mailing lists are open to anyone who wishes to subscribe. IETF Working Group chairs have broad discretion in how they manage their Working Group mailing list(s). This note, while it provides specific guidance to WG chairs and the IESG, does not alter the fundamental principle that IETF Working Group chairs have broad discretion in managing their Working Group mailing list(s). 4.1 Message Content Postings to IETF mailing lists MUST be on-topic for the list(s) that they are posted to. Postings that clearly advance the WG's current work, as defined by the then-current charter posted at the IETF web site, are considered to be on-topic. The Working Group's charter SHOULD be used as an reference for what is on topic for that WG's mailing list(s). Any disputes SHOULD be resolved by the WG Chair(s). The WG Chair(s) has (have) broad discretion in determining what is on-topic or off-topic for their WG list. A WG Chair MAY temporarily suspend or defer discussion of an otherwise on-topic item (e.g. in order to focus WG attention on a different higher priority topic). Postings to IETF mailing lists MUST focus on architectural, standards, or technical content that advances the progress of the Working Group towards fulfilling its charter. Postings that are primarily of a political, (non-technical) philosophical, or legal nature SHOULD NOT be made to IETF mailing lists. Postings that use foul language or attack people (as different from criticising a particular idea on technical grounds) are always inappropriate and SHOULD NOT be made to IETF lists. Postings to IETF lists MUST be made using real identifiable names and email addresses, rather than obfuscating aliases. Participants ought not use their employer affiliation for marketing, neither should they disguise their employer affiliation in IETF activities. All postings to IETF lists are considered to be only the personal views of the person originating the posting, neither as the opinion of their employer (even if the posting asserts it is an employer's official view) nor as the opinion of the organisation hosting their email account. Atkinson Expires in 6 months [Page 4]
Internet Draft IETF Mailing List Conventions 6 September 2001 4.2 List Hosting The IETF Secretariat has good facilities in place for hosting IETF mailing lists. Tools in place include not only the usual email-based subscription methods, but also a subscriber web- interface. IETF WG Lists hosted at IETF.ORG are administered by someone designated by the WG Chair, not by the IETF Secretariat. A password-protected web-based list administration interface makes remote list administration straight-forward. Hence, newly created IETF mailing lists are encouraged to use the mail relay at IETF.ORG, rather than setting one a mail relay elsewhere. Having more lists located at IETF.ORG also makes it easier for newcomers to find and join the lists of interest. Existing lists MAY migrate to the mail relay operated by the IETF Secretariat if they wish to do so. Existing lists that aren't conforming with this specification might find that moving such lists to the IETF Secretariat is the simplest way of getting such lists in compliance with this document. 4.3 List Moderation There are two kinds of moderated lists that are discussed in this note. There are some IETF lists that already have implemented one of these two kinds of moderation. Self-moderated lists are not uncommon as of this writing. A "Self-Moderated List" is one that accepts postings only from source email addresses that are members of the list of subscribers to that mailing list. The term "self- moderated list" dates back to USENET of the late 1980s. Self- moderation is primarily used to reduce SPAM and other off-topic postings. A "Full Moderated List" is different in that each individual submission to that mailing list is subjected to human review and filtering before being posted to the list. 4.3.1 Self-Moderation A "Self-Moderated Mailing List" is one that accepts an email posting only if the source ("From:") email address is in the list of addresses that subscribe to that mailing list or is in a side list of other approved source email addresses. In this case, "moderation" is NOT some person making a personal judgement call, but rather is normally just an automated program that makes the single check above, then either accepts or rejects the attempted email posting. An IETF mailing list MAY be self-moderated without explicit approval from the IESG if the WG Chair(s) approve(s). Postings from a non-subscriber to a self-moderated IETF list MUST be automatically routed to a human moderator. That moderator SHOULD ignore any Atkinson Expires in 6 months [Page 5]
Internet Draft IETF Mailing List Conventions 6 September 2001 message posting from a non-subscriber if the message posting appears to be off-topic. The moderator of a self-moderated list MAY post a non-subscriber message if it appears to be within charter and on- topic for the list, MAY simply grant the non-subscriber posting rights to the list without subscribing the poster, or MAY bounce the message back to the author with subscription instructions. A self-moderated mailing list SHOULD have the concept of an authorised posting address that is not a list subscriber address. If an IETF list has the concept of an authorised posting address that is not a subscriber address, then postings from a non-subscriber to a self-moderated IETF list MAY simply be bounced back automatically along with instructions on how to join the non-subscriber posting address and instructions on how to subscribe to the list itself, instead of being forwarded to a moderator. A self-moderated list MAY automatically add the subscribers to one or more other IETF lists to its own non-subscriber authorised posting address list. Because WG participants SHOULD be subscribed to the WG list (by definition) as part of keeping abreast of that WG's efforts, there is NO hard requirement that the moderator of a self-moderated list automatically post any messages from non-subscribers (who, by definition, are not WG participants). The moderator MAY directly post on-topic notes from non-subscribers, but also MAY choose not to do so on high-volume lists because that manual intervention does not scale well. Posters who are not subscribers to the self-moderated list being posted to SHOULD NOT expect instantaneous or rapid handling of their posting by the moderator. An explicit goal with self-moderated lists is to keep the burden on human moderators at a very low level. 4.3.2 Full Moderation With explicit prior approval from the applicable IESG Area Director(s), an IETF Working Group mailing list MAY use a human moderator to reduce and prevent off-topic postings to an IETF Working Group mailing list. If this approval is granted, the applicable IESG Area Director(s) MUST promptly announce it to the affected mailing list(s). That announcement, a brief statement from the AD on why full moderation was approved, and also the name(s) and email address(es) of the moderator(s) MUST additionally be posted in an appropriate place on the official IETF web site. There SHOULD normally be some specific arrangement (e.g. having dual moderators or having both a primary moderator and backup moderator) that ensures that the list does not grind to a halt if the moderator becomes ill, goes on travel, takes vacation, or is otherwise temporarily not able to perform the function. Significant Atkinson Expires in 6 months [Page 6]
Internet Draft IETF Mailing List Conventions 6 September 2001 changes to the moderator arrangements SHOULD be noted in an email announcement from the applicable IESG Area Director(s) to the affected IETF mailing lists and SHOULD cause updated information to appear an the appropriate place on the IETF web site. Procedurally, the standard IETF process rules apply to any dispute over management of an IETF mailing list. This means that complaints about mailing list management MUST initially be discussed with the Chair(s) of the applicable Working Group. For this reason, WG Chair(s) normally SHOULD NOT moderate their own WG's mailing list(s), although they MAY moderate their own WG's mailing list if the appropriate Area Directors do not object to this. 4.4 Languages & Character Sets To ensure maximum interoperability, users MUST NOT use proprietary or uncommon MIME charsets in postings to IETF mailing lists [RFC-2130], whether or not those charsets have been registered with IANA. In particular, local or national character set and encoding standards are often not implemented globally, while the IETF does operate globally. In particular, the MIME charset of "US-ASCII" SHOULD be used for all messages that only employ US-ASCII [ANSI-X3.4] characters. The UTF-8 MIME charset [RFC-2279] or any ISO-8859 series MIME charset MUST be used for any postings that employ non-US-ASCII characters. [RFC-2277] Postings not in the US-ASCII character set MUST contain appropriate IETF standards-track (i.e. MIME-compliant) headers indicating the MIME charset(s) contained in the message. [RFC-2231] Postings MUST NOT use any form of ISO-2022 mechanism for character set switching, because of repeated negative operational experience with this mechanism. [ISO-2022] Postings SHOULD NOT use header characters in any manner that is not strictly compliant with IETF mail header standards, because it impedes both interoperability and the ability of all readers to reply to the sender. An IETF mailing list MAY automatically or manually filter out email that uses any character set encodings that are not compliant with IETF standards. In particular, any postings that use proprietary character set encodings MAY be filtered out. Messages containing only the MIME charsets approved above, including US-ASCII, any ISO-8859 series, and UTF-8 MUST NOT be filtered out on the basis of the charset. Lists that employ MIME charset filters SHOULD cause Atkinson Expires in 6 months [Page 7]
Internet Draft IETF Mailing List Conventions 6 September 2001 the filtered out messages to be sent to a human moderator for review before discarding. Subject to the above restrictions on non-standard character sets in email, any human language MAY be used for IETF list email. Users SHOULD send postings in a human language that is readable by ALL list members. In practice, IETF meetings are held in English and current IETF lists overwhelmingly use English on their lists. 4.5 Mail Format Requirements Many users are behind low-bandwidth, long-delay links and so suffer undue adverse impact by needlessly large mail messages. The IETF intends to be accessible to all, even those in remote locations with limited bandwidth, so plain-text messages are strongly preferred. Also, IETF participants use an exceptionally wide range of computing systems in their IETF activities, so no proprietary (e.g. PC word processor) file format exists that will be readable by everyone on an IETF list. 4.5.1 Preferred Mail Format Users SHOULD send out all messages in the MIME "text/plain" format ONLY. Users SHOULD NOT send out any messages with either proprietary-format attachments (e.g. some word processor format or some viewgraph format) or binary-format attachments (e.g. compressed file, various proprietary application formats) to an IETF mailing list. 4.5.2 Mail Attachments (General) If an attachment is included in a posting to an IETF mailing list, the mail message containing attachment MUST be fully compliant with the IETF MIME specifications. In particular, the attachment MUST be properly marked with MIME headers, so that the readers have a good chance of being able to read the attachment. Usually the best approach to handling attachments is to place the file (which would otherwise be sent as an attachment) onto a publically accessible ftp or http server and just include the URL for the file in one's email to the IETF mailing list. IETF mailing lists MAY automatically or manually strip out HTML, MIME RichText, and/or proprietary-format attachments before Atkinson Expires in 6 months [Page 8]
Internet Draft IETF Mailing List Conventions 6 September 2001 sending on the message. IETF mailing lists MAY automatically or manually bounce messages that contain HTML, MIME RichText, or proprietary-format attachments back to the sender without posting them to the list. Bounce messages SHOULD also have some indication of the reason for the bounce (e.g. The attached message contains HTML, MIME RichText, or proprietary-format attachments and so is not being posted to the ietf-foo mailing list."). 4.5.3 Mail Attachments (Binary format) An IETF mailing list MAY automatically or manually filter out email that contains any form of binary attachment. Lists that do this MAY cause the filtered out messages to be sent to a human moderator for review. That moderator MAY then handle the message as deemed appropriate. 4.5.4 Mail Standards Compliance Any IETF mailing list MAY filter out messages that do not conform and comply with then-current IETF standards-track mail message format RFCs. Examples of IETF mail format standards that apply and are current as of this writing include [RFC-2045], [RFC- 2047], [RFC-2049], [RFC-2821], and [RFC-2822]. Lists that filter out such non-compliant postings SHOULD either cause the filtered out messages to be sent to a human moderator or automatically bounce the posting back to the sender with basic information on why the message was bounced (e.g. "The attached message does not comply with IETF standards-track mail format specifications and so is not being posted to the foo list.") 4.6 Vacation Messages IETF list members MUST NOT misconfigure their mail systems such that "Out of Office" or "Vacation" type messages are automatically sent to IETF mailing lists or to folks who post messages to IETF mailing lists. In some cases, mail software has a default "vacation" configuration that is broken. Users are responsible for correct configuration of their software. Configuration hints for certain widely deployed mail tools are provided in an accompanying informational document [MUA]. IETF mailing list administrators MAY filter out (either manually or automatically) from any IETF mailing list any messages that appear to be "Out of Office" or "Vacation" notifications. Atkinson Expires in 6 months [Page 9]
Internet Draft IETF Mailing List Conventions 6 September 2001 4.7 Other Conventions IETF mailing lists MUST NOT automatically insert a "Reply- to:" header in postings to the mailing list. The automatic presence of that header impedes multi-list conversations when such is appropriate, by automatically cutting off one of the lists from the followup postings. The automatic presence of that header also decreases the signal/noise ratio of the list because it makes it unduly difficult for someone to send a private off-list reply to the author of some note posted to the list. The "Precedence:" header in mail messages is not formally standardised by the IETF. Although it is widely deployed, implementations vary in how they treat that header. Hence, interoperability of that email header is not assured. IETF Mailing List messages MAY or MAY NOT contain a "Precedence:" header. If a "Precedence:" header is present for a given IETF mailing list, then the "Precedence:" value SHOULD be set to "bulk", indicating that the message is not high priority for immediate delivery. New IETF WG mailing lists SHOULD have a list name that clearly indicates both that it is an IETF list and also which precise IETF Working Group uses that list. For example, if there were a new IETF WG whose official IETF WG acronym was "foo", then ideally its mailing list SHOULD be "ietf-foo". For WG lists hosted at ietf.org, then the new mailing list MAY alternately be named just "foo@ietf.org". Each mailing list MUST have a separate address that is used for subscription, unsubscription, or other administrivia. This list address must be formed by taking the posting address and adding "- request" immediately before the "@" symbol. For example, if there were a list using "ietf-foo@nowhere.none" as its posting address, then its subscription and administrivia address would be "ietf-foo- request@nowhere.none". [RFC-2142] A mailing list MAY prefix the subject line with the Working Group's IETF acronym. For example, one MAY have "Subject: [ietf-foo] topic name" automatically appear when the original poster's email had "Subject: topic name". A mailing list relay MAY add a unique "Sender:" mail header for each separate mailing list to facilitate automated sorting of inbound email by subscribers. For example, at present the IETF SNMPv3 WG list automatically adds the line "Sender: owner- snmpv3@lists.tislabs.com" to all postings relayed through that WG's mailing list. This practice is already common. Atkinson Expires in 6 months [Page 10]
Internet Draft IETF Mailing List Conventions 6 September 2001 An IETF mailing list SHOULD add a unique "List-Id:" header compliant with RFC-2919, so that mail client software can use that for sorting incoming email. This practice is not uncommon now and deployment appears to be growing over time. [RFC-2919] An IETF mailing list MAY add the optional list-related headers defined in RFC-2369. This practice is not widespread as of this writing, but the practice might be helpful to list members. [RFC-2369] 5. Security Considerations This document discusses conventions for IETF mailing lists. The goal of IETF mailing lists is to disseminate information to the entire set of Working Group members (mailing list subscribers), so mail to IETF mailing lists does not require confidentiality. Some mail to IETF mailing lists might benefit from authentication. If a mail message is authenticated, an IETF standards-track email message authentication mechanism SHOULD be used. S/MIME is an example of such a standards-track email message authentication mechanism. [RFC- 2633] Computing systems hosting IETF mailing lists ought to be configured using current best commercial practices to prevent break- ins or other security issues from impairing the reliability and availability of the IETF mailing list service. In particular, operating systems and mailing list software SHOULD be kept at current patch levels and SHOULD be configured in a secure manner. Systems hosting official archives of IETF mailing lists ought to be configured using current best commercial practices to prevent break-ins or other security issues from impairing the availability and integrity of the mailing list archives. Additionally, such archives ought to be backed up on a regular basis via methods that are normally considered reliable enough in current best commercial practices (e.g. backed up to magnetic tape or onto some optical media). Mailing list software used with IETF mailing lists MUST be configured in a manner that reduces SPAM by disallowing open relaying of email. [RFC-2635] ACKNOWLEDGMENTS The author would like to thank (in alphabetical order) Harald Alvestrand, Randy Bush, Brian Carpenter, Ned Freed, John Klensin, Tom Narten, Erik Nordmark, and Henning Schulzrinne for their comments and Atkinson Expires in 6 months [Page 11]
Internet Draft IETF Mailing List Conventions 6 September 2001 suggestions on earlier drafts of this document. Vernon Schryver provided help in identifying common mailing list issues. Any grammatical or typographical errors here are the sole responsibility of the author. Kindly note that this draft is written in the English, not American, language. REFERENCES [ANSI86] ANSI, American Standard Code for Information Interchange, Standard X3.4, 1986. [ISO-2022] International Standards Organisation, title here, International Standard 2022, date, place. [RFC-1718] G. Malkin et alia, "The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force", RFC-1718, November 1994. [RFC-2045] N. Freed, et alia, "Multipurpose Internet Mail Extensions (MIME), Part 1, Internet Message Bodies", RFC-2045, November 1996. [RFC-2047] K. Moore, "Multipurpose Internet mail Extensions (MIME), Part 3, Message Header Extensions for non-ASCII Text", RFC-2047, November 1996. [RFC-2049] N. Freed, et alia, "Multipurpose Internet Mail Extensions (MIME), Part 5, Conformance Criteria and Examples", RFC-2049, November 1996. [RFC-2130] C. Weider, et alia, "Report of IAB Character Set Workshop held 29 February - 1 March 1996", RFC-2130, April 1997. [RFC-2142] D. Crocker, "Mailbox Names for Common Services, Roles, & Functions", RFC-2142, May 1997. [RFC-2231] N. Freed & K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, & Continuations", RFC-2231, November 1997. [RFC-2277] H. Alvestrand, "IETF Policy on Character Sets & Languages", RFC-2277, January 1998. [RFC-2279] F. Yergeau, "UTF-8, A Transformation format of ISO-10646", RFC-2279, January 1998. [RFC-2369] G. Neufeld et alia, "Use of URLs as a Meta-Syntax for Core mail List Commands and their Transport through Atkinson Expires in 6 months [Page 12]
Internet Draft IETF Mailing List Conventions 6 September 2001 Message Header Fields", RFC-2369, July 1998. [RFC-2418] S. Bradner, "IETF Working Group Guidelines & Procedures", RFC-2418, September 1996. [RFC-2505] G. Lindberg, "Anti-spam Recommendations for SMTP MTAs", RFC-2505, February 1999. [RFC-2633] B. Ramsdell (Editor), "S/MIME Version 3 Message Specification", RFC-2633, June 1999. [RFC-2635] S. Hambridge & A. Lunde, "Don't Spew: A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam)", RFC-2635, June 1999. [RFC-2821] J. Klensin (Editor), "Simple Mail Transfer Protocol", RFC-2821, April 2001. [RFC-2822] P. Resnick (Editor), "Internet Message Format", RFC-2822, April 2001. [RFC-2919] R. Chandhok & G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC-2919, March 2001. [RFC-3005] S. Harris, "IETF Discussion List Charter", RFC-3005, November 2000. [MUA] R. Atkinson, "Configuration Hints for Common Mail User Agents", Internet-Draft, 31 August 2001. Editor's Address RJ Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA Email: rja@extremenetworks.com Phone: +1 (408)579-2800 Atkinson Expires in 6 months [Page 13]