Use a list key without trusting the message
05A forged List-Id can misdirect automatic mail processing. It is neither proof of origin nor permission to execute a list command.
Do not infer message authenticity or a command URL from the matching ID. Check applicable authentication separately; no network fetch or list action is defined by this identifier.
Source for this drawing: RFC 2919 · Read RFC section 8 ↗
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
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
An identifier labels a message; it does not authenticate it.
- The identifier in its current form SHOULD NOT be used as an indication of message authenticity. A plausible key can be forged.
- The only operation defined for the identifier is case-insensitive equality. Its sole use is identifying a list and marking membership of a message, not locating a command endpoint.
- Authentication mechanisms such as DKIM are separate specifications with their own validation and limits. This guide does not infer an authenticated sender from List-Id or make a complete mail acceptance decision.
Mail User Agent (MUA) means software reading mail. A filing rule is an illustrative client use, not a requirement to auto-file untrusted messages. List commands belong to other headers, for example RFC2369, and one-click unsubscribe has the separate RFC8058 consent/authentication requirements.
Read the RFC section ↗