RFC 2110
MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
RFC 2110: MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) 💌
Okay bestie, the title block is the tea ☕. This is from the Network Working Group, dated March 1997, and it's a Standards Track doc 👑. It was written by J. Palme (Stockholm University/KTH) and A. Hopmann (Microsoft Corporation). The header doesn't list anything it obsoletes or updates, so no drama there 🫶.
Status of this Document 📣
This doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🦋. For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Abstract 🎀
HTML [RFC 1866] was designed with MIME in mind, but the HTML spec in RFC 1866 on its own isn't enough for two electronic mail user agents to interoperate using HTML as a document format 🙈. Two things are missing: naming the objects that are normally referred to by URIs, and a way to aggregate the objects that go together. This doc lays out a set of guidelines so conforming mail user agents can send, deliver and display these objects, like HTML objects that contain links represented by URIs ✨. To handle inter-linked objects, it uses the MIME type multipart/related and specifies the MIME content-headers Content-Location and Content-Base 💜.
Table of Contents 🗂️
1. Introduction.............................................. 2
2. Terminology............................................... 3
2.1 Conformance requirement terminology................... 3
2.2 Other terminology..................................... 4
3. Overview.................................................. 5
4. The Content-Location and Content-Base MIME Content Headers 6
4.1 MIME content headers.................................. 6
4.2 The Content-Base header............................... 7
4.3 The Content-Location Header........................... 7
4.4 Encoding of URIs in e-mail headers.................... 8
5. Base URIs for resolution of relative URIs................. 8
6. Sending documents without linked objects.................. 9
7. Use of the Content-Type: Multipart/related................ 9
8. Format of Links to Other Body Parts....................... 11
8.1 General principle..................................... 11
8.2 Use of the Content-Location header.................... 11
8.3 Use of the Content-ID header and CID URLs............. 12
9 Examples................................................... 12
9.1 Example of a HTML body without included linked objects 12
9.2 Example with absolute URIs to an embedded GIF picture 13
9.3 Example with relative URIs to an embedded GIF picture 13
9.4 Example using CID URL and Content-ID header to an
embedded GIF picture.................................. 14
10. Content-Disposition header............................... 15
11. Character encoding issues and end-of-line issues......... 15
12. Security Considerations.................................. 16
13. Acknowledgments.......................................... 17
14. References............................................... 18
15. Author's Address......................................... 19Mailing List Information 📬
Further discussion on this doc should happen on the mailing list MHTML@SEGATE.SUNET.SE 💖.
To subscribe, send a message to LISTSERV@SEGATE.SUNET.SE containing the text SUB MHTML <your name (not your e-mail address)> 🫶.
The archives are available by anonymous ftp from FTP://SEGATE.SUNET.SE/lists/mHTML/. They're also available by e-mail: send a message to LISTSERV@SEGATE.SUNET.SE with the text INDEX MHTML to get a list of the archive files, then send a new message GET <file name> to retrieve the one you want 🗃️.
Comments on less important details can go to the editor, Jacob Palme <jpalme@dsv.su.se> 💌.
More info may also be available at HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.HTML 🌸.
1. Introduction 🌷
There are a bunch of document formats, like HTML [HTML2], PDF [PDF] and VRML, that use URIs to link things up and resolve them 🧚. It's obviously needed to send documents in these formats through e-mail [RFC821=SMTP, RFC822]. This doc adds specifications on how to send such documents in MIME [RFC 1521=MIME1] e-mail messages ✨. This version of the standard was based on fully considering only the needs of objects with links in the Text/HTML media type (defined in RFC 1866 [HTML2]). The standard may still apply to other formats for sets of interlinked objects that are linked by URIs 🦋. There is no conformance requirement that implementations claiming conformance to this standard handle URI-s in document formats other than HTML 💅.
URIs in HTML and similar formats reference other objects and resources, either embedded or directly accessible through hypertext links 🌈. When you mail a document like this, it's often desirable to mail all of the additional resources it references too, since those elements are necessary for fully interpreting the primary object 🫶.
Another option is to only send the URL and let the recipient look up the document using HTTP. That method is described in [URLBODY] and is not described in this document 🙈.
An informational RFC will be published later as a supplement to this standard 📚. It will discuss implementation methods and some implementation problems, and implementors are recommended to read it when developing MHTML implementations 💜. When this RFC is published, that informational RFC will still be in IETF draft status, and it will stay that way for at least six months so it can gain more implementation experience before it's published ⏳.
2. Terminology 📖
2.1 Conformance requirement terminology
This specification uses the same words as RFC 1123 [HOSTS] to define the significance of each particular requirement 💅. Those words are:
- MUST: this word, or the adjective "required", means the item is an absolute requirement of the specification 🔥.
- SHOULD: this word, or the adjective "recommended", means there may be valid reasons in particular circumstances to ignore the item. However, the full implications should be understood and the case carefully weighed before choosing a different course 🤔.
- MAY: this word, or the adjective "optional", means the item is truly optional. One vendor may include it because a marketplace requires it or because it enhances the product, for example. Another vendor may omit the same item 🌈.
An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements 🙅♀️. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant" 👑. One that satisfies all the MUST requirements but not all the SHOULD requirements is said to be "conditionally compliant" 🎀.
2.2 Other terminology
Most of the terms in this document are defined in other RFCs 📎. Here's the cheat sheet:
Absolute URI, See RFC 1808 [RELURL].
AbsoluteURI
CID See [MIDCID].
Content-Base See section 4.2 below.
Content-ID See [MIDCID].
Content-Location MIME message or content part header with the
URI of the MIME message or content part body,
defined in section 4.3 below.
Content-Transfer-Enco Conversion of a text into 7-bit octets as
ding specified in [MIME1].
CR See [RFC822].
CRLF See [RFC822].
Displayed text The text shown to the user reading a document
with a web browser. This may be different from
the HTML markup, see the definition of HTML
markup below.
Header Field in a message or content heading specifying
the value of one attribute.
Heading Part of a message or content before the first
CRLFCRLF, containing formatted fields with
attributes of the message or content.
HTML See RFC 1866 [HTML2].
HTML Aggregate HTML objects together with some or all objects,
to objects which the HTML object contains
hyperlinks.
HTML markup A file containing HTML encodings as specified
in [HTML] which may be different from the
displayed text which a person using a web
browser sees. For example, the HTML markup
may contain "<" where the displayed text
contains the character "<".
LF See [RFC822].
MIC Message Integrity Codes, codes use to verify
that a message has not been modified.
MIME See RFC 1521 [MIME1], [MIME2].
MUA Messaging User Agent.
PDF Portable Document Format, see [PDF].
Relative URI, See RFC 1866 [HTML2] and RFC 1808[RELURL].
RelativeURI
URI, absolute and See RFC 1866 [HTML2].
relative
URL See RFC 1738 [URL].
URL, relative See [RELURL].
VRML Virtual Reality Markup Language.3. Overview 🔭
An aggregate document is a MIME-encoded message that contains a root document, plus other data needed to represent that document, like inline pictures, style sheets, applets and so on 🖼️. Aggregate documents can also include extra elements that are linked to the first object 🔗. It's important to keep the different needs of several audiences in mind 👀. Mail sending agents might send aggregate documents as a normal part of everyday e-mail 💌. They might also send them when a user wants to mail a particular document from the web to someone else 🌐. And mail sending agents might send aggregate documents as automatic responders, giving access to WWW resources to non-IP connected clients 🤖.
Mail receiving agents have different needs too 📥. Some can receive an aggregate document and display it just like any other text content type. Others have to pass the aggregate document to a browsing program, so provisions need to be made to make that possible 🧁.
On top of that, several other constraints come into play 😤. It's important that a document can be signed, and that it can be transmitted to a client and displayed with minimal risk of breaking the message integrity (MIC) check that is part of the signature 🔐.
4. The Content-Location and Content-Base MIME Content Headers ✨
⏩ Part 2 is coming up next, stay tuned 💖
4.1. MIME content headers ✨
okay so, to resolve URI references that point at other body parts, there are two MIME content headers: Content-Location and Content-Base. 🎀 Either one can show up in any message or content heading, and then it's valid inside that heading and for its content. Main character energy.
Right now only URLs are actually used as URIs 🌐, but other forms of URI are expected to show up later.
The syntax for these headers is written with the syntax definition tools from [RFC822] 💅:
content-location ::= "Content-Location:" ( absoluteURI |
relativeURI )
content-base ::= "Content-Base:" absoluteURIWhere URI is restricted, as of June 1996, to the syntax for URLs defined in RFC 1738 [URL]. 📜
These two headers are only valid for the exact content heading or message heading they appear in, plus its text. 🙈 They are NOT valid for the parts inside a multipart heading, so they're totally meaningless in multipart headings. Don't even try, bestie.
These two headers can occur both inside and outside of a multipart/related part. 🧚
4.2. The Content-Base header 🍓
The Content-Base header gives a base for relative URIs that show up in other heading fields, and in HTML documents that don't have any BASE element in their HTML code. Its value MUST be an absolute URI. 🔥
Here's an example showing where a Content-Base is valid 👀:
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML; start=foo2*foo3@bar2.net
; A Content-Base header cannot be placed here, since this is a
; multipart MIME object.
--boundary-example-1
Part 1:
Content-Type: Text/HTML; charset=US-ASCII
Content-ID: <foo2*foo3@bar2.net>
Content-Location: http://www.ietf.cnir.reston.va.us/images/foo1.bar1
; This Content-Location must contain an absolute URI, since no base
; is valid here.
--boundary-example-1
Part 2:
Content-Type: Text/HTML; charset=US-ASCII
Content-ID: <foo4*foo5@bar2.net>
Content-Location: foo1.bar1 ; The Content-Base below applies to
; this relative URI
Content-Base: http://www.ietf.cnri.reston.va.us/images/
--boundary-example-1--4.3. The Content-Location Header 💖
The Content-Location header specifies the URI that matches the content of the body part whose heading it sits in. Its value CAN be an absolute or relative URI. Any URI or URL scheme may be used, but using non-standardized URI or URL schemes might carry some risk that recipients can't handle them correctly. ⚠️
This header can also say that the data sent under this heading is retrievable, in identical format, through normal use of this URI. 🪞 If you use it that way, it must contain an absolute URI, or be resolvable into an absolute URI through a Content-Base header. In that case, the info in the message can be seen as a cached version of the original data. Iconic caching behaviour, honestly. ✨
It can also be used for data that isn't available to some or all recipients. For example, the header can point at an object that's only retrievable with this URI inside a restricted domain, like a company-internal web space 🏢. The header can even hold a fictitious URI, and in that case it doesn't need to be globally unique. 🦋
Example:
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML
--boundary-example-1
Part 1:
Content-Type: Text/HTML; charset=US-ASCII
... ... <IMG SRC="fiction1/fiction2"> ... ...
--boundary-example-1
Part 2:
Content-Type: Text/HTML; charset=US-ASCII
Content-Location: fiction1/fiction2
--boundary-example-1--4.4. Encoding of URIs in e-mail headers 📧
MIME header fields have a limited length, and URIs can get really long 😭, so these lines may have to be folded. If you do fold them, you should use the algorithm defined in [URLBODY] section 3.1. 🫶
5. Base URIs for resolution of relative URIs 🌸
Relative URIs inside the contents of MIME body parts get resolved relative to a base URI. To figure out that base URI, you go through the following list and use the first method that applies 🔍.
- (a) There is a base specification inside the MIME body part that contains the link, and it resolves relative URIs into absolute URIs. For example, HTML provides the BASE element for this.
- (b) There is a
Content-Baseheader (as defined in section 4.2), specifying the base to be used. - (c) There is a
Content-Locationheader in the heading of the body part, which can then serve as the base in the same way the requested URI can serve as a base for relative URIs within a file retrieved via HTTP [HTTP].
When the methods above don't give you an absolute URI, the procedure in section 8.2 for matching relative URIs MUST be followed. 🎯
6. Sending documents without linked objects 🧚♀️
If a document, like an HTML object, gets sent without the other objects it's linked to, it MAY be sent as a Text/HTML body part all by itself. In that case, multipart/related doesn't need to be used. 🍃
Such a document can either have no links at all, contain links that the recipient resolves through ordinary net lookup, or contain links that the recipient can't resolve. 🔗
Including links the recipient has to look up through the net might not work for some recipients, since not all e-mail recipients have full internet connectivity 🙃. Also, a link might work for the sender but not for the recipient. For example, the link could point at a URI inside a company-internal network that isn't reachable from outside the company. 🏢
Note that documents with links the recipient can't resolve MAY be sent, although this is discouraged. For example, two people building a new HTML page might swap incomplete versions 🛠️.
7. Use of the Content-Type: Multipart/related 💜
If a message has one or more MIME body parts containing links, AND it also contains, as separate body parts, the data those links refer to (as defined, for example, in RFC 1866 [HTML2]), then this whole set of body parts (the referring body parts and the referred-to body parts) SHOULD be sent within a multipart/related body part as defined in [REL]. 🎀
The root body part of the multipart/related SHOULD be the start object for rendering, such as a text/html object, which contains links to objects in other body parts. It can also be a multipart/alternative of which at least one alternative resolves to such a start object. Implementors, be warned though: lots of mail programs treat multipart/alternative as if it were multipart/mixed, even though MIME [MIME1] requires support for multipart/alternative 🙄.
[REL] requires that the type attribute of the "Content-Type: Multipart/related" statement be the type of the root object, so this value can be "multipart/alternative". If the root is not the first body part within the multipart/related, [REL] further requires that its Content-ID MUST be given in a start parameter to the "Content-Type: Multipart/related" header. 🧩
When presenting the root body part to the user, the additional body parts within the multipart/related can be used:
- (a) For recipients who only have e-mail but not full Internet access.
- (b) For recipients who, for other reasons such as firewalls or the use of company-internal links, can't retrieve the linked body parts through the net.
Note that this means you can, via e-mail, send HTML that includes URIs the recipient can't resolve via HTTP or other connectivity-requiring URIs. 🌈
- (c) For items that aren't available on the web.
- (d) For any recipient, to speed up access. ⚡
The type parameter of the "Content-Type: Multipart/related" MUST be the same as the Content-Type of its root. 👑
When a sending MUA sends objects that were retrieved from the WWW, it SHOULD maintain their WWW URIs. It SHOULD not transform these URIs into some other URI form before transmitting them 🚫. This lets the receiving MUA both verify MICs included with the email message, and verify the documents against their WWW counterparts. 🔐
In certain special cases this won't work if the original HTML document contains URIs as parameters to objects and applets. In that situation, it might be better to rewrite the document before sending it 🙈. This problem is discussed in more detail in the informational RFC that will be published as a supplement to this standard.
This standard does not cover the case where a multipart/related contains links to MIME body parts outside of the current multipart/related, or in other MIME messages, even if methods similar to those described here are used. Implementors who provide such links are warned that mailers implementing this standard may not be able to resolve them 😬.
Within such a multipart/related, ALL different parts MUST have different Content-Location or Content-ID values. 🆔
8. Format of Links to Other Body Parts 🦄
8.1. General principle 🌷
A body part, like a text/HTML body part, may contain hyperlinks to objects that are included as other body parts in the same message and within the same multipart/related content. Often these linked objects are meant to be displayed inline for the reader of the main document, for example objects referenced with the IMG tag in HTML [RFC 1866=HTML2]. New tags with this property are being proposed in the ongoing development of HTML (for example, applet and frame) 🖼️.
So to send messages like this, you need to indicate which other body parts are referred to by the links in the body parts that contain them. For example, a body part of Content-Type: Text/HTML often has links to other objects, which might be included in other body parts in the same MIME message. Referencing other body parts works like this: for each body part that contains links, and each distinct URI within it that refers to data sent in the same MIME message, there SHOULD be a separate body part within the current multipart/related part of the message containing that data. Each of these body parts SHOULD contain a Content-Location header (see section 8.2) or a Content-ID header (see section 8.3). 🧠
An e-mail system that claims conformance to this standard MUST support receipt of multipart/related (as defined in section 7) with links between body parts, using both the Content-Location method (as defined in section 8.2) and the Content-ID method (as defined in section 8.3). 🎉
8.2. Use of the Content-Location header
okay so this bit is all about how a client matches a Content-Location header to a link in the HTML, and the rules change depending on whether there's a Content-Base 🎀
If there is a Content-Base header, the recipient MUST do relative to absolute resolution, as defined in RFC 1808 [RELURL], on the relative URIs in both the HTML markup and the Content-Location header before it matches a hyperlink in the HTML to a Content-Location header. Same deal if the Content-Location has an absolute URI and the HTML markup has a BASE element, so the relative URIs in the HTML can be resolved. 🔥
If there is NO Content-Base header and the Content-Location header has a relative URI, then NO relative to absolute resolution SHOULD be performed. Matching here is a two step process ✨ First, remove any LWSP from the relative URI that may have been added as described in section 4.4. Then do an exact textual match against the HTML URIs. For this matching, ignore BASE specifications, like the BASE element in HTML. This only applies when matching Content-Location headers, not to URL-s in the HTML document that get resolved through a network lookup at read time, so don't mix those up 💅
The URI in the Content-Location header doesn't have to point at something that's actually available globally for retrieval using that URI (after relative URIs are resolved). Still, URI-s in Content-Location headers, whether absolute or resolvable to absolute URIs, SHOULD still be globally unique 🦋
8.3. Use of the Content-ID header and CID URLs
When CID (Content-ID) URLs, as defined in RFC 1738 [URL] and RFC 1873 [MIDCID], are used for links between body parts, the Content-Location statement will normally get swapped out for a Content-ID header. So these two headers mean the same thing:
Content-ID: foo@bar.net
Content-Location: CID: foo@bar.netNote: Content-IDs MUST be globally unique [MIME1]. It is thus not permitted to make them unique only within this message or within this multipart/related. not a vibe 💀
9. Examples 🌸
9.1. Example of a HTML body without included linked objects
The first example is the simplest form of an HTML email message 🍓 It isn't an aggregate HTML object, just a message with a single HTML body part. This message has a hyperlink but can't resolve it. To resolve the hyperlink, the receiving client would need either IP access to the Internet or an electronic mail web gateway.
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: Text/HTML; charset=US-ASCII
<HTML>
<head></head>
<body>
<h1>Hi there!</h1>
An example of an HTML message.<p>
Try clicking <a href="http://www.resnova.com/">here.</a><p>
</body></HTML>9.2. Example with absolute URIs to an embedded GIF picture
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML; start=foo3*foo1@bar.net
--boundary-example-1
Content-Type: Text/HTML;charset=US-ASCII
Content-ID: <foo3*foo1@bar.net>
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
ALT="IETF logo">
--boundary-example-1
Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
--boundary-example-1--
9.3. Example with relative URIs to an embedded GIF picture
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Base: http://www.ietf.cnri.reston.va.us
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML
--boundary-example-1
Content-Type: Text/HTML; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC="/images/ietflogo.gif" ALT="IETF logo">
Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: ¨
--boundary-example-1
Content-Location: /images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
--boundary-example-1--9.4. Example using CID URL and Content-ID header to an embedded GIF picture
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML
--boundary-example-1
Content-Type: Text/HTML; charset=US-ASCII
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
--boundary-example-1
Content-ID: <foo4*foo1@bar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
--boundary-example-1--10. Content-Disposition header 🎀
Note the specification in [REL] on the relations between Content-Disposition and multipart/related. go read that one, it's the boss 👑
11. Character encoding issues and end-of-line issues 🧚
okay so when you're turning an HTML document (or any other text document) into a MIME-friendly stream of octets, these are the mechanisms that matter:
- HTML [HTML2, HTML-I18N] is an application of SGML [SGML], and it lets characters show up as character entities or as numeric character references in the HTML markup. For example, "Latin small letter a with acute accent" can be written as
áorá💜 - HTML documents, like other MIME
Content-Typetextdocuments, can be represented in MIME using one of several character encodings. The MIMEContent-Typecharsetparameter value tells you which encoding was used. For the exact meaning and use of thecharsetparameter, check [MIME-IMB section 4.2].
Note that the charset parameter only refers to the MIME character encoding. For example, the string á can be sent in MIME with charset=US-ASCII, but the raw character "Latin small letter a with acute accent" can't 🙈
All of the above mechanisms are well defined and documented, so they aren't explained further here. When sending a message, all of the mechanisms mentioned above MAY be used, and any mixture of them MAY occur when the document is sent via e-mail. Receiving mail user agents (together with any Web browser they may use to display the document) MUST be capable of handling any combination of these mechanisms. this is the part where everyone has to keep up 🌈
Also note that:
- Any documents, including HTML documents, that contain octet values outside the 7-bit range need a content-transfer-encoding applied before transmission over certain transport protocols [MIME1, chapter 5].
- The MIME standard [MIME1] requires that documents of "Content-Type: Text MUST be in canonical form before Content-Transfer-Encoding, i.e. that line breaks are encoded as CRLFs, not as bare CRs or bare LFs or something else. This is in contrast to [HTTP], where section 3.6.1 allows other representations of line breaks. ngl this is where the HTTP and MIME worlds disagree 😭
This might cause problems with integrity checks based on checksums, which might not survive moving a document from the HTTP environment to the MIME environment. If a document has to be converted in a way that makes a checksum integrity check invalid, then that integrity check header SHOULD be removed from the document.
Other sources of trouble are Content-Encoding (used in HTTP but not allowed in MIME) and charsets that can't represent line breaks as CRLF. A good overview of the differences between HTTP and MIME for Content-Type: Text is in [HTTP], appendix C 🦋
If the original document already has line breaks in canonical form (CRLF), then the document SHOULD remain unconverted, so the integrity check sums don't get invalidated 🫶
A provider of HTML documents who wants his documents to be transferable via both HTTP and SMTP without invalidating checksum integrity checks should always provide original documents in the canonical form, with CRLF for line breaks. that's the golden rule ✨
Some transport mechanisms may specify a default charset parameter if none is supplied [HTTP, MIME1]. Because the default differs between mechanisms, when HTML is transferred through mail, the charset parameter SHOULD be included, rather than relying on the default. 💅
12. Security Considerations 🔐
okay bestie, this part is serious, so no skipping. 😭 One big worry: you can mail someone an object and say it's the thing at a particular URI, just by slapping a Content-Location header on it. Nothing guarantees that a WWW request for that same URI would actually give back that same object. So caching that data could be a bad idea, especially if someone later uses it to retrieve that URI from other messages or message parts. That's why receiving User Agents SHOULD not cache this data the same way data pulled down through an HTTP or FTP request might get cached. 🧐
URLs are sneaky too, especially File URLs. Their names can carry company-internal info, and that info can slip out to whoever gets a document containing them. 🙈
Another way to do linked body parts is to let a combined mail and WWW proxy server handle them. The mail client only gets the start body part and hands it to a web browser, and the browser asks the proxy for the linked parts. If you go this route and the same server serves more than one user, you need to make sure one person's message body parts can't be fetched by someone else. Passwords (also called tickets or magic cookies) are one way to do that. Also, some caching WWW proxy servers don't tell cached mail objects apart from HTTP ones, and that can be a security risk. 🚨
Mailing aggregate objects also opens doors to security problems that used to be only a WWW thing. Some HTML documents now have executable content (JavaScript) or link to it (the "INSERT" specification, Java). A receiving User Agent running content from a mail message without carefully restricting what that content can do would be exceedingly dangerous. 💀
Finally, some WWW apps hide passwords, tickets (access tokens to information that may not be available to just anyone), and other sensitive info in hidden fields of web documents or in on-the-fly constructed URLs. If someone gets one of those documents and forwards it by email, they could accidentally leak that sensitive info. 😬
13. Acknowledgments 💜
Big thank-you to everyone who helped with this doc: Harald T. Alvestrand, Richard Baker, Dave Crocker, Martin J. Duerst, Lewis Geer, Roy Fielding, Al Gilman, Paul Hoffman, Richard W. Jesmajian, Mark K. Joseph, Greg Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt, Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski, Steve Zilles, and several other people. 🫶 I alone take responsibility for any errors which may still be in the document.
14. References 📚
Ref. Author, title
--------- --------------------------------------------------------
[CONDISP] R. Troost, S. Dorner: "Communicating Presentation
Information in Internet Messages: The
Content-Disposition Header", RFC 1806, June 1995.
[HOSTS] R. Braden (editor): "Requirements for Internet Hosts --
Application and Support", STD-3, RFC 1123, October 1989.
[HTML-I18N] F. Yergeau, G. Nicol, G. Adams, & M. Duerst:
"Internationalization of the Hypertext Markup
Language". RFC 2070, January 1997.
[HTML2] T. Berners-Lee, D. Connolly: "Hypertext Markup Language
- 2.0", RFC 1866, November 1995.
[HTTP] T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext
Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996.
[MD5] R. Rivest: "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[MIDCID] E. Levinson: "Content-ID and Message-ID Uniform
Resource Locators". RFC 2111, February 1997.
[MIME-IMB] N. Freed & N. Borenstein: "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bedies". RFC 2045, November 1996.
[MIME1] N. Borenstein & N. Freed: "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC
1521, Sept 1993.
[MIME2] N. Borenstein & N. Freed: "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types". RFC 2046,
November 1996.
[NEWS] M.R. Horton, R. Adams: "Standard for interchange of
USENET messages", RFC 1036, December 1987.
[PDF] Bienz, T., Cohn, R. and Meehan, J.: "Portable Document
Format Reference Manual, Version 1.1", Adboe Systems
Inc.
[REL] Edward Levinson: "The MIME Multipart/Related Content-
Type". RFC 2112, February 1997.
[RELURL] R. Fielding: "Relative Uniform Resource Locators", RFC
1808, June 1995.
[RFC822] D. Crocker: "Standard for the format of ARPA Internet
text messages." STD 11, RFC 822, August 1982.
[SGML] ISO 8879. Information Processing -- Text and Office -
Standard Generalized Markup Language (SGML),
1986. <URL:http://www.iso.ch/cate/d16387.html>
[SMTP] J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[URL] T. Berners-Lee, L. Masinter, M. McCahill: "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[URLBODY] N. Freed and Keith Moore: "Definition of the URL MIME
External-Body Access-Type", RFC 2017, October 1996.15. Author's Address 🦋
For contacting the editors, preferably write to Jacob Palme rather than Alex Hopmann. 💌
Jacob Palme Phone: +46-8-16 16 67
Stockholm University and KTH Fax: +46-8-783 08 29
Electrum 230 E-mail: jpalme@dsv.su.se
S-164 40 Kista, Sweden
Alex Hopmann E-mail: alexhop@microsoft.com
Microsoft Corporation
3590 North First Street
Suite 300
San Jose
CA 95134
Working group chairman:
Einar Stefferud <stef@nma.com>📦 where this page comes from
- ietf: rfc2110 1997-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms