Preserve the parent identity through a known sublist
04A known nested-list relationship and an unexpected incoming List-Id need different handling.
Separate example: an unexpected user submits a claimed List-Id. The processor SHOULD NOT pass that field through; the drawing stops the field, not the entire email.
Source for this drawing: RFC 2919 · Read RFC section 7 ↗
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.
Preserve known nesting; do not blindly relay unexpected identity claims.
- A sublist in a known nested-list hierarchy MUST NOT modify the List-Id field. This depends on the processor knowing its relationship to the parent list.
- If a processor encounters a List-Id from an unexpected source, it SHOULD NOT pass that field through to the list. The rule concerns the field, not necessarily rejection of the whole message.
- Processors SHOULD NOT pass user-originated List-Id fields through. This is compatible with preserving a known parent field and with the one-field-per-message rule.
These are two separate input scenarios, not successive actions on one message. The guide does not invent a replacement-field policy or a message-rejection requirement. The parent and sublist are list-processing roles, not SMTP envelope recipients.
Read the RFC section ↗