The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager command
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 6 must, 9 should, 5 may.
1 Introduction
- SHOULDMTAs generating the header fields SHOULD usually include a mailto based command, in addition to any other protocols used, in order to support users who do not have access to non-mail-based protocols.
- MAYMany list managers, especially as the proposal first gains acceptance, MAY choose to implement only one or two of the fields.
2 The Command Syntax
- MUST NOTMTAs MUST NOT insert whitespace within the brackets, but client applications should treat any whitespace, that might be inserted by poorly behaved MTAs, as characters to ignore.
- MAYA list of multiple, alternate, URLs MAY be specified by a comma- separated list of angle-bracket enclosed URLs.
- SHOULDHowever, systems using such syntaxes SHOULD still take advantage of the List-Help field to provide the user with detailed instructions as needed or - perhaps more usefully - provide access to some form of structured command interface such as an HTML-based form.
- MUSTTo allow for future extension, client applications MUST follow the following guidelines for handling the contents of the header fields described in this document:
- SHOULD1) Except where noted for specific fields, if the content of the field (following any leading whitespace, including comments) begins with any character other than the opening angle bracket '<', the field SHOULD be ignored.
- SHOULD2) Any characters following an angle bracket enclosed URL SHOULD be ignored, unless a comma is the first non-whitespace/comment character after the closing angle bracket.
- SHOULD3) If a sub-item (comma-separated item) within the field is not an angle-bracket enclosed URL, the remainder of the field (the current, and all subsequent, sub-items) SHOULD be ignored.
3 The List Header Fields
- SHOULDThe fields implemented on a given list SHOULD be included on all messages distributed by the list (including command responses to individual users), and on other messages where the message clearly applies to one distinct list.
- MUSTThere MUST be no more than one of each field present in any given message.
- MUSTThese fields MUST only be generated by mailing lists, not end users.
3.1 List-Help
- SHOULDIt would be acceptable for a list manager to include only this field, since by definition it SHOULD direct the user to complete instructions for all other commands.
3.4 List-Post
- MAYThis is typically the address of the list, but MAY be a moderator, or potentially some other form of submission.
3.5 List-Owner
- MAYThe URL MAY contain the address of a administrator for the list, the mail system administrator, or any other person who can handle user contact for the list.
4 Supporting Nested Lists
- SHOULDSublists SHOULD remove the parent list's List-Help, List-Subscribe, List-Unsubscribe and List-Owner fields, and SHOULD insert their own versions of those fields.
- SHOULDIf the sublist provides its own archive, it SHOULD replace the List- Archive with its own.
- MUSTOtherwise, it MUST leave the List-Archive field untouched.
- MAYDependant on how postings to the list are handled, the sublist MAY replace the List-Post field.
6 Acknowledgements
- MUSTIf using a dialog interface (or other feedback element) the client application MUST include an option for the user to review (and possibly modify) the message before it is sent.