MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
obsoletes
- rfc-2110 — MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
Extracted elements (30)
Both Content-ID and Content-Location are defined as valid body-part identifiers so that existing web pages can be forwarded in email without rewriting HTML source. Rewriting would invalidate security checksums and introduce other practical problems.
The 'thismessage:/' fictitious base URI was introduced to provide a uniform mechanism for comparing relative URIs that cannot be resolved to a real absolute URI; all such URIs resolve to the same artificial base, making octet-by-octet comparison possible without live retrieval.
References from a resource in one multipart/related structure to body parts in a parallel or separately-enclosed multipart/related structure are not covered by this standard; implementations are warned that such references may not be resolvable by conforming receiving agents.
Some receiving agents treat multipart/alternative as multipart/mixed despite MIME requiring correct support for multipart/alternative, which may affect root resource identification in MHTML aggregates that use a multipart/alternative start part.
The Content-Base header from RFC 2110 has been removed in RFC 2557. A conservative implementation MAY accept Content-Base on input for backwards compatibility with RFC 2110, but MUST never send a Content-Base header.
A resource from a multipart/related structure stored in a cache MUST NOT be retrieved from that cache except by a reference from a body part in the same multipart/related structure, preventing cache-poisoning attacks using misrepresented Content-Location labels.
A sending MUA SHOULD maintain the WWW URIs of objects retrieved from the web and SHOULD NOT transform these URIs into another form before transmission, so that recipients can verify message integrity checks and compare against the original web resources.
Character encoding as specified in section 4.4.1 MUST be performed before folding a long Content-Location header. Folding is then applied using the algorithm from [URLBODY] section 3.1.
CID URLs MUST be matched only against Content-ID header values and not against Content-Location headers containing a CID: value. A Content-Location with a CID: prefix is explicitly ignored for URI matching.
Content-IDs MUST be globally unique as required by MIME; making them unique only within a message or a single multipart/related structure is not permitted.
Content-Location header values, if absolute or resolvable to absolute URIs, SHOULD be globally unique even if the URI does not point to a globally retrievable resource.
If a message contains body parts with URI references and also includes the referenced resources as separate body parts, the complete set SHOULD be sent within a multipart/related structure as defined in [REL].
If a sender intends a recipient to always retrieve a URI-referenced resource from its source, a URI-labeled copy of that resource MUST NOT be included in the multipart/related structure.
Receiving clients MUST decode any MIME Part 3 encoding present in Content-Location header values before comparing those URIs to URIs found in body text.
Receiving user agents MUST be capable of handling any combination of HTML character-encoding mechanisms, including character entities, numeric character references, and MIME charset encodings.
URIs containing characters inappropriate for RFC 822 headers MUST have spaces and other illegal characters encoded using MIME Part 3 (RFC 2047) methods. This encoding MUST only be applied in the header, never in the HTML text itself.
When a URI in a Content-Location header contains octets outside the 7-bit range and the correct charset cannot be established, the charset parameter value 'UNKNOWN-8BIT' MUST be used; otherwise the correct charset SHOULD be used, or 'US-ASCII' if the URI is entirely 7-bit.
When HTML is transferred through e-mail, the charset parameter SHOULD be explicitly included in the Content-Type header rather than relying on transport-specific defaults, because the default charset differs between HTTP and MIME email environments.
When no higher-priority method yields an absolute base URI, a base URL of 'thismessage:/' MUST be employed. This URI was defined solely for resolving relative references within a multipart/related structure when no other base is available.
When rendering a text/html body part in an MHTML multipart/related structure, all URIs referencing subsidiary resources within the same structure SHALL be satisfied by those enclosed resources and not by any other local or remote source.
When the multipart/related start object is not the first body part in the structure, its Content-ID MUST be specified as the value of a start parameter in the Content-Type multipart/related header.
Within a multipart/related structure, each body part MUST have, if assigned, a distinct Content-ID header value and Content-Location header field values that resolve to distinct URIs.
HTML-formatted email with inline links to externally-hosted objects can break recipient anonymity: when the recipient's mailer fetches the linked object via HTTP, the HTTP transaction reveals the reader's identity and workstation address to the sender.
Base URI resolution for relative URIs in MIME body parts follows a strict priority order: (a) an in-body base specification such as HTML BASE, (b) an absolute Content-Location in the immediately surrounding heading, (c) recursive search up enclosing multipart headings, (d) the HTTP request URI if applicable, and (e) 'thismessage:/' as the mandatory fallback.
Content-Location is a MIME content header that labels a body part with a URI, enabling URI references in a text/html body part to resolve to subsidiary resources in other body parts of the same multipart/related structure. Its value may be an absolute or relative URI.
URI resolution in text/html body parts proceeds by: (a) unfolding headers, (b) removing MIME encodings without percent-decoding, (c) resolving relative URIs via the base URI algorithm from section 5, (d) comparing the resolved URI octet-by-octet against Content-ID- and Content-Location-derived URIs from body parts in the same or surrounding multipart/related structure, and (e) falling back to live Internet retrieval if no match is found.
A sender can misrepresent the source of a body part by labeling it with a Content-Location URI pointing to a different resource. Recipients MUST treat Content-Location only as a label for intra-structure URI resolution, not as a verified source indicator.
File URIs and other URIs embedded in Content-Location headers may inadvertently disclose passwords, access tokens, or other sensitive information encoded in hidden HTML fields or URI parameters when a document is forwarded in email.
HTML documents may directly contain or reference executable content (JavaScript, Java applets). A receiving UA MUST apply careful restrictions before executing such content received in a mail message, as it is exceedingly dangerous to execute it without constraints.
The Content-Location header is defined in ABNF as 'Content-Location:' optionally surrounded by CFWS followed by a URI (absoluteURI or relativeURI per RFC 1738). Only a single Content-Location field is permitted per message or content heading.