Mail List Command Specification

Last update: August 2, 1998
Grant Neufeld - <>

List Message Header Fields approved for RFC!

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 - Advocacy - Introduction - FAQ - Discussion - Definitions - Supporting Applications

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 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.

FAQ: Frequently Asked Questions

Why use header fields for message command information?

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.

Why not use a specialized MIME part to carry the information?

Because most mail clients currently either don't support MIME or are not equipped to handle such specialized parts - resulting in problems for end users.
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.

Why include a Subscribe command?

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

What about servers receiving invalid messages like "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.

Discussion Points

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 group of header fields at the begining of an email message.
header field
An individual field in a message header. Provides information about the message (such as the "Subject:", who the message is "From:", etc.).
"internationalization", meaning making Internet protocols friendly to languages other than English.
A syntax used to provide information about a syntax. It is not the actual syntax itself, but rather a means of describing and identifying information about a syntax.
mail transport agent (email server).
mail user agent (email client).

Applications Supporting the List- Header Fields [RFC2369]

The following applications have implemented, or committed to implement, the core list header fields.

Email Clients

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.

List Server Applications

AutoShare (1.2). Auto-generates the List-Subscribe and List-Unsubscribe headers.

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. Auto-generates the List-Subscribe and List-Unsubscribe headers (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.

Copyright ©1997-1998 Grant Neufeld.
Nisto and are trademarks of Grant Neufeld.