Read bracketed alternatives without losing boundaries
02A field contains angle-bracketed URLs, optionally separated by commas and surrounding comments or white space.
After a valid first URL, a comma introduces an unbracketed sub-item, followed by a later valid-looking URL. The malformed item and remainder SHOULD be ignored; the already parsed first URL is not retroactively erased.
Source for this drawing: RFC 2369 · Read RFC section 2 ↗
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.
A comma separates alternatives only outside an enclosed URL.
- MTAs (mail transfer agents) MUST NOT insert whitespace inside the brackets. Client applications should ignore any such inserted whitespace; this is receiver tolerance, not generation permission.
- A client MUST follow the §2 handling guidelines: except for field-specific exceptions, a non-angle beginning SHOULD cause the field to be ignored; trailing characters SHOULD be ignored unless the next non-whitespace/comment character is a comma.
- If a comma-separated sub-item is not an angle-bracketed URL, that item and all later items SHOULD be ignored. Do not skip a malformed item and resume with a later command.
The examples use unfolded ASCII field bodies, not whole raw mail. Comments and URL values have different boundaries. No URL is fetched. The bounded teaching parser does not implement all RFC822 folding/encoding or all URL syntax; its size/depth guards are local model limits, not RFC2369 mandates.
Read the RFC section ↗