Content-Location: CID: foo@bar.net
Note: Content-IDs MUST be globally unique [MIME1]. It is thus not
permitted to make them unique only within a message or within a
single multipart/related structure.
9. Examples
Warning: The examples are provided for illustrative purposes only. If
there is a contradiction between the explanatory text and the
examples in this standard, then the explanatory text is normative.
Notation: The examples contain indentation to show the structure, the
real objects should not be indented in this way.
Palme, et al. Standards Track [Page 14]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
9.1 Example of a HTML body without included linked objects
The first example is the simplest form of an HTML email message. This
message does not contain an aggregate HTML object, but simply a
message with a single HTML body part. This body part contains a URI
but the messages does not contain the resource referenced by that
URI. To retrieve the resource referenced by the URI 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="iso-8859-1"
Content-Transfer-Encoding: 8bit
Acute accent
The following two lines look have the same screen rendering:
E with acute accent becomes É.
E with acute accent becomes É.
Try clicking
here.
9.2 Example with an absolute URI to an embedded GIF picture
The second example is an HTML message which includes a single image,
referenced using the Content-Location mechanism.
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example";
type="text/html"; start=""
--boundary-example
Content-Type: text/html;charset="US-ASCII"
Content-ID:
... text of the HTML document, which might contain a URI
referencing a resource in another body part, for example
through a statement such as:
--boundary-example
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--
9.3 Example with relative URIs to embedded GIF pictures
In this example, a Content-Location header field in the outermost
heading will be a base to all relative URLs, also inside the HTML
text being sent.
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Location: http://www.ietf.cnri.reston.va.us/
Content-Type: multipart/related; boundary="boundary-example";
type="text/html"
--boundary-example
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: QUOTED-PRINTABLE
... text of the HTML document, which might contain URIs
referencing resources in other body parts, for example through
statements such as:
Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: ¨
--boundary-example
Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif
; Note - Absolute Content-Location does not require a
; base
Palme, et al. Standards Track [Page 16]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
--boundary-example
Content-Location: images/ietflogo2.gif
; Note - Relative Content-Location is resolved by base
; specified in the Multipart/Related Content-Location heading
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
--boundary-example
Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo3.gif
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
--boundary-example--
9.4 Example with a relative URI and no BASE available
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example";
type="text/html"
--boundary-example
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: QUOTED-PRINTABLE
... text of the HTML document, which might contain a URI
referencing a resource in another body part, for example
through a statement such as:
Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: ¨
Palme, et al. Standards Track [Page 17]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
--boundary-example
Content-Location: ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
--boundary-example--
9.5 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";
type="text/html"
--boundary-example
Content-Type: text/html; charset="US-ASCII"
... text of the HTML document, which might contain a URI
referencing a resource in another body part, for example
through a statement such as:
--boundary-example
Content-Location: CID:something@else ; this header is disregarded
Content-ID:
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
--boundary-example--
Palme, et al. Standards Track [Page 18]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
9.6 Example showing permitted and forbidden references between nested
body parts
This example shows in which cases references are allowed between
multiple multipart/related body parts in a message.
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"
Content-ID:
The image reference below will be resolved with the image
in the next body part.
The image reference below cannot be resolved within this
MIME message, since it contains a reference from an outside
body part to an inside body part, which is not supported
by this standard.
The anchor reference immediately below will be resolved with
the nested text/html body part below:
Even more info
--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...
Palme, et al. Standards Track [Page 19]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
--boundary-example-1
Content-Location:
http://www.ietf.cnri.reston.va.us/more-info
Content-Type: multipart/related; boundary="boundary-example-2";
type="text/html"
--boundary-example-2
Content-Type: text/html;charset="US-ASCII"
Content-ID:
The image reference below will be resolved with the image
in the surrounding multipart/related above.
The image reference below will be resolved with the image
inside the current nested multipart/related below.
--boundary-example-2
Content-Location: http:images/ietflogo2.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4
SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa
etc...
--boundary-example-2--
--boundary-example-1
Content-Location:
http://www.ietf.cnri.reston.va.us/even-more-info
Content-Type: multipart/related; boundary="boundary-example-3";
type="text/html"
--boundary-example-3
Content-Type: text/html;charset="US-ASCII"
Content-ID: <4@foo@bar.net>
The image reference below will be resolved with the image
inside the current nested multipart/related below.
The image reference below cannot be resolved according to
this standard since references between parallel multipart/
related structures are not supported.
Palme, et al. Standards Track [Page 20]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
--boundary-example-3
Content-Location: http:images/ietflogo2d.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgANX/AMDAwCkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nz
c3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v
etc...
--boundary-example-3--
--boundary-example-1--
10. Character encoding issues and end-of-line issues
For the encoding of characters in HTML documents and other text
documents into a MIME-compatible octet stream, the following
mechanisms are relevant:
- HTML [HTML2], [HTML-I18N] as an application of SGML [SGML] allows
characters to be denoted by character entities as well as by
numeric character references (e.g. "Latin small letter a with
acute accent" may be represented by "á" or "á") in the
HTML markup.
- HTML documents, in common with other documents of the MIME
Content-Type "text", can be represented in MIME using one of
several character encodings. The MIME Content-Type "charset"
parameter value indicates the particular encoding used. For the
exact meaning and use of the "charset" parameter, please see
[MIME2] chapter 4.
Note that the "charset" parameter refers only to the MIME
character encoding. For example, the string "á" can be sent
in MIME with "charset=US-ASCII", while the raw character "Latin
small letter a with acute accent" cannot.
The above mechanisms are well defined and documented, and therefore
not further explained here. In sending a message, all the above
mentioned mechanisms MAY be used, and any mixture of them MAY occur
when sending the document in MIME format. Receiving user agents
(together with any Web browser they may use to display the document)
MUST be capable of handling any combinations of these mechanisms.
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,
Palme, et al. Standards Track [Page 21]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
chapter 5].
- The MIME standard [MIME2] requires that e-mailed documents of
"Content-Type: Text/ MUST be in canonical form before a Content-
Transfer-Encoding is applied, 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.
Note that this might cause problems with integrity checks based on
checksums, which might not be preserved when moving a document from
the HTTP to the MIME environment. If a document has to be converted
in such a way that a checksum based message integrity check becomes
invalid, then this integrity check header SHOULD be removed from the
document.
Other sources of problems are Content-Encoding used in HTTP but not
allowed in MIME, and character sets that are not able to represent
line breaks as CRLF. A good overview of the differences between HTTP
and MIME with regards to Content-Type: "text" can be found in [HTTP],
appendix C.
Some transport mechanisms may specify a default "charset" parameter
if none is supplied [HTTP, MIME1]. Because the default differs for
different mechanisms, when HTML is transferred through e-mail, the
charset parameter SHOULD be included, rather than relying on the
default.
11. Security Considerations
11.1 Security considerations not related to caching
It is possible for a message sender to misrepresent the source of a
multipart/related body part to a message recipient by labeling it
with a Content-Location URI that references another resource.
Therefore, message recipients should only interpret Content-Location
URIs as labeling a body part for the resolution of references from
body parts in the same multipart/related message structure, and not
as the source of a resource, unless this can be verified by other
means.
URIs, especially File URIs, if used without change in a message, may
inadvertently reveal information that was not intended to be revealed
outside a particular security context. Message senders should take
care when constructing messages containing the new header fields,
defined in this standard, that they are not revealing information
outside of any security contexts to which they belong.
Palme, et al. Standards Track [Page 22]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
Some resource servers hide passwords and tickets (access tokens to
information which should not be reveled to others) and other
sensitive information in non-visible fields or URIs within a
text/html resource. If such a text/html resource is forwarded in an
email message, this sensitive information may be inadvertently
revealed to others.
Since HTML documents can either directly contain executable content
(i.e., JavaScript) or indirectly reference executable content (The
"INSERT" specification, Java). It is exceedingly dangerous for a
receiving User Agent to execute content received in a mail message
without careful attention to restrictions on the capabilities of that
executable content.
HTML-formatted messages can be used to investigate user behaviour,
for example to break anonymity, in ways which invade the privacy of
individuals. If you send a message with a inline link to an object
which is not itself included in the message, the recipients mailer or
browser may request that object through HTTP. The HTTP transaction
will then reveal who is reading the message. Example: A person who
wants to find out who is behind an anonymous user identity, or from
which workstation a user is reading his mail, can do this by sending
a message with an inline link and then observe from where this link
is used to request the object.
11.2 Security considerations related to caching
There is a well-known problem with the caching of directly retrieved
web resources. A resource retrieved from a cache may differ from that
re-retrieved from its source. This problem, also manifests itself
when a copy of a resource is delivered in a multipart/related
structure.
When processing (rendering) a text/html body part in an MHTML
multipart/related structure, all URIs in that text/html body part
which reference subsidiary resources within the same
multipart/related structure SHALL be satisfied by those resources and
not by resources from any another local or remote source.
Therefore, if a sender wishes a recipient to always retrieve an URI
referenced resource from its source, an URI labeled copy of that
resource MUST NOT be included in the same multipart/related
structure.
In addition, since the source of a resource received in a
multipart/related structure can be misrepresented (see 11.1 above),
if a resource received in multipart/related structure is stored in a
cache, it MUST NOT be retrieved from that cache other than by a
Palme, et al. Standards Track [Page 23]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
reference contained in a body part of the same multipart/related
structure. Failure to honor this directive will allow a
multipart/related structure to be employed as a Trojan Horse. For
example, to inject bogus resources (i.e. a misrepresentation of a
competitor's Web site) into a recipient's generally accessible Web
cache.
12. Differences as compared to the previous version of this proposed
standard in RFC 2110
The specification has been changed to show that the formats described
do not only apply to multipart MIME in email, but also to multipart
MIME transferred through other protocols such as HTTP or FTP.
In order to agree with [RELURL], Content-Location headers in
multipart Content-Headings can now be used as a base to resolve
relative URIs in their component parts, but only if no base URI can
be derived from the component part itself. Base URIs in Content-
Location header fields in inner headings have precedence over base
URIs in outer multipart headings.
The Content-Base header, which was present in RFC 2110, has been
removed. A conservative implementor may choose to accept this header
in input for compatibility with implementations of RFC 2110, but MUST
never send any Content-Base header, since this header is not any more
a part of this standard.
A section 4.4.1 has been added, specifying how to handle the case of
sending a body part whose URI does not agree with the correct URI
syntax.
The handling of relative and absolute URIs for matching between body
parts have been merged into a single description, by specifying that
relative URIs, which cannot be resolved otherwise, should be handled
as if they had been given the URL "thismessage:/".
13. Acknowledgments
Harald T. Alvestrand, Richard Baker, Isaac Chan, Dave Crocker, Martin
J. Duerst, Lewis Geer, Roy Fielding, Ned Freed, Al Gilman, Paul
Hoffman, Andy Jacobs, Richard W. Jesmajian, Mark K. Joseph, Greg
Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt,
Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Martyn W.
Peck, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski, Steve
Zilles and several other people have helped us with preparing this
document. We alone take responsibility for any errors which may still
be in the document.
Palme, et al. Standards Track [Page 24]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
14. References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[CONDISP] Troost, R. and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-
Disposition Header", RFC 2183, August 1997.
[HOSTS] Braden, R., Ed., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October
1989.
[HTML-I18N] Yergeau, F., Nicol, G. Adams, G. and M. Duerst:
"Internationalization of the Hypertext Markup
Language", RFC 2070, January 1997.
[HTML2] Berners-Lee, T. and D. Connolly: "Hypertext Markup
Language - 2.0", RFC 1866, November 1995.
[HTML3.2] Dave Raggett: HTML 3.2 Reference Specification, W3C
Recommendation, January 1997, at URL
http://www.w3.org/TR/REC-html32.html
[HTTP] Berners-Lee, T., Fielding, R. and H. Frystyk,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996.
[IETF-TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirements Levels", BCP 14, RFC 2119, March 1997.
[INFO] J. Palme: Sending HTML in MIME, an informational
supplement to the RFC: MIME Encapsulation of
Aggregate Documents, such as HTML (MHTML), Work in
Progress.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[MIDCID] Levinson, E., "Content-ID and Message-ID Uniform
Resource Locators", RFC 2387, August 1998.
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, December 1996.
Palme, et al. Standards Track [Page 25]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
[MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, December 1996.
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, December 1996.
[MIME4] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four:
Registration Procedures", RFC 2048, January 1997.
[MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance
Criteria and Examples", RFC 2049, November 1996.
[NEWS] Horton, M. and R. Adams: "Standard for interchange of
USENET messages", RFC 1036, December 1987.
[PDF] Tim Bienz and Richar Cohn: "Portable Document Format
Reference Manual", Addison-Wesley, Reading, MA, USA,
1993, ISBN 0-201-62628-4.
[REL] Levinson, E., "The MIME Multipart/Related Content-
Type", RFC 2389, August 1998.
[RELURL] Fielding, R., "Relative Uniform Resource Locators",
RFC 1808, June 1995.
[RFC822] Crocker, D., "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.
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[URL] Berners-Lee, T., Masinter, L. and M. McCahill,
"Uniform Resource Locators (URL)", RFC 1738, December
1994.
[URLBODY] Freed, N. and K. Moore, "Definition of the URL MIME
External-Body Access-Type", RFC 2017, October 1996.
Palme, et al. Standards Track [Page 26]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
[VRML] Gavin Bell, Anthony Parisi, Mark Pesce: "Virtual
Reality Modeling Language (VRML) Version 1.0 Language
Specification." May 1995,
http://www.vrml.org/Specifications/.
[XML] Extensible Markup Language, published by the World
Wide Web Consortium, URL http://www.w3.org/XML/
15. Authors' Addresses
For contacting the editors, preferably write to Jacob Palme.
Jacob Palme
Stockholm University and KTH
Electrum 230
S-164 40 Kista, Sweden
Phone: +46-8-16 16 67
Fax: +46-8-783 08 29
EMail: jpalme@dsv.su.se
Alex Hopmann
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
Phone: +1-425-703-8238
EMail: alexhop@microsoft.com
Nick Shelness
Lotus Development Corporation
55 Cambridge Parkway
Cambridge MA 02142-1295
EMail: Shelness@lotus.com
Working group chairman:
Einar Stefferud
EMail: stef@nma.com
Palme, et al. Standards Track [Page 27]
RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
16. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Palme, et al. Standards Track [Page 28]