Last update: August 2, 1998
Grant Neufeld - <firstname.lastname@example.org>
The internet draft describing the List-Help, List-Subscribe, List-Unsubscribe, List-Post, List-Owner and List-Archive header fields has been approved by the IESG/IETF as RFC 2369.
Thanks to everyone who worked on and supported this effort!
Introductory Documents and Instructions
Technical Documents, Proposals and Discussion
Mailing List -
The email list ("list-header") for work on this project has been shut down, since the project is complete.
An incomplete archive of the email list is available.
Having a standard is only half the challenge. Now we have to get software developers, and mailing list managers, to implement support.
To that end, here are some form letters that can be used to contact developers and listmoms. Please Cc email@example.com on all such letters you send out. Thanks for your support!
Note: Some of the discussion here is not (and will not be) on the standards track, and as such is subject to tremendous, contradictory change.
This document is "mission control" for discussion about making email list services easier and more consistent to access by end users.
Things we're examining include: designing a meta-syntax for describing list server command syntaxes, as well as structuring protocols for communicating that meta-syntax to email client software (which can use the information to make it easy for the user to issue list server commands such as subscribe and unusbscribe).
It is expected that by implementing a standard format for list server identifier headers, mail client software developers could implement interface features to make mail list control easier for users (when the headers are present). For example, a GUI mail client could potentially offer buttons to un/subscribe, get list info, or switch to digest mode.
Since this document is a general discussion paper, most of the possibilities that have been suggested are included here (hence the clutter). After the discussion progresses, the suggestions will certainly be trimmed down to a smaller number for acutal use.
Because they are easy for many (even if not all) list servers to implement. They also mean no modification is required of the message body.
Because most mail clients currently either don't support MIME or are not
equipped to handle such specialized parts - resulting in problems for
It is also not as easy for many list servers to implement MIME as it is to implement new headers.
However, we are working on defining a MIME part for list command information.
Because users who have unsubscribe (before going on vacation, or for whatever other reason) may want to resubscribe to a list. Or, a message may be forwarded/bounced from a subscriber to a non-subscriber. Or, the user may change addresses and want to subscribe from their new address. Etc.
Subscribing is one of the most - if not the most - commonly used list actions. Making it easier to perform can have a large cumulative effect in terms of making list access easier for users (and reducing related support requests).
subscribe list [username]"?
If a server requiring variable support in their command syntax implements command URLs for their service (perhaps including plain-text square bracket enclosed variable substitution instructions for the user, such as "[your first name]"), they must at the same time implement support for handling invalid responses where the variable hasn't been substituted but instead has been included as plaintext.
If the server software can't handle that sort of invalid response, they must not produce the command URLs that can generate it. Otherwise, they're just asking for trouble, IMHO.
Note: These are just 'points for discussion' and open questions. This is not part of the proposal.
An important consideration in this discussion is avoiding adding a tonne of new headers and 'bulking up' messages that are already often heavy with headers and other administrative info (e.g., list info footers).
We still need to figure out how to handle 'partner' lists such as when there is a
separate digest lists and users need to unsub the regular list and sub the digest
list in order to switch to digests.
This leads into the more general question of handling individual actions which consist of multiple commands (such as unsubscribe x-list then subscribe x-digest to switch to digest mode).
Alex Hoppman wrote: "There is a more general issue of mail client capability discovery (IE: How does my mail client know that your client understands Binhex and Text/Enriched but not text/html?)."
For systems requiring mailback authentication to confirm subscriptions (and/or other commands), it would be useful to standardize the mailback message format - or at least provide a header which gives instructions the client application can use to provide a confirmation interface to the user (E.g., Dialog saying: "Confirmation request received for subscription to MAIL-LIST. Do you wish to accept the subscription?").
What about time-to-live (expiry) issues?
Client software authors should support both "X-List-" and "List-" prefixes for any of the List Headers they support. Supporting both formats is important so that servers don't have to include both formats in outgoing messages just to support old versions of client software.
The following applications have implemented, or committed to implement, the core list header fields.
Emailer from Claris. Announced intention to implement. Script based Macintosh prototype already working.
Eudora from Qualcomm. Announced intention to implement. (Macintosh prototype by Josh D. Baer and Grant Neufeld is available.)
Pegasus Mail from David Harris. Support for the headers has been implemented.
Internet Protocol Adapter (IPAD) (2.0) from eSoft, Inc. User configurable header fields allow for inclusion of any header fields.
LetterRip (as of version 1.1)
from Fog City Software, Inc.
(may be turned off on a per-list basis).
ListSTAR (all versions) from StarNine. Administrator configurable headers file. Includes all List headers by default.
Lyris from Walter Shelby Group Ltd. Supports the list header specification. List-Unsubscribe is included by default, others using a yes/no option.
Message Exchange (MX; 5.0) (MX runs on VMS) Supports the list headers.
NTList (part of NTMail) Supports the addition of the List headers.
Pegasus Mercury from David Harris. Support for the headers has been implemented.
Not all of the protocols described here are
intended for actual use at this time. Only those portions which undergo
some form of peer-review or standards formalization should be deployed.
This document may be redistributed provided this copyright notice remains intact.