MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
obsoleted by
- rfc-2557 — MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
Extracted elements (29)
Content-Base and Content-Location headers are intentionally scoped to only the heading in which they appear and its content, not to enclosed multipart parts. This avoids ambiguity when multiple nested body parts each define different base URIs.
MHTML allows sending aggregate documents (HTML plus all linked resources such as inline images, style sheets, and applets) within a single MIME email message so that recipients without full Internet connectivity can still render the complete document. This addresses the case where linked URIs are only accessible within a private network.
Two URI-based linking mechanisms (Content-Location and CID/Content-ID) are both supported rather than mandating a single one because Content-Location enables use of real WWW URIs that remain verifiable against the live web, while CID URLs provide a self-contained reference scheme for objects not publicly available. Both methods must be supported for broad interoperability.
Moving HTML documents from HTTP to MIME can invalidate checksum integrity checks because HTTP allows non-CRLF line endings while MIME requires CRLF canonical form. Additionally, HTTP Content-Encoding is not allowed in MIME, and some charsets cannot represent line breaks as CRLF.
Using a CID URL in HTML markup is equivalent to using a Content-Location header with the same CID value. The headers 'Content-ID: [email protected]' and 'Content-Location: CID: [email protected]' are identical in meaning, so either referencing mechanism can identify the same body part.
A document MAY be sent as a standalone Text/HTML body part without multipart/related if it has no linked objects or if the recipient is expected to resolve links via normal network access. Documents with unresolvable links MAY be sent but this is discouraged.
A sending MUA that sends objects retrieved from the WWW SHOULD maintain their WWW URIs and SHOULD NOT transform these URIs into another form before transmitting. This enables receiving MUAs to verify MICs and check documents against their WWW counterparts.
An e-mail system claiming conformance to this standard MUST support receipt of multipart/related with links between body parts using both the Content-Location method and the Content-ID method.
Content-IDs MUST be globally unique as required by MIME. It is not permitted to make Content-IDs unique only within a single message or within a single multipart/related.
If a document must be converted in a way that invalidates a checksum integrity check, the integrity check header SHOULD be removed from the document.
If a message contains one or more body parts with links and also contains the linked data as separate body parts, the whole set SHOULD be sent within a multipart/related body part. The root body part SHOULD be the start object for rendering (e.g., text/html) or a multipart/alternative whose alternatives resolve to such an object.
If there is a Content-Base header, the recipient MUST perform relative-to-absolute URI resolution per RFC 1808 on relative URIs in both the HTML markup and the Content-Location header before matching hyperlinks to Content-Location values. If there is no Content-Base and Content-Location contains a relative URI, NO resolution SHOULD be performed; instead an exact textual match against HTML URIs is used after stripping LWSP.
Long Content-Location and Content-Base header lines may need to be folded due to MIME header length limits. If folding is done, the algorithm defined in [URLBODY] section 3.1 should be employed.
Receiving mail user agents MUST be capable of handling any combination of character encoding mechanisms, including HTML character entities, numeric character references, and MIME charset encodings in the same document.
The MIME standard requires that documents of 'Content-Type: Text' MUST be in canonical form (CRLF line breaks) before Content-Transfer-Encoding, unlike HTTP which allows other line break representations. If the original document already uses CRLF, it SHOULD remain unconverted to preserve integrity checksums.
The type parameter of the 'Content-Type: Multipart/related' header MUST be the same as the Content-Type of the root body part. If the root is not the first body part, its Content-ID MUST be given in a start parameter to the multipart/related Content-Type header.
The value of a Content-Base header MUST be an absolute URI. Content-Base and Content-Location headers are valid only within the heading where they occur and are meaningless in multipart headings (they do not apply to enclosed parts).
To determine the base URI for resolving relative URIs in a MIME body part, the first applicable method in priority order applies: (a) an in-document base specification such as HTML BASE element, (b) a Content-Base header, (c) a Content-Location header serving as base. When none yields an absolute URI, the procedure in section 8.2 MUST be followed.
URIs in Content-Location headers, if absolute or resolvable to absolute URIs, SHOULD still be globally unique even when the referenced object is not publicly retrievable.
When HTML is transferred through mail, the charset parameter SHOULD be included in the Content-Type header rather than relying on the default, because the default charset differs between transport mechanisms (HTTP vs. MIME).
Within a multipart/related, ALL different parts MUST have different Content-Location or Content-ID values to allow unambiguous resolution of links between body parts.
Content-Base is a MIME content header that provides a base URI for resolving relative URIs in other headers and in HTML documents lacking a BASE element. Its value MUST be an absolute URI. It is valid only for the content heading or message heading where it occurs, not for parts inside multipart headings.
Content-Location is a MIME content header specifying the URI corresponding to the body part content in whose heading it appears. Its value can be an absolute or relative URI. It may indicate that the body part data is also retrievable at that URI, making the message content a cached version of the original.
A sender can claim that a body part is represented by a particular URI via Content-Location without that being true. Because there is no assurance that an HTTP request to the same URI would return the same object, receiving UAs SHOULD NOT cache Content-Location data in the same manner as data retrieved via HTTP or FTP.
HTML documents may contain executable content (JavaScript) or links to executable content (Java applets). It is exceedingly dangerous for a receiving UA to execute such content received through a mail message without careful restrictions on its capabilities.
URLs, especially File URLs, may contain company-internal information that could be inadvertently revealed to message recipients. Senders should be aware that URIs embedded in documents or headers may disclose sensitive organizational information.
Web applications sometimes embed passwords, tickets, and other sensitive information in hidden form fields or dynamically constructed URLs. If a user forwards such a document via email, sensitive information may be inadvertently disclosed to unintended recipients.
When implementing MHTML using a combined mail and WWW proxy server shared by multiple users, methods MUST be employed to ensure body parts of a message to one person are not retrievable by another. Password/ticket mechanisms are recommended; some caching proxy servers may not distinguish between email and HTTP objects, creating a security risk.
The Content-Location header is encoded as 'Content-Location:' followed by an absoluteURI or relativeURI. The Content-Base header is encoded as 'Content-Base:' followed by an absoluteURI only. Both use RFC 822 syntax and may require line folding for long URIs.