Select the root and check its type
02The required type parameter describes the root; the optional start parameter selects it by Content-ID.
A separate malformed example declares text/html but selects an image/png root. The RFC leaves behavior undefined. The illustration stops at the mismatch to explain it, not to invent a mandatory error code.
Source for this drawing: RFC 2387 · Read RFC section 3.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
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.
The type parameter is required, as stated in sections 2 and 3.1. The verified correction removes the grammar’s conflicting optional brackets.
Read the updated RFC section ↗The type parameter is required. Verified erratum 5578 corrects the optional-looking syntax in section 3.4.
- The type parameter is required. Verified erratum 5578 corrects the optional-looking syntax in section 3.4.
- Without start, the first body part is the root. With start, the matching Content-ID selects the root even if it is not first.
- If the declared type differs from the root Content-Type, this RFC leaves user-agent behavior undefined; it does not prescribe a universal rejection response.
Fictional .example identifiers and omitted payloads. These are simplified illustrations, not complete importable messages or a full MIME parser.
Read the RFC section ↗