INTERNET-DRAFT Jacob Palme Network Working Group Stockholm University/KTH draft-palme-maillist-01.txt Sweden Expires November 2001 May 2001 Appropriate 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 2001. 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 or as a Best Current Practice (BCP) document. 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. Mail Bombing 13. Groupware 14. Security Considerations 15. Copyright and Disclaimer 16. Acknowledgments 17. References 18. 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 [RFC2821], 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 flowers-errors@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. Messages sent to "flowers-errors@foo.bar.net" are usually handled by a person or a process which handles routine maintenance of a list, such as removal of list members who persistently (for at least 3-4 days) return negative Delivery Status Notifications. The e-mail address "flowers-errors@foo.bar.net" should in this case also be put as the SMTP sender when expanding messages from the mailing lists to its members. If there is no person or process doing such maintenance, the SMTP sender for expanded messages may instead be empty. 3. List Headers A mailing list expander should add headers to the mailing list according to [RFC2369] and [RFC2919]. Examples: List-Help: <mailto:flowers@foo.net?subject=help> (List Instructions) List-Unsubscribe: <mailto: flowers@foo.net?subject=unsubscribe> List-Subscribe: <mailto: flowers@foo.net?subject=subscribe> List-Archive: <http://www.foo.net/flowers-archive> List-Post: <mailto:moderator@foo.net> (Postings are Moderated) List-Owner: <mailto:grant@foo.net> (Grant Neufeld) List-Id: List Header Mailing List <list-header.nisto.com> Note that the "List-" headers can either contain an e-mail address, to which requests are sent in a format specified in the "List-" command, for example List-Unsubscribe: <mailto: flowers@foo.net?subject=unsubscribe> Or can contain an URL of a web page, on which a subscription request can be made. 4. 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. Information about which format is used by a particular mailing list expander is specified in the "List-" headers, see section 3 List Headers above. Common such commands are: 4.1 Subscription Control The subscription control commands handle the subscription of the SMTP sender of the request (not the subscription for 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. The actual address for this agent or web page is specified in "List-" headers, see section 3 List Headers above. 4.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". Other systems require the e-mail address to be specified in the subscribe command, or a full e-mail user-friendly name and address in the format used in From: e-mail header, like "Subscribe Mary Woodfence <maryw@foo.bar>" 4.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. 4.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. The actual address for the agent or web page returning such information is specified in "List-" headers, see section 3 List Headers above. 5. Mail Bombing Some people will add other people's e-mail addresses to mailing lists without their permission, causing them to be bombarded with mail they do not want. To counteract this, good practice is that a mailing list expander, which receives a request to add an e-mail address to the mailing list, should send a message to this e-mail address, asking if the recipient really wants to be added to the list, and putting a secret codeword in the "Subject:". If no confirmatory reply arrives with this codeword in its "Subject:" then the person is not permanently added to the list. 6. 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 12. Spam Control below). - Subscribers only: Only subscribers 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. A sublist in a nested mailing list structure can be set to reject all postings which do not come from its superlist. The checking on who may submit to a list is usually done on the SMTP sender of the message, not on the names in From: or Sender: fields in the heading, because this name is a little more difficult to fake. Note however, that mail which is forwarded through nested mailing lists, will have the administrator of the previous list as SMTP sender. If the previous list does not perform filtering, and a list often gets messages from other mailing lists, filtering inom the From: header may be necessary. 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. This option should only be used if there really does exist a moderator who really performs this task on a regular basis. (b) Send a non-delivery notification to the SMTP sender of the rejected message, in accordance with [RFC1891] and [RFC1894]. 7. SMTP Envelope The SMTP sender [RFC2821] of a message after expansion should be the list owner or maintainer [RFC1123], not the original sender, for exmaple the mailing list flowers@foo.bar.net may set flowers- errors@foo.bar.net as the SMTP sender of expanded messages. When several mailing lists are nested, each list in sequence, which expands a message, should set its owner or maintainer as SMTP sender, so that the SMTP sender always indicates the owner of the latest list expander, through which the message has passed. For small, closed lists, the option of retaining the SMTP sender of the original sender can also occur. The SMTP recipients should be the subscribers of the mailing list doing the expansion. A mailing list may send to all recipients in one envelope (SMTP submission) or may split the recipients into multiple submissions, like one submission for each recipient. For large lists, it may be best to split the recipients with only 99 RCPT TO for each submission, since some SMTP servers may not accept more than 99 recipients. Some mailing list have a facility that a subscriper can stay a subscriber, but not get submissions sent. Other mailing list allow subscribers to get submissions in different formats, such as digests of all messages once a day or once a week, or only a list of URLs to retrieve the new messages, not the full text. Such options will mean that the content of the messages sent via SMTP is different for different subscribers. 8. 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. 9. 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-<-+ V V ^ ^ +-----<-----+----->-----+ List B--->--+--<-+ V V V V ^ Sublist A Sublist B Sublist C +---->------List C V +--<---+---->---+ V V SubList A1 Sublist A2 With a hierarchical structure, contributions intended for all subscribers 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 Mail Bombing). Looped nesting will also avoid the problem with contributions submitted to the wrong branch of a hierarchical structure. A common practice is to accept contributions only to the top list in a nested structure of mailing lists. This would mean that sublists will only accept contributions coming from the superior list. In a few cases, submissions are acceted to sublists, intended only to a subset of the main list, but this practice is usually not recommended. 10. 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) A variant of this which is *not* recommended is to use "Resent-" headers or "List-" headers. A problem with such headers is that they may not always correctly show the whole path which the message has gone through. It is normally not desirable that mailing lists add "Resent-" headers to messages, see section 11: Header Munging and [RFC2822]. (3) Store a list 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 may be enough in most cases. (4) Store a list 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. 11. Header Munging Apart from what is specifed in sections 9. Loop Control and 10. 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:", and should not remove or modify "Received:" headers (but may add an additional "Received:" header with information about the mailing list expansion). 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]. 12. 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. 13. 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. A message created in a groupware system, and sent out via e-mail, should include the e-mail address of the forum (groupware discussion group) in a "To:" och "Cc:" header, as well as in the List-headers according to [RFC2369] and [RFC 2919]. One particular class of Groupware is Usenet News. This document is not written to specially cater to the issues of gatewaying between e-mail and Usenet News. Such gatewaying is a complex issue, which requires special consideration for that particular case. 14. Security Considerations Allowing people to retrieve lists of subscribers 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 12. 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. Some mailing list try to solve this problem by having multiple moderators, so that another moderator can take over when one of them cannot perform the moderating task. 15. 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. 16. Acknowledgments Many people have helped with the production of this document. Of special value have been ..... 17. 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) [RFC2919] List-Id: A Structured Field and Namespace for the Identification of Mailing Lists, By R. Chandhok and G. Wegner, March 2001 (Status: PROPOSED STANDARD). [RFC2821] Simple Mail Transfer Protocol, by J. Klensin, April 2001. [RFC2822] Internet Message Format, by P. Resnick, April 2001. 18. 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