As per Relevance of the word internet, we have this rfc below:
Network Working Group N.
Request for Comments: 2045
Obsoletes: 1521, 1522, 1590 N.
Category: Standards Track First
November 1996
Multipurpose Internet Mail
(MIME) Part One
Format of Internet Message
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
STD 11, RFC 822, defines a message representation protocol
considerable detail about US-ASCII message headers, and leaves
message content, or message body, as flat US-ASCII text. This set
documents, collectively called the Multipurpose Internet
Extensions, or MIME, redefines the format of messages to allow
(1) textual message bodies in character sets other
US-ASCII
(2) an extensible set of different formats for non-
message bodies
(3) multi-part message bodies,
(4) textual header information in character sets other
US-ASCII
These documents are based on earlier work documented in RFC 934,
11, and RFC 1049, but extends and revises them. Because RFC 822
so little about message bodies, these documents are
orthogonal to (rather than a revision of) RFC 822.
This initial document specifies the various headers used to
the structure of MIME messages. The second document, RFC 2046,
defines the general structure of the MIME media typing system
defines an initial set of media types. The third document, RFC 2047,
describes extensions to RFC 822 to allow non-US-ASCII text data
Freed & Borenstein Standards Track [Page 1]
RFC 2045 Internet Message Bodies November 1996
Internet mail header fields. The fourth document, RFC 2048,
various IANA registration procedures for MIME-related facilities.
fifth and final document, RFC 2049, describes MIME
criteria as well as providing some illustrative examples of
message formats, acknowledgements, and the bibliography
These documents are revisions of RFCs 1521, 1522, and 1590,
themselves were revisions of RFCs 1341 and 1342. An appendix in
2049 describes differences and changes from previous versions
Table of
1. Introduction ......................................... 3
2. Definitions, Conventions, and Generic BNF Grammar .... 5
2.1 CRLF ................................................ 5
2.2 Character Set ....................................... 6
2.3 Message ............................................. 6
2.4 Entity .............................................. 6
2.5 Body Part ........................................... 7
2.6 Body ................................................ 7
2.7 7bit Data ........................................... 7
2.8 8bit Data ........................................... 7
2.9 Binary Data ......................................... 7
2.10 Lines .............................................. 7
3. MIME Header Fields ................................... 8
4. MIME-Version Header Field ............................ 8
5. Content-Type Header Field ............................ 10
5.1 Syntax of the Content-Type Header Field ............. 12
5.2 Content-Type Defaults ............................... 14
6. Content-Transfer-Encoding Header Field ............... 14
6.1 Content-Transfer-Encoding Syntax .................... 14
6.2 Content-Transfer-Encodings Semantics ................ 15
6.3 New Content-Transfer-Encodings ...................... 16
6.4 Interpretation and Use .............................. 16
6.5 Translating Encodings ............................... 18
6.6 Canonical Encoding Model ............................ 19
6.7 Quoted-Printable Content-Transfer-Encoding .......... 19
6.8 Base64 Content-Transfer-Encoding .................... 24
7. Content-ID Header Field .............................. 26
8. Content-Description Header Field ..................... 27
9. Additional MIME Header Fields ........................ 27
10. Summary ............................................. 27
11. Security Considerations ............................. 27
12. Authors' Addresses .................................. 28
A. Collected Grammar .................................... 29
Freed & Borenstein Standards Track [Page 2]
RFC 2045 Internet Message Bodies November 1996
1.
Since its publication in 1982, RFC 822 has defined the
format of textual mail messages on the Internet. Its success
been such that the RFC 822 format has been adopted, wholly
partially, well beyond the confines of the Internet and the
SMTP transport defined by RFC 821. As the format has seen wider use
a number of limitations have proven increasingly restrictive for
user community
RFC 822 was intended to specify a format for text messages. As such
non-text messages, such as multimedia messages that might
audio or images, are simply not mentioned. Even in the case of text
however, RFC 822 is inadequate for the needs of mail users
languages require the use of character sets richer than US-ASCII
Since RFC 822 does not specify mechanisms for mail containing audio
video, Asian language text, or even text in most European languages
additional specifications are needed
One of the notable limitations of RFC 821/822 based mail systems
the fact that they limit the contents of electronic mail messages
relatively short lines (e.g. 1000 characters or less [RFC-821])
7bit US-ASCII. This forces users to convert any non-textual
that they may wish to send into seven-bit bytes representable
printable US-ASCII characters before invoking a local mail UA (
Agent, a program with which human users send and receive mail).
Examples of such encodings currently used in the Internet
pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified
RFC 1421, the Andrew Toolkit Representation [ATK], and many others
The limitations of RFC 822 mail become even more apparent as
are designed to allow for the exchange of mail messages between
822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for
inclusion of non-textual material within electronic mail messages
The current standards for the mapping of X.400 messages to RFC 822
messages specify either that X.400 non-textual material must
converted to (not encoded in) IA5Text format, or that they must
discarded, notifying the RFC 822 user that discarding has occurred
This is clearly undesirable, as information that a user may wish
receive is lost. Even though a user agent may not have
capability of dealing with the non-textual material, the user
have some mechanism external to the UA that can extract
information from the material. Moreover, it does not allow for
fact that the message may eventually be gatewayed back into an X.400
message handling system (i.e., the X.400 message is "tunneled
through Internet mail), where the non-textual information
definitely become useful again
Freed & Borenstein Standards Track [Page 3]
RFC 2045 Internet Message Bodies November 1996
This document describes several mechanisms that combine to solve
of these problems without introducing any serious
with the existing world of RFC 822 mail. In particular,
describes
(1) A MIME-Version header field, which uses a
number to declare a message to be conformant with
and allows mail processing agents to
between such messages and those generated by older
non-conformant software, which are presumed to
such a field
(2) A Content-Type header field, generalized from RFC 1049,
which can be used to specify the media type and
of data in the body of a message and to fully
the native representation (canonical form) of
data
(3) A Content-Transfer-Encoding header field, which can
used to specify both the encoding transformation
was applied to the body and the domain of the result
Encoding transformations other than the
transformation are usually applied to data in order
allow it to pass through mail transport
which may have data or character set limitations
(4) Two additional header fields that can be used
further describe the data in a body, the Content-ID
Content-Description header fields
All of the header fields defined in this document are subject to
general syntactic rules for header fields specified in RFC 822.
particular, all of these header fields except for Content-
can include RFC 822 comments, which have no semantic content
should be ignored during MIME processing
Finally, to specify and promote interoperability, RFC 2049 provides
basic applicability statement for a subset of the above
that defines a minimal level of "conformance" with this document
HISTORICAL NOTE: Several of the mechanisms described in this set
documents may seem somewhat strange or even baroque at first reading
It is important to note that compatibility with existing
AND robustness across existing practice were two of the
priorities of the working group that developed this set of documents
In particular, compatibility was always favored over elegance
Freed & Borenstein Standards Track [Page 4]
RFC 2045 Internet Message Bodies November 1996
Please refer to the current edition of the "Internet
Protocol Standards" for the standardization state and status of
protocol. RFC 822 and STD 3, RFC 1123 also provide
background for MIME since no conforming implementation of MIME
violate them. In addition, several other informational RFC
will be of interest to the MIME implementor, in particular RFC 1344,
RFC 1345, and RFC 1524.
2. Definitions, Conventions, and Generic BNF
Although the mechanisms specified in this set of documents are
described in prose, most are also described formally in the
BNF notation of RFC 822. Implementors will need to be familiar
this notation in order to understand this set of documents, and
referred to RFC 822 for a complete explanation of the augmented
notation
Some of the augmented BNF in this set of documents makes
references to syntax rules defined in RFC 822. A complete
grammar, then, is obtained by combining the collected
appendices in each document in this set with the BNF of RFC 822
the modifications to RFC 822 defined in RFC 1123 (which
changes the syntax for `return', `date' and `mailbox').
All numeric and octet values are given in decimal notation in
set of documents. All media type values, subtype values,
parameter names as defined are case-insensitive. However,
values are case-sensitive unless otherwise specified for the
parameter
FORMATTING NOTE: Notes, such at this one, provide
nonessential information which may be skipped by the reader
missing anything essential. The primary purpose of these non
essential notes is to convey information about the rationale of
set of documents, or to place these documents in the
historical or evolutionary context. Such information may
particular be skipped by those who are focused entirely on building
conformant implementation, but may be of use to those who wish
understand why certain design choices were made
2.1.
The term CRLF, in this set of documents, refers to the sequence
octets corresponding to the two US-ASCII characters CR (decimal
13) and LF (decimal value 10) which, taken together, in this order
denote a line break in RFC 822 mail
Freed & Borenstein Standards Track [Page 5]
RFC 2045 Internet Message Bodies November 1996
2.2. Character
The term "character set" is used in MIME to refer to a method
converting a sequence of octets into a sequence of characters.
that unconditional and unambiguous conversion in the other
is not required, in that not all characters may be representable by
given character set and a character set may provide more than
sequence of octets to represent a particular sequence of characters
This definition is intended to allow various kinds of
encodings, from simple single-table mappings such as US-ASCII
complex table switching methods such as those that use ISO 2022'
techniques, to be used as character sets. However, the
associated with a MIME character set name must fully specify
mapping to be performed. In particular, use of external
information to determine the exact mapping is not permitted
NOTE: The term "character set" was originally to describe
straightforward schemes as US-ASCII and ISO-8859-1 which have
simple one-to-one mapping from single octets to single characters
Multi-octet coded character sets and switching techniques make
situation more complex. For example, some communities use the
"character encoding" for what MIME calls a "character set",
using the phrase "coded character set" to denote an abstract
from integers (not octets) to characters
2.3.
The term "message", when not further qualified, means either
(complete or "top-level") RFC 822 message being transferred on
network, or a message encapsulated in a body of type "message/rfc822"
or "message/partial".
2.4.
The term "entity", refers specifically to the MIME-defined
fields and contents of either a message or one of the parts in
body of a multipart entity. The specification of such entities
the essence of MIME. Since the contents of an entity are
called the "body", it makes sense to speak about the body of
entity. Any sort of field may be present in the header of an entity
but only those fields whose names begin with "content-" actually
any MIME-related meaning. Note that this does NOT imply thay
have no meaning at all -- an entity that is also a message has non
MIME header fields whose meanings are defined by RFC 822.
Freed & Borenstein Standards Track [Page 6]
RFC 2045 Internet Message Bodies November 1996
2.5. Body
The term "body part" refers to an entity inside of a
entity
2.6.
The term "body", when not further qualified, means the body of
entity, that is, the body of either a message or of a body part
NOTE: The previous four definitions are clearly circular. This
unavoidable, since the overall structure of a MIME message is
recursive
2.7. 7bit
"7bit data" refers to data that is all represented as
short lines with 998 octets or less between CRLF line
sequences [RFC-821]. No octets with decimal values greater than 127
are allowed and neither are NULs (octets with decimal value 0).
(decimal value 13) and LF (decimal value 10) octets only occur
part of CRLF line separation sequences
2.8. 8bit
"8bit data" refers to data that is all represented as
short lines with 998 octets or less between CRLF line
sequences [RFC-821]), but octets with decimal values greater than 127
may be used. As with "7bit data" CR and LF octets only occur as
of CRLF line separation sequences and no NULs are allowed
2.9. Binary
"Binary data" refers to data where any sequence of octets
is allowed
2.10.
"Lines" are defined as sequences of octets separated by a
sequences. This is consistent with both RFC 821 and RFC 822.
"Lines" only refers to a unit of data in a message, which may or
not correspond to something that is actually displayed by a
agent
Freed & Borenstein Standards Track [Page 7]
RFC 2045 Internet Message Bodies November 1996
3. MIME Header
MIME defines a number of new RFC 822 header fields that are used
describe the content of a MIME entity. These header fields occur
at least two contexts
(1) As part of a regular RFC 822 message header
(2) In a MIME body part header within a
construct
The formal definition of these header fields is as follows
entity-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
*( MIME-extension-field CRLF )
MIME-message-headers := entity-
version
; The ordering of the
; fields implied by this
; definition should be ignored
MIME-part-headers := entity-
[ fields ]
; Any field not beginning
; "content-" can have no
; meaning and may be ignored
; The ordering of the
; fields implied by this
; definition should be ignored
The syntax of the various specific MIME header fields will
described in the following sections
4. MIME-Version Header
Since RFC 822 was published in 1982, there has really been only
format standard for Internet messages, and there has been
perceived need to declare the format standard in use. This
is an independent specification that complements RFC 822.
the extensions in this document have been defined in such a way as
be compatible with RFC 822, there are still circumstances in which
might be desirable for a mail-processing agent to know whether
message was composed with the new standard in mind
Freed & Borenstein Standards Track [Page 8]
RFC 2045 Internet Message Bodies November 1996
Therefore, this document defines a new header field, "MIME-Version",
which is to be used to declare the version of the Internet
body format standard in use
Messages composed in accordance with this document MUST include
a header field, with the following verbatim text
MIME-Version: 1.0
The presence of this header field is an assertion that the
has been composed in compliance with this document
Since it is possible that a future document might extend the
format standard again, a formal BNF is given for the content of
MIME-Version field
version := "MIME-Version" ":" 1*DIGIT "." 1*
Thus, future format specifiers, which might replace or extend "1.0",
are constrained to be two integer fields, separated by a period.
a message is received with a MIME-version value other than "1.0",
cannot be assumed to conform with this document
Note that the MIME-Version header field is required at the top
of a message. It is not required for each body part of a
entity. It is required for the embedded headers of a body of
"message/rfc822" or "message/partial" if and only if the
message is itself claimed to be MIME-conformant
It is not possible to fully specify how a mail reader that
with MIME as defined in this document should treat a message
might arrive in the future with some value of MIME-Version other
"1.0".
It is also worth noting that version control for specific media
is not accomplished using the MIME-Version mechanism. In particular
some formats (such as application/postscript) have version
conventions that are internal to the media format. Where
conventions exist, MIME does nothing to supersede them. Where
such conventions exist, a MIME media type might use a "version
parameter in the content-type field if necessary
Freed & Borenstein Standards Track [Page 9]
RFC 2045 Internet Message Bodies November 1996
NOTE TO IMPLEMENTORS: When checking MIME-Version values any RFC 822
comment strings that are present must be ignored. In particular,
following four MIME-Version fields are equivalent
MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0
In the absence of a MIME-Version field, a receiving mail user
(whether conforming to MIME requirements or not) may
choose to interpret the body of the message according to
conventions. Many such conventions are currently in use and
should be noted that in practice non-MIME messages can contain
about anything
It is impossible to be certain that a non-MIME mail message
actually plain text in the US-ASCII character set since it might
be a message that, using some set of nonstandard local
that predate MIME, includes text in another character set or non
textual data presented in a manner that cannot be
recognized (e.g., a uuencoded compressed UNIX tar file).
5. Content-Type Header
The purpose of the Content-Type field is to describe the
contained in the body fully enough that the receiving user agent
pick an appropriate agent or mechanism to present the data to
user, or otherwise deal with the data in an appropriate manner.
value in this field is called a media type
HISTORICAL NOTE: The Content-Type header field was first defined
RFC 1049. RFC 1049 used a simpler and less powerful syntax, but
that is largely compatible with the mechanism given here
The Content-Type header field specifies the nature of the data in
body of an entity by giving media type and subtype identifiers,
by providing auxiliary information that may be required for
media types. After the media type and subtype names, the
of the header field is simply a set of parameters, specified in
attribute=value notation. The ordering of parameters is
significant
Freed & Borenstein Standards Track [Page 10]
RFC 2045 Internet Message Bodies November 1996
In general, the top-level media type is used to declare the
type of data, while the subtype specifies a specific format for
type of data. Thus, a media type of "image/xyz" is enough to tell
user agent that the data is an image, even if the user agent has
knowledge of the specific image format "xyz". Such information
be used, for example, to decide whether or not to show a user the
data from an unrecognized subtype -- such an action might
reasonable for unrecognized subtypes of text, but not
unrecognized subtypes of image or audio. For this reason,
subtypes of text, image, audio, and video should not contain
information that is really of a different type. Such
formats should be represented using the "multipart" or "application
types
Parameters are modifiers of the media subtype, and as such do
fundamentally affect the nature of the content. The set
meaningful parameters depends on the media type and subtype.
parameters are associated with a single specific subtype. However,
given top-level media type may define parameters which are
to any subtype of that type. Parameters may be required by
defining content type or subtype or they may be optional.
implementations must ignore any parameters whose names they do
recognize
For example, the "charset" parameter is applicable to any subtype
"text", while the "boundary" parameter is required for any subtype
the "multipart" media type
There are NO globally-meaningful parameters that apply to all
types. Truly global mechanisms are best addressed, in the
model, by the definition of additional Content-* header fields
An initial set of seven top-level media types is defined in RFC 2046.
Five of these are discrete types whose content is essentially
as far as MIME processing is concerned. The remaining two
composite types whose contents require additional handling by
processors
This set of top-level media types is intended to be
complete. It is expected that additions to the larger set
supported types can generally be accomplished by the creation of
subtypes of these initial types. In the future, more top-level
may be defined only by a standards-track extension to this standard
If another top-level type is to be used for any reason, it must
given a name starting with "X-" to indicate its non-standard
and to avoid a potential conflict with a future official name
Freed & Borenstein Standards Track [Page 11]
RFC 2045 Internet Message Bodies November 1996
5.1. Syntax of the Content-Type Header
In the Augmented BNF notation of RFC 822, a Content-Type header
value is defined as follows
content := "Content-Type" ":" type "/"
*(";" parameter
; Matching of media type and
; is ALWAYS case-insensitive
type := discrete-type / composite-
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-
composite-type := "message" / "multipart" / extension-
extension-token := ietf-token / x-
ietf-token := extension token defined by
standards-track RFC and
with IANA.>
x-token := followed,
no intervening white space, by any token
subtype := extension-token / iana-
iana-token := extension token.
of this form must be registered with
as specified in RFC 2048.>
parameter := attribute "="
attribute :=
; Matching of
; is ALWAYS case-insensitive
value := token / quoted-
token := 1*
or tspecials
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string
; to use within parameter
Freed & Borenstein Standards Track [Page 12]
RFC 2045 Internet Message Bodies November 1996
Note that the definition of "tspecials" is the same as the RFC 822
definition of "specials" with the addition of the three
"/", "?", and "=", and the removal of ".".
Note also that a subtype specification is MANDATORY -- it may not
omitted from a Content-Type header field. As such, there are
default subtypes
The type, subtype, and parameter names are not case sensitive.
example, TEXT, Text, and TeXt are all equivalent top-level
types. Parameter values are normally case sensitive, but
are interpreted in a case-insensitive fashion, depending on
intended use. (For example, multipart boundaries are case-sensitive
but the "access-type" parameter for message/External-body is
case-sensitive.)
Note that the value of a quoted string parameter does not include
quotes. That is, the quotation marks in a quoted-string are not
part of the value of the parameter, but are merely used to
that parameter value. In addition, comments are allowed
accordance with RFC 822 rules for structured header fields. Thus
following two
Content-type: text/plain; charset=us-ascii (Plain text
Content-type: text/plain; charset="us-ascii
are completely equivalent
Beyond this syntax, the only syntactic constraint on the
of subtype names is the desire that their uses must not conflict
That is, it would be undesirable to have two different
using "Content-Type: application/foobar" to mean two
things. The process of defining new media subtypes, then, is
intended to be a mechanism for imposing restrictions, but simply
mechanism for publicizing their definition and usage. There are
therefore, two acceptable mechanisms for defining new media subtypes
(1) Private values (starting with "X-") may be
bilaterally between two cooperating agents
outside registration or standardization. Such
cannot be registered or standardized
(2) New standard values should be registered with IANA
described in RFC 2048.
The second document in this set, RFC 2046, defines the initial set
media types for MIME
Freed & Borenstein Standards Track [Page 13]
RFC 2045 Internet Message Bodies November 1996
5.2. Content-Type
Default RFC 822 messages without a MIME Content-Type header are
by this protocol to be plain text in the US-ASCII character set
which can be explicitly specified as
Content-type: text/plain; charset=us-
This default is assumed if no Content-Type header field is specified
It is also recommend that this default be assumed when
syntactically invalid Content-Type header field is encountered.
the presence of a MIME-Version header field and the absence of
Content-Type header field, a receiving User Agent can also
that plain US-ASCII text was the sender's intent. Plain US-
text may still be assumed in the absence of a MIME-Version or
presence of an syntactically invalid Content-Type header field,
the sender's intent might have been otherwise
6. Content-Transfer-Encoding Header
Many media types which could be usefully transported via email
represented, in their "natural" format, as 8bit character or
data. Such data cannot be transmitted over some transfer protocols
For example, RFC 821 (SMTP) restricts mail messages to 7bit US-
data with lines no longer than 1000 characters including any
CRLF line separator
It is necessary, therefore, to define a standard mechanism
encoding such data into a 7bit short line format. Proper
of unencoded material in less restrictive formats for direct use
less restrictive transports is also desireable. This
specifies that such encodings will be indicated by a new "Content
Transfer-Encoding" header field. This field has not been defined
any previous standard
6.1. Content-Transfer-Encoding
The Content-Transfer-Encoding field's value is a single
specifying the type of encoding, as enumerated below. Formally
encoding := "Content-Transfer-Encoding" ":"
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-
These values are not case sensitive -- Base64 and BASE64 and bAsE64
are all equivalent. An encoding type of 7BIT requires that the
Freed & Borenstein Standards Track [Page 14]
RFC 2045 Internet Message Bodies November 1996
is already in a 7bit mail-ready representation. This is the
value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if
Content-Transfer-Encoding header field is not present
6.2. Content-Transfer-Encodings
This single Content-Transfer-Encoding token actually provides
pieces of information. It specifies what sort of
transformation the body was subjected to and hence what
operation must be used to restore it to its original form, and
specifies what the domain of the result is
The transformation part of any Content-Transfer-Encodings specifies
either explicitly or implicitly, a single, well-defined
algorithm, which for any sequence of encoded octets either
it to the original sequence of octets which was encoded, or
that it is illegal as an encoded sequence. Content-Transfer
Encodings transformations never depend on any additional
profile information for proper operation. Note that while
must produce a single, well-defined output for a valid encoding
such restrictions exist for encoders: Encoding a given sequence
octets to different, equivalent encoded sequences is perfectly legal
Three transformations are currently defined: identity, the "quoted
printable" encoding, and the "base64" encoding. The domains
"binary", "8bit" and "7bit".
The Content-Transfer-Encoding values "7bit", "8bit", and "binary"
mean that the identity (i.e. NO) encoding transformation has
performed. As such, they serve simply as indicators of the domain
the body data, and provide useful information about the sort
encoding that might be needed for transmission in a given
system. The terms "7bit data", "8bit data", and "binary data"
all defined in Section 2.
The quoted-printable and base64 encodings transform their input
an arbitrary domain into material in the "7bit" range, thus making
safe to carry over restricted transports. The specific definition
the transformations are given below
The proper Content-Transfer-Encoding label must always be used
Labelling unencoded data containing 8bit characters as "7bit" is
allowed, nor is labelling unencoded non-line-oriented data
anything other than "binary" allowed
Unlike media subtypes, a proliferation of Content-Transfer-
values is both undesirable and unnecessary. However,
only a single transformation into the "7bit" domain does not
Freed & Borenstein Standards Track [Page 15]
RFC 2045 Internet Message Bodies November 1996
possible. There is a tradeoff between the desire for a compact
efficient encoding of largely- binary data and the desire for
somewhat readable encoding of data that is mostly, but not entirely
7bit. For this reason, at least two encoding mechanisms
necessary: a more or less readable encoding (quoted-printable) and
"dense" or "uniform" encoding (base64).
Mail transport for unencoded 8bit data is defined in RFC 1652. As
the initial publication of this document, there are no
Internet mail transports for which it is legitimate to
unencoded binary data in mail bodies. Thus there are
circumstances in which the "binary" Content-Transfer-Encoding
actually valid in Internet mail. However, in the event that
mail transport becomes a reality in Internet mail, or when MIME
used in conjunction with any other binary-capable mail
mechanism, binary bodies must be labelled as such using
mechanism
NOTE: The five values defined for the Content-Transfer-Encoding
imply nothing about the media type other than the algorithm by
it was encoded or the transport system requirements if unencoded
6.3. New Content-Transfer-
Implementors may, if necessary, define private Content-Transfer
Encoding values, but must use an x-token, which is a name prefixed
"X-", to indicate its non-standard status, e.g., "Content-Transfer
Encoding: x-my-new-encoding". Additional standardized Content
Transfer-Encoding values must be specified by a standards-track RFC
The requirements such specifications must meet are given in RFC 2048.
As such, all content-transfer-encoding namespace except
beginning with "X-" is explicitly reserved to the IETF for
use
Unlike media types and subtypes, the creation of new Content
Transfer-Encoding values is STRONGLY discouraged, as it seems
to hinder interoperability with little potential
6.4. Interpretation and
If a Content-Transfer-Encoding header field appears as part of
message header, it applies to the entire body of that message. If
Content-Transfer-Encoding header field appears as part of an entity'
headers, it applies only to the body of that entity. If an entity
of type "multipart" the Content-Transfer-Encoding is not permitted
have any value other than "7bit", "8bit" or "binary". Even
severe restrictions apply to some subtypes of the "message" type
Freed & Borenstein Standards Track [Page 16]
RFC 2045 Internet Message Bodies November 1996
It should be noted that most media types are defined in terms
octets rather than bits, so that the mechanisms described here
mechanisms for encoding arbitrary octet streams, not bit streams.
a bit stream is to be encoded via one of these mechanisms, it
first be converted to an 8bit byte stream using the network
bit order ("big-endian"), in which the earlier bits in a
become the higher-order bits in a 8bit byte. A bit stream not
at an 8bit boundary must be padded with zeroes. RFC 2046 provides
mechanism for noting the addition of such padding in the case of
application/octet-stream media type, which has a "padding" parameter
The encoding mechanisms defined here explicitly encode all data
US-ASCII. Thus, for example, suppose an entity has header
such as
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
This must be interpreted to mean that the body is a base64 US-
encoding of data that was originally in ISO-8859-1, and will be
that character set again after decoding
Certain Content-Transfer-Encoding values may only be used on
media types. In particular, it is EXPRESSLY FORBIDDEN to use
encodings other than "7bit", "8bit", or "binary" with any
media type, i.e. one that recursively includes other Content-
fields. Currently the only composite media types are "multipart"
"message". All encodings that are desired for bodies of
multipart or message must be done at the innermost level, by
the actual body that needs to be encoded
It should also be noted that, by definition, if a composite
has a transfer-encoding value such as "7bit", but one of the
entities has a less restrictive value such as "8bit", then either
outer "7bit" labelling is in error, because 8bit data are included
or the inner "8bit" labelling placed an unnecessarily high demand
the transport system because the actual included data were
7bit-safe
NOTE ON ENCODING RESTRICTIONS: Though the prohibition against
content-transfer-encodings on composite body data may seem
restrictive, it is necessary to prevent nested encodings, in
data are passed through an encoding algorithm multiple times,
must be decoded multiple times in order to be properly viewed
Nested encodings add considerable complexity to user agents:
from the obvious efficiency problems with such multiple encodings
they can obscure the basic structure of a message. In particular
they can imply that several decoding operations are necessary
Freed & Borenstein Standards Track [Page 17]
RFC 2045 Internet Message Bodies November 1996
to find out what types of bodies a message contains. Banning
encodings may complicate the job of certain mail gateways, but
seems less of a problem than the effect of nested encodings on
agents
Any entity with an unrecognized Content-Transfer-Encoding must
treated as if it has a Content-Type of "application/octet-stream",
regardless of what the Content-Type header field actually says
NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-TRANSFER
ENCODING: It may seem that the Content-Transfer-Encoding could
inferred from the characteristics of the media that is to be encoded
or, at the very least, that certain Content-Transfer-Encodings
be mandated for use with specific media types. There are
reasons why this is not the case. First, given the varying types
transports used for mail, some encodings may be appropriate for
combinations of media types and transports but not for others. (
example, in an 8bit transport, no encoding would be required for
in certain character sets, while such encodings are clearly
for 7bit SMTP.)
Second, certain media types may require different types of
encoding under different circumstances. For example, many
bodies might consist entirely of short lines of 7bit data and
require no encoding at all. Other PostScript bodies (
those using Level 2 PostScript's binary encoding mechanism) may
be reasonably represented using a binary transport encoding
Finally, since the Content-Type field is intended to be an open-
specification mechanism, strict specification of an
between media types and encodings effectively couples
specification of an application protocol with a specific lower-
transport. This is not desirable since the developers of a
type should not have to be aware of all the transports in use
what their limitations are
6.5. Translating
The quoted-printable and base64 encodings are designed so
conversion between them is possible. The only issue that arises
such a conversion is the handling of hard line breaks in quoted
printable encoding output. When converting from quoted-printable
base64 a hard line break in the quoted-printable form represents
CRLF sequence in the canonical form of the data. It must therefore
converted to a corresponding encoded CRLF in the base64 form of
data. Similarly, a CRLF sequence in the canonical form of the
obtained after base64 decoding must be converted to a quoted
printable hard line break, but ONLY when converting text data
Freed & Borenstein Standards Track [Page 18]
RFC 2045 Internet Message Bodies November 1996
6.6. Canonical Encoding
There was some confusion, in the previous versions of this RFC
regarding the model for when email data was to be converted
canonical form and encoded, and in particular how this process
affect the treatment of CRLFs, given that the representation
newlines varies greatly from system to system, and the
between content-transfer-encodings and character sets. A
model for encoding is presented in RFC 2049 for this reason
6.7. Quoted-Printable Content-Transfer-
The Quoted-Printable encoding is intended to represent data
largely consists of octets that correspond to printable characters
the US-ASCII character set. It encodes the data in such a way
the resulting octets are unlikely to be modified by mail transport
If the data being encoded are mostly US-ASCII text, the encoded
of the data remains largely recognizable by humans. A body which
entirely US-ASCII may also be encoded in Quoted-Printable to
the integrity of the data should the message pass through
character-translating, and/or line-wrapping gateway
In this encoding, octets are to be represented as determined by
following rules
(1) (General 8bit representation) Any octet, except a CR
LF that is part of a CRLF line break of the
(standard) form of the data being encoded, may
represented by an "=" followed by a two
hexadecimal representation of the octet's value.
digits of the hexadecimal alphabet, for this purpose
are "0123456789ABCDEF". Uppercase letters must
used; lowercase letters are not allowed. Thus,
example, the decimal value 12 (US-ASCII form feed)
be represented by "=0C", and the decimal value 61 (US
ASCII EQUAL SIGN) can be represented by "=3D".
rule must be followed except when the following
allow an alternative encoding
(2) (Literal representation) Octets with decimal values
33 through 60 inclusive, and 62 through 126, inclusive
MAY be represented as the US-ASCII characters
correspond to those octets (EXCLAMATION POINT
LESS THAN, and GREATER THAN through TILDE
respectively).
(3) (White Space) Octets with values of 9 and 32 MAY
represented as US-ASCII TAB (HT) and SPACE characters
Freed & Borenstein Standards Track [Page 19]
RFC 2045 Internet Message Bodies November 1996
respectively, but MUST NOT be so represented at the
of an encoded line. Any TAB (HT) or SPACE
on an encoded line MUST thus be followed on that
by a printable character. In particular, an "=" at
end of an encoded line, indicating a soft line
(see rule #5) may follow one or more TAB (HT) or
characters. It follows that an octet with
value 9 or 32 appearing at the end of an encoded
must be represented according to Rule #1. This rule
necessary because some MTAs (Message Transport Agents
programs which transport messages from one user
another, or perform a portion of such transfers)
known to pad lines of text with SPACEs, and others
known to remove "white space" characters from the
of a line. Therefore, when decoding a Quoted-
body, any trailing white space on a line must
deleted, as it will necessarily have been added
intermediate transport agents
(4) (Line Breaks) A line break in a text body,
as a CRLF sequence in the text canonical form, must
represented by a (RFC 822) line break, which is also
CRLF sequence, in the Quoted-Printable encoding.
the canonical representation of media types other
text do not generally include the representation
line breaks as CRLF sequences, no hard line
(i.e. line breaks that are intended to be
and to be displayed to the user) can occur in
quoted-printable encoding of such types.
like "=0D", "=0A", "=0A=0D" and "=0D=0A" will
appear in non-text data represented in quoted
printable, of course
Note that many implementations may elect to encode
local representation of various content types
rather than converting to canonical form first
encoding, and then converting back to
representation. In particular, this may apply to
text material on systems that use newline
other than a CRLF terminator sequence. Such
implementation optimization is permissible, but
when the combined canonicalization-encoding step
equivalent to performing the three steps separately
(5) (Soft Line Breaks) The Quoted-Printable
REQUIRES that encoded lines be no more than 76
characters long. If longer lines are to be
with the Quoted-Printable encoding, "soft" line
Freed & Borenstein Standards Track [Page 20]
RFC 2045 Internet Message Bodies November 1996
must be used. An equal sign as the last character on
encoded line indicates such a non-significant ("soft")
line break in the encoded text
Thus if the "raw" form of the line is a single unencoded line
says
Now's the time for all folk to come to the aid of their country
This can be represented, in the Quoted-Printable encoding, as
Now's the time =
for all folk to come
to the aid of their country
This provides a mechanism with which long lines are encoded in such
way as to be restored by the user agent. The 76 character limit
not count the trailing CRLF, but counts all other characters
including any equal signs
Since the hyphen character ("-") may be represented as itself in
Quoted-Printable encoding, care must be taken, when encapsulating
quoted-printable encoded body inside one or more multipart entities
to ensure that the boundary delimiter does not appear anywhere in
encoded body. (A good strategy is to choose a boundary that
a character sequence such as "=_" which can never appear in
quoted-printable body. See the definition of multipart messages
RFC 2046.)
NOTE: The quoted-printable encoding represents something of
compromise between readability and reliability in transport.
encoded with the quoted-printable encoding will work reliably
most mail gateways, but may not work perfectly over a few gateways
notably those involving translation into EBCDIC. A higher level
confidence is offered by the base64 Content-Transfer-Encoding. A
to get reasonably reliable transport through EBCDIC gateways is
also quote the US-ASCII
!"#$@[\]^`{|}~
according to rule #1.
Because quoted-printable data is generally assumed to be line
oriented, it is to be expected that the representation of the
between the lines of quoted-printable data may be altered
transport, in the same manner that plain text mail has always
altered in Internet mail when passing between systems with
newline conventions. If such alterations are likely to constitute
Freed & Borenstein Standards Track [Page 21]
RFC 2045 Internet Message Bodies November 1996
corruption of the data, it is probably more sensible to use
base64 encoding rather than the quoted-printable encoding
NOTE: Several kinds of substrings cannot be generated according
the encoding rules for the quoted-printable content-transfer
encoding, and hence are formally illegal if they appear in the
of a quoted-printable encoder. This note enumerates these cases
suggests ways to handle such illegal substrings if any
encountered in quoted-printable data that is to be decoded
(1) An "=" followed by two hexadecimal digits, one or
of which are lowercase letters in "abcdef", is
illegal. A robust implementation might choose
recognize them as the corresponding uppercase letters
(2) An "=" followed by a character that is neither
hexadecimal digit (including "abcdef") nor the
character of a CRLF pair is illegal. This case can
the result of US-ASCII text having been included in
quoted-printable part of a message without
having been subjected to quoted-printable encoding.
reasonable approach by a robust implementation might
to include the "=" character and the
character in the decoded data without
transformation and, if possible, indicate to the
that proper decoding was not possible at this point
the data
(3) An "=" cannot be the ultimate or penultimate
in an encoded object. This could be handled as in
(2) above
(4) Control characters other than TAB, or CR and LF
parts of CRLF pairs, must not appear. The same is
for octets with decimal values greater than 126.
found in incoming quoted-printable data by a decoder,
robust implementation might exclude them from
decoded data and warn the user that illegal
were discovered
(5) Encoded lines must not be longer than 76 characters
not counting the trailing CRLF. If longer lines
found in incoming, encoded data, a
implementation might nevertheless decode the lines,
might report the erroneous encoding to the user
Freed & Borenstein Standards Track [Page 22]
RFC 2045 Internet Message Bodies November 1996
WARNING TO IMPLEMENTORS: If binary data is encoded in quoted
printable, care must be taken to encode CR and LF characters as "=0D
and "=0A", respectively. In particular, a CRLF sequence in
data should be encoded as "=0D=0A". Otherwise, if CRLF
represented as a hard line break, it might be incorrectly decoded
platforms with different line break conventions
For formalists, the syntax of quoted-printable data is described
the following grammar
quoted-printable := qp-line *(CRLF qp-line
qp-line := *(qp-segment transport-padding CRLF
qp-part transport-
qp-part := qp-
; Maximum length of 76
qp-segment := qp-section *(SPACE / TAB) "="
; Maximum length of 76
qp-section := [*(ptext / SPACE / TAB) ptext
ptext := hex-octet / safe-
safe-char :=
60 inclusive, and 62 through 126>
; Characters not listed as "mail-safe"
; RFC 2049 are also not recommended
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; Octet must be used for characters > 127, =,
; SPACEs or TABs at the ends of lines, and
; recommended for any character not listed
; RFC 2049 as "mail-safe".
transport-padding := *LWSP-
; Composers MUST NOT
; non-zero length
; padding, but receivers
; be able to handle
; added by message transports
IMPORTANT: The addition of LWSP between the elements shown in
BNF is NOT allowed since this BNF does not specify a
header field
Freed & Borenstein Standards Track [Page 23]
RFC 2045 Internet Message Bodies November 1996
6.8. Base64 Content-Transfer-
The Base64 Content-Transfer-Encoding is designed to
arbitrary sequences of octets in a form that need not be
readable. The encoding and decoding algorithms are simple, but
encoded data are consistently only about 33 percent larger than
unencoded data. This encoding is virtually identical to the one
in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
A 65-character subset of US-ASCII is used, enabling 6 bits to
represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.)
NOTE: This subset has the important property that it is
identically in all versions of ISO 646, including US-ASCII, and
characters in the subset are also represented identically in
versions of EBCDIC. Other popular encodings, such as the
used by the uuencode utility, Macintosh binhex 4.0 [RFC-1741],
the base85 encoding specified as part of Level 2 PostScript, do
share these properties, and thus do not fulfill the
requirements a binary transport encoding for mail must meet
The encoding process represents 24-bit groups of input bits as
strings of 4 encoded characters. Proceeding from left to right,
24-bit input group is formed by concatenating 3 8bit input groups
These 24 bits are then treated as 4 concatenated 6-bit groups,
of which is translated into a single digit in the base64 alphabet
When encoding a bit stream via the base64 encoding, the bit
must be presumed to be ordered with the most-significant-bit first
That is, the first bit in the stream will be the high-order bit
the first 8bit byte, and the eighth bit will be the low-order bit
the first 8bit byte, and so on
Each 6-bit group is used as an index into an array of 64
characters. The character referenced by the index is placed in
output string. These characters, identified in Table 1, below,
selected so as to be universally representable, and the set
characters with particular significance to SMTP (e.g., ".", CR, LF
and to the multipart boundary delimiters defined in RFC 2046 (e.g.,
"-").
Freed & Borenstein Standards Track [Page 24]
RFC 2045 Internet Message Bodies November 1996
Table 1: The Base64
Value Encoding Value Encoding Value Encoding Value
0 A 17 R 34 i 51
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47
14 O 31 f 48 w (pad) =
15 P 32 g 49
16 Q 33 h 50
The encoded output stream must be represented in lines of no
than 76 characters each. All line breaks or other characters
found in Table 1 must be ignored by decoding software. In base64
data, characters other than those in Table 1, line breaks, and
white space probably indicate a transmission error, about which
warning message or even a message rejection might be
under some circumstances
Special processing is performed if fewer than 24 bits are
at the end of the data being encoded. A full encoding quantum
always completed at the end of a body. When fewer than 24 input
are available in an input group, zero bits are added (on the right
to form an integral number of 6-bit groups. Padding at the end
the data is performed using the "=" character. Since all base64
input is an integral number of octets, only the following cases
arise: (1) the final quantum of encoding input is an
multiple of 24 bits; here, the final unit of encoded output will
an integral multiple of 4 characters with no "=" padding, (2)
final quantum of encoding input is exactly 8 bits; here, the
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input
exactly 16 bits; here, the final unit of encoded output will be
characters followed by one "=" padding character
Because it is used only for padding at the end of the data,
occurrence of any "=" characters may be taken as evidence that
end of the data has been reached (without truncation in transit).
Freed & Borenstein Standards Track [Page 25]
RFC 2045 Internet Message Bodies November 1996
such assurance is possible, however, when the number of
transmitted was a multiple of three and no "=" characters
present
Any characters outside of the base64 alphabet are to be ignored
base64-encoded data
Care must be taken to use the proper octets for line breaks if base64
encoding is applied directly to text material that has not
converted to canonical form. In particular, text line breaks must
converted into CRLF sequences prior to base64 encoding.
important thing to note is that this may be done directly by
encoder rather than in a prior canonicalization step in
implementations
NOTE: There is no need to worry about quoting potential
delimiters within base64-encoded bodies within multipart
because no hyphen characters are used in the base64 encoding
7. Content-ID Header
In constructing a high-level user agent, it may be desirable to
one body to make reference to another. Accordingly, bodies may
labelled using the "Content-ID" header field, which is
identical to the "Message-ID" header field
id := "Content-ID" ":" msg-
Like the Message-ID values, Content-ID values must be generated to
world-unique
The Content-ID value may be used for uniquely identifying
entities in several contexts, particularly for caching
referenced by the message/external-body mechanism. Although
Content-ID header is generally optional, its use is MANDATORY
implementations which generate data of the optional MIME media
"message/external-body". That is, each message/external-body
must have a Content-ID field to permit caching of such data
It is also worth noting that the Content-ID value has
semantics in the case of the multipart/alternative media type.
is explained in the section of RFC 2046 dealing
multipart/alternative
Freed & Borenstein Standards Track [Page 26]
RFC 2045 Internet Message Bodies November 1996
8. Content-Description Header
The ability to associate some descriptive information with a
body is often desirable. For example, it may be useful to mark
"image" body as "a picture of the Space Shuttle Endeavor." Such
may be placed in the Content-Description header field. This
field is always optional
description := "Content-Description" ":" *
The description is presumed to be given in the US-ASCII
set, although the mechanism specified in RFC 2047 may be used
non-US-ASCII Content-Description values
9. Additional MIME Header
Future documents may elect to define additional MIME header
for various purposes. Any new header field that further
the content of a message should begin with the string "Content-"
allow such fields which appear in a message header to
distinguished from ordinary RFC 822 message header fields
MIME-extension-field :=
begins with the
"Content-">
10.
Using the MIME-Version, Content-Type, and Content-Transfer-
header fields, it is possible to include, in a standardized way
arbitrary types of data with RFC 822 conformant mail messages.
restrictions imposed by either RFC 821 or RFC 822 are violated,
care has been taken to avoid problems caused by
restrictions imposed by the characteristics of some Internet
transport mechanisms (see RFC 2049).
