HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:42:21 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 24 Feb 1999 15:20:00 GMT ETag: "361d6c-45ac-36d418a0" Accept-Ranges: bytes Content-Length: 17836 Connection: close Content-Type: text/plain INTERNET-DRAFT Jacob Palme Network Working Group Stockholm University/KTH draft-palme-maillist-00.txt Sweden Expires August 1999 February 1999 Good Mailing List Behaviour Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society 1998. All Rights Reserved. Abstract This memo summarizes common ideas on how good mailing lists should behave. Some of this is taken from IETF standards, some is not. This memo is not intended, itself, to become a standard, but might, if accepted by the IETF, be published as informational RFC. Table of contents 1. Terminology and Scope 2. Reserved E-mail Addresses 3. Sending Requests to a List Expander 3.1 Subscription Control 3.1.1 To Subscribe 3.1.2 To Unsubscribe 3.2 To Get Information about a List 4. Who may Post to a Mailing List 5. SMTP Envelope 6. Delivery Status Notifications 7. Nested Lists 8. Loop Control 9. List Headers 10. Header Munging 11. Spam Control 12. Groupware 13. Security Considerations 14. Copyright and Disclaimer 15. Acknowledgments 16. References 17. Author's address 1. Terminology and Scope By a mailing list is in this specification meant an automatic agent which has an e-mail address, and which will resend messages, sent to this address via SMTP [RFC821], to all e-mail addresses in a list of subscribers to the mailing list. This process of resending is designated "expansion" of the mailing list. Note that lists which are expanded by the sender's client before submission to the mail transport system are not covered by this specification, even though the word "mailing list" is sometimes used also for such lists. This memo summarizes customary ideas on how good mailing lists should behave. Some of this is taken from IETF standards, some is not. 2. Reserved E-mail Addresses Every mailing list has an e-mail address, named according to the same conventions as for personal mailboxes, and reachable through the same mail transport system as for personal mailboxes. If the e-mail address of a mailing list is "flowers@foo.bar.net" then the following e-mail addresses are also reserved: flowers-request@foo.bar.net flowers-owner@foo.bar.net Messages sent to "flowers-request@foo.bar.net" are usually handled by an automatic process which performs common actions as requested in the message. Sometimes all, or some, such messages are sent to a human administrator of the list. Messages sent to "flowers-owner@foo.bar.net" are sent to a human administrator of the list, or cause a non-delivery notification (see section 6. Delivery Status Notifications) in accordance with [RFC1891] and [RFC1894], if the list administrator is not willing to handle messages sent to this e-mail address. 3. Sending Requests to a List Expander Some, but not all, mailing lists accept commands sent in messages to an automatic agent representing the list expander. The most common address for such an agent is "flowers-request@foo.bar.net", but other addresses occur, such as "list-handler@foo.bar.net". There is no agreed standard on the format of commands in such messages, so it is good practice to accept a number of common variants in either the subject or the text of the message to the agent. Such commands are case-insensitive. Common such commands are: 3.1 Subscription Control The subscription control commands handle the subscription of the SMTP sender of the request (not the name in the From: or Sender: header). The mailing list expander may however find the name of the requestor from the "From:" or "Sender:" field, in order to register the name. This name is however not used in normal list expansion. 3.1.1 To Subscribe Common commands are: sub, subscribe, join. Best is to support all of them. Sometimes the name of the requestor (not the e-mail address) is specified after this command, for example "Subscribe Mary Woodfence". 3.1.2 To Unsubscribe Common unsubscribe commands are: uns, unsubscribe, signoff, sign-off, sign off, delete, leave, cancel, remove, rem, del. Best is to support all of them. 3.2 To Get Information about a List Common commands to retrieve information about a list are: help, review, query, info, information. Best is to support all of them. The information returned may include a textual description of the purpose of the list and of which postings are acceptable to the list. It may also include description of how to subscribe and unsubscribe and where archives of the mailing list are kept. Some lists also return a list of the subscribers of the list. 4. Who may Post to a Mailing List There may be different kinds of restrictions on who may submit messages to a list. Common cases are: - Anyone: Anyone can submit messages to the list (warning, see section 11. Spam Control below). - Members only: Only members are allowed to submit to the list - Moderators only: Only one or more designated moderators may submit to the list Other cases, such as geographical or domain name restrictions, or that only a program, agent or filter may post, also occur. The checking on who may submit to a list is done on the SMTP sender of the message, not on the names in From: or Sender: fields in the heading. If a message is sent to a list, by someone who is not allowed to submit to the list, this can be handled in either of two ways: (a) Forward the message to the moderator of the list, who decides whether to accept or reject the message. (b) Send a non-delivery notification to the SMTP sender of the rejected message, in accordance with [RFC1891] and [RFC1894]. 5. SMTP Envelope The SMTP sender [RFC821] of a message after expansion should be the list owner or maintainer [RFC1123], not the original sender. For small, closed lists, the option of retaining the SMTP sender of the original sender can also occur. 6. Delivery Status Notifications Delivery Status Notification [RFC1891], [RFC1894] requests are usually not forwarded by mailing list expanders. Instead, notifications are sent when the message arrives at the list, and the list maintainer can request notifications when the messages are delivered to list subscribers. An exception to this is small, closed lists, where sometimes Delivery Status Notification requests are forwarded through the list, and the notifications are sent back to the original sender. 7. Nested Lists A subscriber of a mailing list can be another mailing list. This is called "nested lists". Nested lists are used for efficiency reasons and in order to distribute the management of different parts of the subscriber space. Nested lists can have a hierarchical structure or be looped, see Figure 7.1: Figure 7.1 Examples of hierarchical and looped nesting Hierarchical Looped Top list +---<-List A-<-+ | | | | +-----<-----+----->-----+ List B--->--+--<-+ | | | | | Sublist A Sublist B Sublist C +---->------List C | +--<---+---->---+ | | SubList A1 Sublist A2 With a hierarchical structure, contributions intended for all members of the whole set of lists must be sent to the top list. Theoretically, messages intended for only a brach of the tree might be sent to the top of that branch, but this is usually not recommended, because users have difficulty understanding it. A way to stop contributions to other branches than the top list is to designated that the sublists will only accept contributions from their immediate superior in the nesting structure. Looped nesting can cause loops, where the same message circles indefinitely between the lists. How such loops can be avoided is described in section 8. Loop Control. Another alternative is to only use hierarhically nested lists. It is, however, sometimes desirable to allow looped nesting, for example when one or more of the nested lists is a groupware system which accepts local contributions using other submission methods than e-mail (see section 12. Groupware). Looped nesting will also avoid the problem with contributions submitted to the wrong branch of a hierarchical structure. 8. Loop Control Loops can occur because lists are nested (see section 7. Nested Lists). Even if lists are not intended to be nested, it is advisable to employ loop control techniques, because nesting of lists can happen by mistake. Mailing lists commonly employ one or more of the following techniques for avoiding loops and duplicates. It is better to employ more than one of these techniques: (1) Add a "Received:" header to all messages passing the list. If a mailing list recognizes its own "Received:" header in an incoming message, such a message is dropped. No non-delivery notification should be sent in this case (since it might cause another loop). Note: The content of the Received header should be different from what is added by the mail transport agent during ordinary routing of e-mail, since otherwise a message routed by this mail transport agent may at a later time be rejected by the mailing list, even though it has not actually passed the list. (2) Store a data base of the Message-ID-s of messages which have passed the list, and reject incoming messages whose Message-ID is on this list. To achieve loop control, this list need not be kept for a long time, a week is enough. (3) Store a data base of the content or checksum of messages which have passed this list, and use it in the same way as the Message-ID. The advantage with this is that it may work even when a message did not have any Message-ID or when some badly behaving list expander has removed or modified the Message-ID. 9. List Headers A mailing list expander should add headers to the mailing list according to [RFC2369]. Examples: List-Help: (List Instructions) List-Unsubscribe: List-Subscribe: List-Archive: List-Post: (Postings are Moderated) List-Owner: (Grant Neufeld) 10. Header Munging Apart from what is specifed in sections 8. Loop Control and 9. List Headers, a mailing list expander should not in any way modify the heading of a message. In particular, the list should not change the Message-ID, not add "Resent-", "From:", "Sender:", "Auto-Submitted:" or "Reply-To:". The practice to add the e-mail address of the list in a "Reply-To:" header is common, but is not recommended. Instead, use the "List-Post:" command from [RFC2369]. 11. Spam Control Many mailing list expanders employ various methods to counteract spamming. Examples of such methods are: (1) Do not allow non-subscribers to post to the list. (2) Check all submissions by a human moderator before acceptance. (3) Employ various filtering techniques to recognize spams, such as multiple occurence of the same message sent to different mailing lists. Since such techniques may reject legitimate messages, rejected messages should be passed to a human moderator for checking. 12. Groupware A groupware product may appear as a mailing list to people accessing it via e-mail, and may at the same time appear as a forum to people accessing it via other user interfaces, such as HTTP [RFC2068]/HTML [RFC1866] or own protocols for this particular groupware. Such groupware products may allow addition of e-mail addresses as subscribers to a forum in the same way as groupware users are added as members of the forum. 13. Security Considerations Allowing people to retrieve lists of members of mailing lists may be misused by spammers and other people using these names for no-goood purposes. Allowing anyone to post to a list may be misused by spammers. See see section 11. Spam Control. Loop control may incur some risk of messages disappearing, but this should normally not happen. Loop control with Message-ID can be misused to stop unwanted messages, but this would be difficult, since the offender must send the false message with the same Message-ID before the message to be stopped. Spam control may incur some risk of messages disappearing. A way to reduce this risk is to forward rejected messages to a human moderator for checking. A well-known problem with moderated mailing lists is that if the moderator is sick, on holiday, or otherwise occupied, the list ceases to work. 14. Copyright and Disclaimer The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat." The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 15. Acknowledgments Many people have helped with the production of this document. Of special value have been ..... 16. References [RFC821] Simple Mail Transfer Protocol. J. Postel. Aug-01- 1982. (Format: TXT=124482 bytes) (Obsoletes RFC0788) (Also STD0010) (Status: STANDARD) [RFC822] Standard for the format of ARPA Internet text messages. D. Crocker. Aug-13-1982. (Format: TXT=109200 bytes) (Obsoletes RFC0733) (Updated by RFC1123, RFC1138, RFC1148, RFC1327, RFC2156) (Also STD0011) (Status: STANDARD) [RFC1123] Requirements for Internet hosts - application and support. R.T. Braden. Oct-01-1989. (Format: TXT=245503 bytes) (Updates RFC0822) (Updated by RFC2181) (Status: STANDARD) [RFC1866] Hypertext Markup Language - 2.0. T. Berners-Lee & D. Connolly. November 1995. (Format: TXT=146904 bytes) (Status: PROPOSED STANDARD) [RFC1891] SMTP Service Extension for Delivery Status Notifications. K. Moore. January 1996. (Format: TXT=65192 bytes) (Status: PROPOSED STANDARD) [RFC1894] An Extensible Message Format for Delivery Status Notifications. K. Moore & G. Vaudreuil. January 1996. (Format: TXT=77462 bytes) (Status: PROPOSED STANDARD) [RFC2068] Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 1997. (Format: TXT=378114 bytes) (Status: PROPOSED STANDARD) [RFC2369] The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields. G. Neufeld, J. Baer. July 1998. (Format: TXT=30853 bytes) (Status: PROPOSED STANDARD) 17. Author's address Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Skeppargatan 73 E-mail: jpalme@dsv.su.se S-115 30 Stockholm, Sweden