Visual RFC.
ALL RFCs / RFC 2919
Read the RFC ↗
RFC 2919 / MAILING LIST IDENTIFICATION

Separate the list name from its identifier

01

List-Id is an email header field: an optional descriptive phrase followed by one list identifier in angle brackets.

DIAGRAMRead RFC section 3 ↗
RFC 2919 · § 3EXAMPLE
3 / 3
Separate the list name from its identifierThree field views. A fictional List-Id header has optional description Garden Notes and bracketed identifier garden.example.org. The second isolates only the identifier as the comparison key, not a mailbox or URL. The third separates clean generation from receiver tolerance of one internal space inserted by a poorly behaved mail transfer agent. Receiver tolerance does not permit generators to add internal whitespace. Verified erratum 3951 permits phrase or comments and folding white space before the opening bracket.One field, two different rolesList-Id: Garden Notes<garden.example.org>Received: <garden. example.org>ignore inserted spaceClient key: garden.example.orgGenerator: MUST NOT insert that space
03
Separate sending from receiving.

A clean generated identifier has no internal whitespace. A client tolerating the illustrated malformed garden. example.org ignores that space; it must not treat the description as part of the key.

Source for this drawing: RFC 2919 · Read RFC section 3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

The envelope and the letter do different jobs.

Mail transport moves a message between servers. The message format describes its contents. Authentication adds checks; it does not make every message safe.

Helpful first, if these ideas are unfamiliar

RFC 5322 Email message format RFC 8058 One-click unsubscribe RFC 6376 DKIM mail signatures

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

What changed
RFC 2919 § 3 original ABNFVerified erratum 3951

The optional component before < is [phrase / CFWS], not just [phrase]. This permits whitespace before the bracket when no descriptive phrase is present; it does not permit arbitrary comments inside the identifier.

Read the updated RFC section ↗
KEY POINT

Use the identifier for matching; the description is presentation.

  • List software SHOULD include this field on distributed messages, including individual command responses. There MUST be no more than one List-Id field per message; the field MUST be generated only by mailing list software, not end users.
  • The identifier MUST NOT exceed 255 octets. Its dot-atom components are not an email address or a command URL.
  • MTAs (mail transfer agents) MUST NOT insert whitespace inside the brackets. Client applications should ignore such whitespace if a poorly behaved MTA inserts it. This receiver tolerance is not permission for generators.
DETAILS

Verified erratum 3951 adds the optional phrase / CFWS alternative before the opening bracket, allowing a space there even without a description. CFWS means comments and folding white space; this is not unrestricted whitespace/comment insertion between every token. Optional phrases can need encoded-word decoding. The examples here use plain ASCII; they are not a complete mail-header parser.

Read the RFC section ↗

All chapters in RFC 2919

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗