INTERNET-DRAFT                              Jacob Palme
Network Working Group                         Stockholm
University/KTH                                   Sweden
draft-palme-maillist-02.txt
Expires May 2003                          November 2002





Appropriate Mailing List Behavior


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 will not be 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 on 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 example 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 subscriber 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 on incoming messages to the list
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
branch 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 hierarchically 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 accepted 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 expander.

(2) A variant of (1) 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 specified in sections 1 Nested Lists
and 3 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 occurrence 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 groupware 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:" and "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-good purposes.

Allowing anyone to post to a list may be misused by
spammers. 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 implementers 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 implementation
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 Bruce Lilly , Charles
Lindsey, Erland Sommarskog, Graham Klyne, Maxim Masiutin,
Natalia Syracuse, Ned Freed, Neil Carpender, Rob Chandhok,
Russ Allbery and Simon Josefsson.


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