RFC 2919

Part 1 of 2 🎀

List-Id: A Structured Field and Namespace for the Identification of Mailing Lists ✨

• RFC: 2919
• Authors: R. Chandhok and G. Wenger, both at QUALCOMM, Inc.
• Category: Standards Track
• Date: March 2001
• Obsoletes/Updates: This RFC's header doesn't list any RFCs it obsoletes or updates.

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. Check the current edition of the "Internet Official Protocol Standards" (STD 1) for this protocol's standardization state and status. Distribution of this memo is unlimited.

Copyright Notice ©️

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract 💌

Okay so, software that handles mailing list messages (servers and user agents) needs a reliable way to tell which messages belong to a particular mailing list. Since list management headers showed up, it's gotten even more important to have a unique identifier for a list that stays the same no matter which host is running the list at any given moment. 🫶

That's where the List-Id header comes in. It gives you a standard place to put that identifier. This doc also describes a namespace for list identifiers that's built on fully qualified domain names. The namespace is meant to guarantee uniqueness for list owners who need that, while still leaving room for a looser namespace for experimental and personal lists. 🌈

Once the List-Id field is there, list servers make life easier for mail clients, which can then offer automated tools for users to do list stuff. The list identifier can be the key that makes lots of automated processing easier, and therefore more widely available. ✨

1. Introduction 🦋

Internet mailing lists have turned into seriously sophisticated spaces for group chat and collaboration, but the infrastructure underneath them has kind of been left behind 😭. Proposals like [RFC2369] have expanded what the MUA can do, by putting more information into each message the mailing list distribution software sends.

To actually build that functionality into the MUA, you need to be able to accurately tell which messages belong to a particular mailing list. So the question becomes: what attribute or property should you use to identify a list? The obvious candidate is the list's own submission address. The problem is that when the list server host, the list processing software, or the list's submission policy changes, the submission address can change too. That makes automated processing and filtering really hard. 💀

To make the processing a software agent does more automatic (and more accurate), there needs to be a unique identifier for the mailing list. It can be used for plain string matching in a filter, or it can power fancier systems that identify messages as belonging to a particular list no matter which host delivered them. This identifier can also work as a key into a database of mailing lists. 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 📖

2. The List Identifier Syntax 🎀

Most of the time, a list identifier looks like a host name inside a domain that belongs to the list owner. So the domain name system is used to delegate namespace authority for list identifiers, the same way it's already used to hand out authority for other internet resources. Iconic. 👑

Using the domain name system as the basis for the list identifier namespace means you get to borrow an existing authority structure and apply it to a brand new area. It becomes instantly obvious who has the right to create a given list identifier, and the list identifier gets separated from any particular delivery host or mechanism. Only the rights-holder of a domain or subdomain has the authority to create list identifiers in that domain's namespace. For example, only the rights-holder of the "acm.org" domain has the authority to create list identifiers in the "acm.org" domain. 🧚

It's perfectly fine for a list identifier to be totally independent of the domain name of the host machine that services the mailing list. However, the owner of a mailing list MUST NOT generate list identifiers in any domain namespace they don't have authority over. For example, a mailing list hosting service might assign list identifiers in its own domain-based namespace, or it might let its clients (the list owners) provide list identifiers in a namespace the owner has authority over. 🍓

If the list owner doesn't have the authority to create a list identifier in a domain-based namespace, they can create unmanaged list identifiers in the special unmanaged domain "localhost". This is meant for personal users, or for users who can't afford domain name registration fees. 🌸

The syntax for a list identifier in ABNF [RFC2234] looks like this:

list-id = list-label "." list-id-namespace

list-label = dot-atom-text

list-id-namespace = domain-name / unmanaged-list-id-namespace

unmanaged-list-id-namespace    = "localhost"

domain-name = dot-atom-text

Where:

• dot-atom-text is defined in [DRUMS]
• "localhost" is a reserved domain name is defined in [RFC2606]

Also, a list identifier (list-id) MUST NOT be longer than 255 octets in length, for future compatibility. Note that "localhost" is not valid for the domain-name rule. ⭐

3. The List-Id Header Field 💜

This document presents a header field that gives an identifier for an e-mail distribution list. This 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. There MUST be no more than one of each field present in any given message. 🔥

This field MUST only be generated by mailing list software, never end users. 🙅‍♀️

The contents of the List-Id header are mostly an identifier enclosed in angle brackets ('<', '>'), with internal whitespace being ignored. MTAs MUST NOT insert whitespace within the brackets. Client applications should still treat any whitespace that a poorly behaved MTA inserts anyway as characters to ignore. 🫠

The list header fields are subject to the encoding and character restrictions for mail headers described in [RFC822]. 📝

The List-Id header MAY optionally include a description, placed as a "phrase" [DRUMS] before the angle-bracketed list identifier. The MUA MAY choose to use this description in its user interface. Any MUA that plans to use the description should be prepared to properly parse and decode any encoded strings or other legal phrase components. For lots of MUAs, parsing the List-Id header will just mean pulling the list identifier out from between the delimiting angle brackets. 🌷

The syntax of the List-Id header is:

list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF

where phrase and CRLF are as defined in [DRUMS]. Unlike most headers in [RFC822], the List-Id header does not allow free insertion of whitespace and comments around tokens. Any descriptive text has to go in the optional phrase component of the header. 🚫

Examples:

List-Id: List Header Mailing List <list-header.nisto.com>
List-Id: <commonspace-users.list-id.within.com>
List-Id: "Lena's Personal Joke List"
         <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>

---

~ to be continued in part 2 🫶✨

6. Operations on List Identifiers ✨

okay so bestie, there is only ONE operation defined for list identifiers 💅 and it's case insensitive equality (see Section 3.4.7., CASE INDEPENDENCE [RFC822]) 🎀. that's it. no other operations. iconic minimalism, honestly 😭

the sole use of a list identifier is to identify a mailing list 🦋, and the sole use of the List-Id header is to mark a particular message as belonging to that list 🌸. so it's giving very focused energy, no side quests allowed.

the comparison operation MUST ignore any part of the List-Id header outside of the angle brackets 💖, and the MUA MAY choose to inform the user if the descriptive name of a mailing list changes ✨. so the stuff outside the brackets is basically invisible when you're comparing, but your mail app is allowed to tell you if the list's nickname got a glow-up 💜

7. Supporting Nested Lists 🧚

okay this one is lowkey a lot 🙈 so a 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 🫶. like, the sublist has to actually know who its parents are, otherwise it can't pull this off 💀

if a mailing list processor encounters a List-Id header field from any unexpected source, it SHOULD NOT pass it through to the list 🍓. no sneaky forwarding of random List-Ids, periodt 💅

this implies that mailing list processors may have to be updated to properly support List-Ids for nested lists 🌈. so yeah, some list software might need a little glow-up to handle nested lists right ✨

8. Security Considerations 💀

okay listen, this section is SERIOUS and I'm not playing with it 😭🔥

there are very few new security concerns generated with this proposal 🌸. message headers are an existing standard, designed to easily accommodate new types 🦋. there may be concern with headers being forged 👀, but this problem is inherent in Internet e-mail, not specific to the header described in this document 💜. further, the implications are relatively harmless 🫶.

as 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 💀. do not let people sneak fake List-Ids into the list, bestie 🙅‍♀️

on the client side, a forged list identifier may break automated processing 🤖. the list identifier (in its current form) SHOULD NOT be used as an indication of the authenticity of the message 🔐. so a List-Id is NOT proof that a message is legit. not a verified badge, babe ✨

9. Acknowledgements 🫶

the numerous participants of the List-Header [LISTHEADER] and ListMom-Talk [LISTMOM] mailing lists contributed much to the formation and structure of this document 🎀. the whole community showed up, it's so wholesome 🥹

Grant Neufeld <grant@acm.org> focused much of the early discussion, and thus was essential in the creation of this document 👑. literal MVP energy 💖

---

References 📚

[LISTHEADER] "List-Header" Mail list. list-header@list.nisto.com <http://www.nisto.com/listspec/mail/> <http://www.nisto.com/listspec/>

[LISTMOM] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com <http://cgi.skyweyr.com/ListMom.Home>

[MSGID] J. Zawinski, M. Curtin, "Recommendations for generating Message IDs", Work in Progress.

[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.

[RFC1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.

[RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[RFC2369] Neufeld G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.

[RFC2606] Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.

[RFC2822] Resnick, P., Editor, "Internet Message Format Standard", STD 11, RFC 2822, March 2001.

Authors' Addresses 🦋

Ravinder Chandhok QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA

EMail: chandhok@qualcomm.com

Geoffrey Wenger QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA

EMail: gwenger@qualcomm.com

Full Copyright Statement 🌈

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. ✨