The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
Extracted elements (25)
MIME parts were considered but rejected because many mail clients at the time did not support MIME or could not handle specialized parts, and header fields are easier for list servers to implement. A MIME-based approach for more complete command description was noted as future work.
Multiple separate header fields were chosen over a single field to avoid inventing a new meta-syntax, to keep individual field size manageable (single-field multi-command content risks modification by servers in transit), and to allow clients and list managers to implement only a needed subset independently.
URLs were chosen over parameter lists because they are an established, widely deployed syntax; many clients already parse them (enabling prototype implementations without source modification); and as the URL standard evolves, the list fields gain new capabilities without requiring changes to this proposal.
Variable substitution in URL command syntax was deliberately excluded because it would immeasurably increase complexity, potentially require redefining the URL standard, and the need for variables in list command syntaxes is lessening. The List-Help field covers the gap for services that do require variable fields.
The list header field contents are subject to the encoding and character restrictions of RFC 822 mail headers, and URL content is further restricted to the set of URL-safe characters defined in RFC 1738.
The use of these list header fields does not remove the requirement to support the -Request command address for mailing lists as specified in RFC 2142. Both mechanisms must coexist.
Client applications MUST follow three parsing guidelines: ignore fields not starting with '<' (unless noted otherwise); ignore characters after a closing bracket unless a comma follows; and ignore the remainder of a field if a sub-item is not an angle-bracket enclosed URL.
Implemented list header fields SHOULD be included on all messages distributed by the list, including command responses to individual users, and on messages that clearly apply to one distinct list.
List header fields MUST only be generated by mailing lists, not end users.
MTAs generating list header fields SHOULD include a mailto-based command in addition to any other protocols, in order to support users who do not have access to non-mail-based protocols.
MTAs MUST NOT insert whitespace within angle brackets enclosing a URL in list header fields.
Sublists in a nested hierarchy SHOULD remove the parent list's List-Help, List-Subscribe, List-Unsubscribe, and List-Owner fields and insert their own versions. If the sublist has no own archive it MUST leave the List-Archive field untouched; otherwise it SHOULD replace it.
Systems whose command syntax requires variable fields SHOULD still use the List-Help field to provide detailed instructions or access to a structured command interface such as an HTML form.
There MUST be no more than one of each list header field present in any given message.
When using a dialog interface for command confirmation, the client application MUST include an option for the user to review (and possibly modify) the message before it is sent.
List-Archive describes how to access archives for the list. Supported URL schemes include mailto, ftp, and http.
List-Help is the most important of the six header fields. It SHOULD direct the user to complete instructions for all other commands, typically via a URL requesting a help file or instructive website.
List-Owner identifies the path to contact a human administrator for the list. There is no need to specify List-Owner if it is the same person as the mail system administrator (postmaster).
List-Post describes the method for posting to the list, typically the list address, but MAY be a moderator address. For announcement-only lists it may contain the special value "NO" to indicate posting is not allowed.
List-Subscribe describes the command (preferably using mail) to add the user to the list. Like List-Unsubscribe, it accepts angle-bracket enclosed URLs with mailto preferred.
List-Unsubscribe describes the command (preferably using mail) to directly remove the user from the list. It accepts one or more angle-bracket enclosed URLs, with mailto preferred.
Mail client applications SHOULD NOT support list header field URLs that could compromise the security of the user's system, including the "file://" URL type which could trigger execution of a local application. All URL security considerations from RFC 1738 apply.
Mail list processors MUST NOT allow user-originated list header fields to pass through to their lists, as these could confuse users and create security problems.
On the client side, users MUST have the opportunity to confirm any action before it is executed. For mailto, it may be appropriate to create the correctly formatted message without sending it, letting the user approve or discard.
Each list header field value consists of angle-bracket ('<', '>') enclosed URLs. Multiple alternate URLs MAY be specified as a comma-separated list with preference order left to right. Internal whitespace within brackets MUST NOT be inserted by MTAs but clients SHOULD ignore any such whitespace.