Message Context for Internet Mail
updated by
- rfc-3938 — Video-Message Message-Context
Extracted elements (20)
Media type alone is insufficient to convey message context: a message with audio and image could be voice mail with diagrams, fax with commentary, or a fully multimedia message. Likewise, text and audio could be e-mail with an MP3 attachment or a voice message with a text header. An explicit header is needed.
Message-Context was defined as a top-level RFC 2822 header rather than a MIME Content-Type subtype to avoid requiring UAs to scan the entire (potentially large) message before determining context, and to avoid creating multiple aliases for multipart/mixed each time a new primary content type is identified.
The scope of this document deliberately excludes specifying user agent behavior when forwarding a message, as the easy cases are obvious (keep context unchanged) but other scenarios are too varied to specify normatively.
Incorrect classification must not result in failure to transfer or inability to present a message. The context should not affect actual rendering — a 'voice-message' context must not prevent a terminal with a printer from rendering fax content that arrives in that context.
Message-Context is only a hint; a message marked 'voice-message' but lacking an audio body part (e.g., after a content gateway strips large parts) must still be accepted and presented by the receiving UA rather than triggering an error or delivery failure.
A receiving user agent MUST NOT depend on the indicated message-context value in a way that prevents proper presentation of the message. If the value is incorrect or does not match the message content, the receiving UA MUST still be capable of displaying the message content at least as meaningfully as it would if no Message-Context value were present.
If a message has no Message-Context reference field, a receiving user agent MUST treat it the same as it would if the message has a 'none' value.
The values for Message-Context MUST be IANA registered values following the directions in the IANA Considerations section.
To create a new message context type, an RFC MUST be published to document the type, including a copy of the registration template and descriptions of interoperability and security issues.
The fax-message class indicates the message is a facsimile mail message whose primary content is image data, typically recorded from a facsimile telephone call.
The message-context-class is an IANA registered token with six initial values: voice-message, fax-message, pager-message, multimedia-message, text-message, and none.
The Message-Context header is a top-level RFC 2822 message header inserted by the sending UA to indicate the context of the message. It is an indicator only and does not imply message disposition, delivery notification, or required content capabilities.
The multimedia-message class indicates the message is an aggregate multimedia message (e.g., MHTML-based), distinguishing it from visually identical MIME multipart/related structures with different semantics.
The none class indicates there is no context information for the message. A missing Message-Context header is treated identically to an explicit 'none' value.
The pager-message class indicates the message is a page such as a text or numeric pager message or SMS message, whose primary content is text data representing an urgent, limited-length notification.
The text-message class indicates a traditional internet mail message consisting of text, possibly richly formatted, with or without attachments.
The voice-message class indicates the message is a voice mail message whose primary content is audio data, typically recorded from a voice telephone call.
IANA established the 'Internet Message Context Types' registry with Specification Required policy (RFC required). Initial values are: voice-message, fax-message, pager-message, multimedia-message, text-message, and none. The Message-Context header itself is registered as an RFC 2822 header with min 0, max 1 occurrences.
A poorly designed UA could blindly execute a mailed program based on Message-Context (e.g., an 'Application' context). UAs must not take executable or irreversible actions driven solely by the Message-Context value. Additionally, an attacker could mount a denial-of-service attack by sending messages whose Message-Context does not match their body, which is why the header is treated as a hint only.
The Message-Context field syntax is: 'Message-Context' ':' message-context-class CRLF, defined using ABNF. Both the header field name and message-context-class values are case-insensitive.