Network Working Group Keith Moore
Internet-Draft University of Tennessee
Expires: 25 March 1998 25 September 1997
Requirements for IETF Mailing Lists
draft-moore-maillist-req-01.txt
1. Status of this Memo
This document is an Internet-Draft. 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 not appropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Following review by interested parties, the author intends to submit
this document to the IESG for consideration as a Best Current Practice.
2. Abstract
This document describes requirements for all IETF official mailing
lists, including (but not limited to) mailing lists used for working
group discussion.
3. Introduction
There is a wide variety of practice in the administration and processing
of mailing lists, and there are several existing software packages which
enforce or encourage different practices. In the interest of uniformity
of user interfaces across IETF discussions, and of robust handling of
mailing list anomalies, this memo outlines practices which are required
for all IETF mailing lists.
NOTE: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in
Moore Expires 25 March 1998 [Page 1]
IETF Mailing List Requirements 25 September 1997
this document, when written in all upper-case, are to be interpreted as
described in [RFC-2119]. When these words are written using lower-case
letters, they are to be interpreted as in ordinary English usage.
4. Administration
Each IETF mailing list SHALL have a human who is directly responsible
for maintaining the list. The list maintainer shall be responsible for
routine administrative requests (e.g. subscribe, unsubscribe, or change-
of-address), deleting subscribers for whom mail is persistently
undeliverable, thwarting mail loops due to broken subscriber software,
and taking other action as necessary to assure continued operation of
the mailing list.
Each IETF mailing list SHALL have (at least) two addresses: one for
submissions to be redistributed to the list subscribers, and another for
administrative requests (e.g. subscription requests, deletions, address
changes). A mailing list MAY have other addresses, for instance, to
access a mail-based robot which provides back issues of the list.
If the address used for subscriptions is of the form <listname@y.z>, the
address used for administrative requests SHALL be <listname-
REQUEST@y.z>. This address SHALL be the primary point-of-contact for
administrative requests. It is NOT sufficient for a list to respond to
all mail sent to the -REQUEST address, with instructions to use a list
server at a different address.
Administrative requests which are sent to the -REQUEST address SHOULD be
honored, or at least answered, within two working days of receipt. For
the purpose of this requirement, days on which IETF meetings are held
are not considered working days. All administrative requests SHOULD be
acknowledged by sending an electronic mail "reply" to the requestor.
Automatic list server software MAY be used to handle routine
administrative requests sent to the -REQUEST address. If such software
is used, it MUST forward unrecognized requests to the list maintainer.
Requests thus forwarded SHOULD be answered within two working days.
The address <Postmaster@y.z> SHALL also be valid, though this address
SHOULD NOT normally be used for routine administrative requests
associated with the mailing list. Mail sent to the Postmaster of the
list server SHOULD be answered within two working days.
A subscriber SHOULD be removed by the list maintainer if mail from the
list for that subscriber is returned as undeliverable on more than three
separate days within a thirty-day period. If a subscriber is removed
for this reason, the list maintainer SHOULD attempt to send a message to
that (former) subscriber notifying him/her that he/she has been removed
Moore Expires 25 March 1998 [Page 2]
IETF Mailing List Requirements 25 September 1997
from the list.
A subscriber SHALL be removed by the list maintainer,
+ if that subscriber's email software automatically returns any kind
of response message to the entire mailing list (be it a nondelivery
notification, delivery notification, delay notification, receipt
notification, vacation notification, change-of-address notifica-
tion, or any other kind of automatic response), OR
+ if the subscriber's mailer sends an automatic response messages to
the addresses on the To field, Cc field, or any Resent-* field of a
message sent to the list, OR
+ if the subscriber's mailer causes forwarding loops or repeatedly
spews messages to the list.
If a subscriber is removed from the list for one of the above reasons,
the list maintainer SHALL immediately inform the subscriber of the
reason for the removal. The subscription SHALL NOT be restored to the
list until the list maintainer has assurance that the subscriber has
taken appropriate corrective action.
When the list administrator receives a message which is obviously
intended as a submission to the list, and which was sent to either the
-REQUEST address or to the SMTP MAIL FROM address used to redistribute
messages (see section 6), it SHOULD NOT be forwarded to list
subscribers. Instead, it SHOULD be returned to the originator with
instructions to send that message to the correct list submission
address.
5. Header munging
Two types of lists are considered here: Non-digest lists forward each
message individually to list subscribers. Digest lists collect inbound
messages until some number of messages have been received or some time
interval has elapsed, and bundle those collected messages into a single
message which is then sent to list subscribers. A single discussion may
be available in both non-digest and digest form; however, every IETF
list SHALL be available in non-digest form.
5.1. Header munging for non-digest lists
In general, a non-digest list is expected to preserve all header fields
in the input message when redistributing that message to list
subscribers. In particular:
Moore Expires 25 March 1998 [Page 3]
IETF Mailing List Requirements 25 September 1997
+ A list MUST NOT alter the To, Cc, Sender, From, Reply-To, Message-
Id, In-Reply-To, References, Date, or Received fields of a message
redistributed to list subscribers.
+ A list MUST NOT alter or delete a header field without specific
instructions to do so, or simply because it does not recognize the
field name.
Exceptions and/or clarifications for specific cases appear below.
5.1.1. Reply-To
A list MUST NOT remove or alter a Reply-To field supplied by the
originator of the message.
A list SHOULD NOT add a Reply-To field to a message that lacks one. For
a working group mailing list, exceptions to this rule SHALL be approved
by the Area Director responsible for that group.
DISCUSSION: On most IETF lists it is highly desirable to allow extended
conversations between one or more mailing lists and one or more parties
who may not be subscribers of such lists. A list which supplies its own
Reply-To field defeats that functionality.
5.1.2. Subject field
A list MUST NOT alter the Subject field of a message redistributed to
list subscribers.
EXCEPTION: A list MAY prepend a short name of the mailing list to the
Subject line. The short name MUST be the same for all messages sent to
that list -- for example, it MUST NOT contain a sequence number.
For any list which prepends the short name of the list:
+ The short name MUST be enclosed in square brackets.
+ The list MUST remove its short name from the Subject field of any
inbound replies, before prepending the short name.
Example: For a list named "XYZ", a message containing the header field
Subject: foo
would have that rewritten to read
Moore Expires 25 March 1998 [Page 4]
IETF Mailing List Requirements 25 September 1997
Subject: [XYZ] foo
before being sent to the list. A reply to that message might contain
the header field
Subject: Re: [XYZ] foo
Rather than simply prepending "[XYZ] " to that subject, the list MUST
first remove the "[XYZ] " from the reply (yielding "Re: foo"). The list
may then prepend its name to the result, producing
Subject: [XYZ] Re: foo
5.1.3. Sender field
A list MUST NOT add a Sender header field to a message redistributed to
list subscribers. A list MUST NOT alter or remove a Sender field which
was originally present in the message.
DISCUSSION: Many lists add a Sender field of some kind which indicates
either the address of the list maintainer, or the software which handles
the mailing list, and this field is widely used by subscribers of those
lists (e.g. for collation of mail from different lists). Such use
defeats the original purpose of Sender, which is to identify the person
who originated the message. (RFC 822 says "person, system, or process",
but neither systems nor processes should be sending messages to IETF
lists.)
Automatic collation of mail can be accomplished using the Return-Path
field. Collation may also be accomplished using one of the List-*
fields, or a tag in the Subject field, if the list supports either of
these features.
5.1.4. Message Disposition Notification processing
A list MAY issue a Message Disposition Notification [MDN] on behalf of
the list if it receives a message with a Disposition-Notification-To
field. If such a notification is issued, the list MUST remove the
Disposition-Notification-To field from the message before it is
redistributed to list subscribers.
Moore Expires 25 March 1998 [Page 5]
IETF Mailing List Requirements 25 September 1997
5.1.5. List-* fields
A list MAY add one or more List-* fields such as those defined in
[LISTSPEC] or future standards-track RFCs.
5.1.6. Other fields commonly added by mailing lists
A list MUST NOT add an Errors-To field to messages distributed to list
subscribers. This practice can interfere with normal error handling.
A list SHOULD NOT add a Precedence header field to a message
redistributed to the list subscribers. Due to a wide variation in the
handling of the Precedence field, inclusion of this field can result in
message delivery failures.
5.1.7. Removal of undesirable fields
A list SHOULD remove any of the following header fields from any message
redistributed to a list:
+ Content-Length (nonstandard, ill-defined, and probably inaccurate),
+ Errors-To (conflicts with SMTP MAIL FROM and Return-Path),
+ Precedence (nonstandard, use varies widely and causes some mail
software to break),
+ Return-Path (should not be present in a message before final deliv-
ery).
+ Disposition-Notification-To, Return-Receipt-To, X-Confirm-Reading-
To, or any other field which is intended to cause the recipient's
mail system to send a receipt notification or delivery report.
+ Any List-* header fields present in the original message. (However
a list is allowed to add its own List-* header fields.)
5.2. Format of digest messages
Digests SHOULD be in MIME format, as in the example in [RFC-2046],
section 5.1.5. In particular, the structure of a digest message SHOULD
be:
Moore Expires 25 March 1998 [Page 6]
IETF Mailing List Requirements 25 September 1997
multipart/mixed
text/plain (table of contents)
multipart/digest
message/rfc822 (message 1)
message/rfc822 (message 2)
message/rfc822 (message 3)
...
NOTE: Some MIME mail readers, and some foreign mail systems which are
gatewayed to MIME, do not effectively present multipart/digest format.
Participants who are stuck using such mail readers should subscribe to
the non-digest version of the list.
For some degree of compatibility with mail readers that understand
[RFC-1153], the "boundary" parameter of the inner multipart/digest MAY
be specified as 28 "-" characters.
NOTE: the actual boundary marker consists of 2 "-" characters plus the
value of the "boundary" parameter, thus messages will actually be
separated by 30 "-" characters as per RFC 1153.
If this boundary marker is used, a line in the message text beginning
with 30 "-" characters MUST be altered in some way to prevent its confu-
sion with a boundary marker, but which does not change the meaning of
the message. This MAY be accomplished by changing the first "-" to a
SPACE.
The top-level header of a digest message MAY have a Sender field
containing an address for the list maintainer. This address MAY be an
alias (say owner-FOO-DIGEST@somehost.org), but it MUST NOT be the
address used for posting.
The top-level header of a digest message MAY have one or more List-*
fields such as defined in [LISTSPEC] or future standards-track RFCs.
The top-level header MUST NOT contain an Errors-to field, and SHOULD NOT
contain a Precedence field.
5.2.1 Header munging for component messages
For the component messages, the following header fields MUST be retained
if present in the original message: MIME-Version, Content-Type, Content-
Transfer-Encoding, In-Reply-To, Date, Sender, From, Reply-To, To, Cc,
Subject, Message-Id, Keywords. It is RECOMMENDED that the fields be
included in this order. These fields MUST NOT be modified from the
original message. Other fields SHOULD be omitted.
Moore Expires 25 March 1998 [Page 7]
IETF Mailing List Requirements 25 September 1997
Exceptions:
+ A Content-Type field specifying "text/plain; charset=US-ASCII",
with no other parameters, MAY be omitted.
+ A Content-Transfer-Encoding of 7BIT MAY be omitted.
+ If neither Content-Type nor Content-Transfer-Encoding are present,
the MIME-Version field MAY be omitted.
+ The Content-Transfer-Encoding of a component message MAY be
changed, for example, to allow transmission of the digest over
7-bit only channels.
6. Envelope munging
A list MUST set the SMTP MAIL FROM address to point to the address of
the list maintainer (or a robot acting on his or her behalf) on all
messages redistributed to list subscribers. This address MUST NOT be
the same as the list submission address, and mail to this address MUST
be processed separately from normal submissions to the list. For a list
submission address of <listname@y.z>, a suggested MAIL FROM address is
<OWNER-listname@y.z>.
DISCUSSION: Some list handling software attempts to heuristically
distinguish between list submissions, administrative requests, and
automatically generaeted responses such as nondelivery reports. While
such heuristics can sometimes identify misdirected subscribe messages,
or thwart mail loops caused by certainly especially brain-damaged
mailers, experience has shown that they are not sufficiently reliable to
obviate the need for a separate address, and separate processing of each
of these categories of mail.
The MAIL FROM address SHOULD be fixed for any particular list; a
separate MAIL FROM address SHOULD NOT be assigned on a per-recipient or
per-delivery basis.
DISCUSSION: Some list handling software assigns a separate MAIL FROM
address for each subscriber, so that nondelivery reports sent to the
MAIL FROM address automatically identify the subscriber for whom
delivery has failed. While this technique is useful in some cases, it
is not recommended for mailing lists because it requires that the
message be transmitted separately to each subscriber. It may also
interfere with other uses of MAIL FROM and Return-Path.
Even if this technique is used, it is still necessary to interpret
messages returned to that address, because MAIL FROM and Return-Path are
Moore Expires 25 March 1998 [Page 8]
IETF Mailing List Requirements 25 September 1997
used for other kinds of mail besides permanent nondelivery reports.
7. Filtering
A list MAY attempt to automatically filter out administrative requests
("subscribe", "help", etc.), to prevent such messages from being sent to
the list subscribers. Mail with an invalid sender address (e.g. illegal
address syntax, or domain not listed in DNS) MAY also be filtered.
A list MAY attempt to automatically filter out mass mailed commercial or
political advertisements, chain letters, messages describing "make money
fast" schemes, requests to send postcards to a dying child, or other
traffic whose content is obviously inappropriate for, and not
specifically intended for, the discussion on the list.
Such automatically filtered traffic MUST be sent to the list
administrator or an appropriate moderator for review and possible
resubmission to the list, just in case it was mistakenly selected by the
filter. Ordinary misdirected messages SHOULD be returned to the sender
to inform the sender that the message was not delivered. However,
messages which are inappropriate and obviously not specifically intended
for the list, SHOULD NOT be returned to the sender.
Most IETF mailing lists (including all working group lists) are public
and open to any individual who wishes to contribute to the discussion.
While effective contribution to a list discussion generally requires
that the contributor read the list traffic, some contributors may prefer
to do so by other means than being subscribed to the list - say by
perusing the list archives. In addition, some subscribers may receive
their list mail at one address (perhaps one specifically dedicated to
traffic from that list) but send mail to the list using a different From
address.
Public IETF mailing lists therefore SHOULD NOT reject a message (i.e.
refuse to distribute it to the list subscribers) simply because the
sender's address does not appear on the list of subscribers. Any public
IETF list that performs such filtering:
+ MUST forward filtered messages to the list administrator or an
appointed moderator for review and possible resubmission to the
list (rather than simply bouncing the message),
+ MUST provide a mechanism to allow nonsubscribers to be added to a
list of addresses which are allowed to post messages to the list
(thus bypassing the nonsubscriber filter)
Moore Expires 25 March 1998 [Page 9]
IETF Mailing List Requirements 25 September 1997
+ MUST notify a nonsubscriber sender of such a message that his mail
is being forwarded to the moderator for review, along with an
explanation of how the sender may request to be added to the "non-
subscribers who are allowed to post" list.
A list MAY attempt to filter out malformed messages which are likely to
cause problems with recipients' mail software. Examples include
messages with non-ASCII characters in the message header, illegal RFC
2047 encoded-words in the message header, illegal MIME boundary markers,
or 8bit messages labelled as 7bit. Such messages SHOULD be immediately
returned to the sender as nondeliverable.
8. Responsibilities of a list subscriber
List subscribers are expected to send administrative requests to the
-REQUEST address and not to the list submission address.
List subscribers are expected to send submissions to the primary list
submission address, rather than to any other address. List subscribers
SHOULD NOT send submissions to any of:
+ an "alias" for the list submission address,
+ the list maintainer,
+ the -REQUEST address,
+ the address in the Return-Path header field,
+ the address in the Sender header field (if any),
+ the so-called "From " address (on systems that use the UNIX "mbox"
format), OR
+ the SMTP envelope return address. (This could happen if the sub-
scriber's Internet access is via a mail gateway which derives its
notion of "From" or "Sender" from SMTP.)
List subscribers are expected to choose descriptive Subject lines for
messages (including replies) that they submit to the list. This is
especially important for a list member who subscribes to the digest
version of a list, where the top-level Subject is often "XXX-Digest,
issue YYY".
List subscribers are expected to prevent robots which automatically send
notifications on their behalf, from responding to messages from mailing
lists. (e.g., automatically generated "vacation" notices, receipt
Moore Expires 25 March 1998 [Page 10]
IETF Mailing List Requirements 25 September 1997
notifications, message disposition notifications, change-of-address
notices, or "I'm behind in reading my mail" notices)
Autoresponders used by list subscribers SHOULD send responses to the
envelope return address or the address in the Return-Path header field.
Autoresponders MUST NOT send responses to any address obtained from a
To, Cc, Resent-To, Resent-Cc, or Reply-To field. (NOTE: the MUST NOT
prohibition against use of Reply-To is necessary to prevent loops for
lists which put the list submission address in the Reply-To field.)
If a list subscriber receives a nondelivery report as a result of
submitting a message to the list, say from a list subscriber whose
address is no longer valid, the originator SHOULD forward that
nondelivery report to the list maintainer. (This shouldn't happen, but
it happens anyway due to broken mail software.)
There are other requirements on the content of messages sent to an IETF
list, e.g., the sender should be civil to other list participants, IETF
lists should not be used for advertising, etc. Such requirements are
not within the scope of this memo, and their omission from this memo
should not be taken to mean that they do not exist.
9. List archives
According to IETF standards procedures, each working group mailing list
MUST maintain an archive of messages sent to that list. Archived
messages MUST be available in the format sent to subscribers of the non-
digested list, so that they may be downloaded into one's private message
store. The archives may be accessible using FTP or HTTP or both. If
there is no FTP-accessible archive, the HTTP archive MUST permit
downloading of all messages to the list in a small number of transfers.
Other means of accessing list archives MAY be provided, for instance,
via IMAP or as hypertext.
A useful format for archives is:
+ a single directory contains all of the archived mail for a particu-
lar list, and the directory only contains mail for that list.
+ Within that directory, archived mail for a particular year and
month is collected in a single file named for that year and month.
The year should appear first, so that the individual files will
appear in time order when sorted by name. Four digits MUST be used
to represent the year. (e.g. "1997-09"). File names SHOULD be
short.
+ Within a file, messages are concatenated together in the order they
are received, each message preceded by a line of the form:
Moore Expires 25 March 1998 [Page 11]
IETF Mailing List Requirements 25 September 1997
From sender@some.domain Wed Sep 25 00:01:34 1997
which is immediately followed by the RFC 822 message header. A
blank line is appended to the message body. If this format is
used, it will be necessary to "escape" messages containing "From "
at the beginning of a line. This may be accomplished by changing
"From " to ">From ", or (preferably) by changing the content-trans-
fer-encoding of the message so that "From " never appears.
While not a standard, this format is understood by many user agents.
MIME digest format is also acceptable, but the digests used for
archiving SHOULD contain all message header fields which were sent to
the non-digest list.
10. Security Considerations
This section discusses known attacks on mailing lists, some possible
effects of such attacks, and suggested countermeasures.
10.1. Forged requests
It is possible to forge administrative requests (subscribe, unsubscribe,
change address) on behalf of unsuspecting parties. A malicious forgery
might be used to deny a subscriber access to the list traffic, or to
send list traffic to someone who did not wish to receive it.
All successful administrative requests MUST be acknowledged to both the
requester (i.e. the user whose address appears in the From header field
of the request), and the subscriber address(es) affected by the request
(if different from that in the From field). For a change-of-address
request, acknowledgement MUST be sent to both the old and new subscriber
addresses, in addition to the addresses in the header From field.
To prevent some kinds of loops, unsuccessful administrative requests
SHOULD NOT be acknowledged to other than the single address of the
requestor.
10.2. Unsolicited mass mailings
Even small amounts of bulk mail, (consisting of content which is neither
appropriate for the list, nor specifically intended for the list), can
disrupt the normal functioning of a list. In extreme cases, mass
mailings can be indistinguishable from a denial-of-service attack.
A variety of heuristics can be employed to discourage such attack,
including:
Moore Expires 25 March 1998 [Page 12]
IETF Mailing List Requirements 25 September 1997
+ Sending a confirmation message to first-time or occasional posters,
requiring a reply before their submission will be forwarded to the
list.
+ Verification of the From address of the subject message (e.g. syn-
tax, domain listed in DNS)
+ Verification that the From address is a subscriber of the list, or
on the list's "allow postings from" list.
As attacks on lists are becoming more sophisticated, countermeasures
will necessarily also become more sophisticated. It would therefore be
inappropriate for this memo to specify which countermeasures should be
used, or to limit use of such countermeasures.
10.3. Mail loops and flooding
Malicious or clueless individuals can create mail loops by causing list
submissions to be sent back to the list. While accidental loops can
often be detected by examining message content, deliberate attacks may
not contain such clues. Lists SHOULD therefore employ mechanisms such
as rate limiting to limit the effect of loops and flooding attacks.
10.4. Automatic probing of list subscribers
Some list exploders provide commands which allow attackers to obtain the
addresses of list subscribers. Attackers may use such commands, for
instance, to gather lists of addresses for unsolicited mass mailings, or
to automatically compile lists of people interested in certain topics.
The list of subscribers SHOULD NOT be available without human
intervention -- either via the SMTP VRFY or EXPN commands, or otherwise
from the list processor.
DISCUSSION: This supersedes the rule in [RFC-2026] requiring that
mailing lists be accessable. EXPN and similar mechanisms are
increasingly used by hostile parties, to collect lists of addresses to
be used as targets of unsolicited bulk mailing.
Requests for the membership of any official IETF mailing list (for
instance that of an active working group) SHOULD be sent to the list
maintainer, or to the IETF Secretariat.
Moore Expires 25 March 1998 [Page 13]
IETF Mailing List Requirements 25 September 1997
11. Acknowledgements
The author wishes to thank Harald Alvestrand, Ad Bresser, Ned Freed,
Randall Gellens, John Klensin, Chip Rosenthal, Bonnie Scott, and Klaus
Weide for their comments in response to earlier drafts of this memo.
12. References
[LISTSPEC]
Neufeld, Grant, and Joshua D. Baer. "The Use of URLs as Meta-Syn-
tax for Core Mail List Commands and their Transport through Message
Header Fields". Internet-Draft <draft-baer-listspec-01.txt>, 22
March 1997.
[MDN]
Fajman, Roger. "An Extensible Message Format for Message Disposi-
tion Notifications". Internet-Draft <draft-ietf-receipt-
mdn-05.txt>, 29 July 1997.
[RFC-1153]
Wancho, F. "Digest Message Format". RFC 1153, April 1990.
[RFC-2026]
Bradner, S. "The Internet Standards Process -- Revision 3". RFC
2026, BCP 9, October 1996.
[RFC-2046]
Freed, N., and N. Borenstein. "Multipurpose Internet Mail Exten-
sions (MIME) Part Two: Media Types". RFC 2046, November 1996.
[RFC-2119]
Bradner, S. "Key words for use in RFCs to Indicate Requirements
Levels", RFC 2119, BCP 14, March 1997.
13. Author's Address
Keith Moore <moore@cs.utk.edu>
Moore Expires 25 March 1998 [Page 14]