Preserve mappings, nesting and content safety
05Passing and storing a compound object requires the relationships between its parts, not only their body bytes.
The application still treats content and filenames as untrusted data. Related packaging and a successful part lookup do not authenticate the sender, sanitize HTML or authorize external resource loading.
Source for this drawing: RFC 2387 · Read RFC section 6.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 application receives entity bodies and Content-* headers, container parameters, and correspondence between local filenames, header data and Content-IDs when present.
- The application receives entity bodies and Content-* headers, container parameters, and correspondence between local filenames, header data and Content-IDs when present.
- Internal links may need application or receiving-agent processing when stored. Enclosed Multipart/Related entities are processed as though being stored; nesting is not permission to flatten or discard mappings.
- Security considerations are those of the underlying content type. Related packaging provides neither sender authentication nor a guarantee that HTML, images, filenames or auxiliary data are safe.
Fictional .example identifiers and omitted payloads. These are simplified illustrations, not complete importable messages or a full MIME parser.
Read the RFC section ↗