List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. [STANDARDS-TRACK]
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 9 must, 8 should, 4 may.
2 The List Identifier Syntax
- MUST NOTWhile it is perfectly acceptable for a list identifier to be completely independent of the domain name of the host machine servicing the mailing list, the owner of a mailing list MUST NOT generate list identifiers in any domain namespace for which they do not have authority.
- MUST NOTIn addition, a list identifier (list-id) MUST NOT be longer than 255 octets in length, for future compatibility.
3 The List-Id Header Field
- SHOULDThis header 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 this particular distinct list.
- MUSTThere MUST be no more than one of each field present in any given message.
- MUSTThis field MUST only be generated by mailing list software, not end users.
- MUST NOTMTAs MUST NOT insert whitespace within the brackets, but client applications should treat any such whitespace, that might be inserted by poorly behaved MTAs, as characters to ignore.
- MAYThe List-Id header MAY optionally include a description by including it as a "phrase" [DRUMS] before the angle-bracketed list identifier.
- MAYThe MUA MAY choose to use this description in its user interface; however, any MUA that intends to make use of the description should be prepared to properly parse and decode any encoded strings or other legal phrase components.
4 Persistence of List Identifiers
- MAYAlthough the list identifier MAY be changed by the mailing list administrator this is not desirable.
- SHOULD(Note that there is no disadvantage to changing the description portion of the List-Id header.) A MUA may not recognize the change to the list identifier because the MUA SHOULD treat a different list identifier as a different list.
- SHOULDAs such the mailing list administrator SHOULD avoid changing the list identifier even when the host serving the list
5 Uniqueness of List Identifiers
- MUSTList-IDs not ending with ".localhost" MUST be globally unique in reference to all other mailing lists.
- SHOULDList owners wishing to use the special "localhost" namespace for their list identifier SHOULD use the month and year (in the form MMYYYY) that they create the list identifier as a "subdomain" of the "localhost" namespace.
- MUSTIn addition, some portion of the list identifier MUST be a randomly generated string.
- SHOULDIn particular, list identifiers that have a random component SHOULD contain a hex encoding of 128 bits of randomness (resulting in 32 hex characters) as part of the list identifier
- MAYA particular list owner with several lists MAY choose to use the same random number subdomain when generating list identifiers for each of the lists.
6 Operations on List Identifiers
- MUSTThe comparison operation MUST ignore any part of the List-Id header outside of the angle brackets, the MUA MAY choose to inform the user if the descriptive name of a mailing list changes.
7 Supporting Nested Lists
- MUST NOTA list that is a sublist for another list in a nested mailing list hierarchy MUST NOT modify the List-Id header field; however, this will only be possible when the nested mailing list is aware of the relationship between it and its "parent" mailing lists.
- SHOULD NOTIf a mailing list processor encounters a List-Id header field from any unexpected source it SHOULD NOT pass it through to the list.
8 Security Considerations
- SHOULD NOTAs mentioned above, mail list processors SHOULD NOT allow any user- originated List-Id fields to pass through to their lists, lest they confuse the user and have the potential to create security problems.
- SHOULD NOTThe list identifier (in its current form) SHOULD NOT be used as an indication of the authenticity of the message.