Use MID to name the message context
03MID means Message-ID. A mid URL can identify a whole message or a particular body part inside a designated message. Its long form supplies context for stores that do not index all body parts separately.
In the selected store, a mid URL names a message that is no longer present. Stop before selecting a body part. The RFC supplies an addressing scheme, not a guarantee of retention or an automatic web fallback.
Source for this drawing: RFC 2392 · Read RFC section 2 ↗
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.
mid:message-id identifies the whole message. mid:message-id/content-id identifies a body part within that message.
- mid:message-id identifies the whole message. mid:message-id/content-id identifies a body part within that message.
- An implementation conforming to RFC 2392 is required to support the long form. The slash between its two identifiers is a separator; slashes inside either identifier must be escaped.
- Separate the URL’s structural components before decoding the escaped identifiers. A decoded slash within an identifier does not create a second context separator.
- An identifier does not guarantee that a recipient’s store contains the message. The selected missing-message outcome is a local lookup result, not a specified HTTP or mail-protocol status.
Fictional .example identifiers; payloads are omitted. Consult the linked MIME and message-format specifications for complete parsing, retrieval and security requirements.
Read the RFC section ↗