Adapt command fields for a nested sublist
04A known sublist may need its own support commands while some parent fields remain appropriate.
The manager MAY choose a suitable List-Post. If a post is intended for all parent members, redirecting it only to the sublist would lose that reach; the picture stops that narrowing, not every possible replacement.
Source for this drawing: RFC 2369 · Read RFC section 4 ↗
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.
Nested command headers follow field-specific rules, not blanket preservation.
- A sublist SHOULD remove the parent List-Help, List-Subscribe, List-Unsubscribe and List-Owner fields and SHOULD insert its own versions.
- If the sublist has its own archive it SHOULD replace List-Archive. Otherwise it MUST leave the parent List-Archive untouched.
- A sublist MAY replace List-Post according to posting policy. If posting should reach the whole parent list, it should not redirect posts only to sublist members. This differs from RFC2919’s known-sublist List-Id preservation rule.
The example assumes an explicitly configured parent/sublist relationship. A parent field is replaced, not duplicated; at most one of each remains. The last scene compares posting policies rather than declaring that every sublist must rewrite List-Post.
Read the RFC section ↗