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: <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)


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

