MIME
Encyclopedia
Multipurpose Internet Mail Extensions (MIME) is an Internet standard
that extends the format of email to support:
MIME's use, however, has grown beyond describing the content of email to describe content type in general, including for the web (see Internet media type
) and as a storage for rich content in some commercial products (e.g., IBM Lotus Domino
and IBM Lotus Quickr
).
Virtually all human-written Internet
email and a fairly large proportion of automated email is transmitted via SMTP
in MIME format. Internet email is so closely associated with the SMTP and MIME standards that it is sometimes called SMTP/MIME email.
The content types defined by MIME standards are also of importance outside of email, such as in communication protocols like HTTP
for the World Wide Web
. HTTP requires that data be transmitted in the context of email-like messages, although the data most often is not actually email.
MIME is specified in six linked RFC memoranda
: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 and RFC 2049, which together define the specifications.
characters (see also 8BITMIME).
This effectively limits Internet email to messages which, when transmitted, include only the characters sufficient for writing a small number of languages, primarily English
. Other languages based on the Latin alphabet
typically include diacritic
s and are not supported in 7-bit ASCII, meaning text in these languages cannot be correctly represented in basic email.
MIME defines mechanisms for sending other kinds of information in email. These include text in languages other than English using character encoding
s other than ASCII, and 8-bit binary content such as files containing image
s, sound
s, movies
, and computer program
s. MIME is also a fundamental component of communication protocols such as HTTP, which requires that data be transmitted in the context of email-like messages even though the data might not (and usually doesn't) actually have anything to do with email. Mapping messages into and out of MIME format is typically done automatically
by an email client or by mail servers
when sending or receiving Internet (SMTP/MIME) email.
The basic format of Internet email is defined in RFC 5322, which is an updated version of RFC 2822 and RFC 822. These standards specify the familiar formats for text email headers
and body and rules pertaining to commonly used header fields such as "To:", "Subject:", "From:", and "Date:".
MIME defines a collection of email headers for specifying additional attributes of a message including content type, and defines a set of transfer encodings which can be used to represent 8-bit binary data using characters from the 7-bit ASCII character set.
MIME also specifies rules for encoding non-ASCII characters in email message headers, such as "Subject:", allowing these header fields to contain non-English characters.
MIME is extensible. Its definition includes a method to register new content types and other MIME attribute values.
The goals of the MIME definition included requiring no changes to existent email servers and allowing plain text email to function in both directions with existing clients. These goals were achieved by using additional RFC 822-style headers for all MIME message attributes and by making the MIME headers optional with default values ensuring a non-MIME message is interpreted correctly by a MIME-capable client. A simple MIME text message is therefore likely to be interpreted correctly by a non-MIME client even if it has email headers which the non-MIME client won't know how to interpret. Similarly, if the quoted printable transfer encoding (see below) is used, the ASCII part of the message will be intelligible to users with non-MIME clients.
MIME-Version: 1.0
According to MIME co-creator Nathaniel Borenstein
, the intention was to allow MIME to change, to advance to version 2.0 and so forth, but this decision led to the opposite outcome, making it nearly impossible to create a new version of the standard.
"We did not adequately specify how to handle a future MIME version," Borenstein said. "So if you write something that knows 1.0, what should you do if you encounter 2.0 or 1.1? I sort of thought it was obvious but it turned out everyone implemented that in different ways. And the result is that it would be just about impossible for the Internet to ever define a 2.0 or a 1.1."
Content-ID: <5.31.32252.1057009685@server01.example.net>
The standards don't really have a lot to say about exactly what is in a Content-ID; they're only supposed to be globally and permanently unique (meaning that no two are ever the same, even when generated by different people in different times and places). To achieve this, some conventions have been adopted; one of them is to include an at sign (@), with the hostname of the computer which created the content ID to the right of it. This ensures the content ID is different from any created by other computers (well, at least it is when the originating computer has a unique Internet hostname; if, as sometimes happens, an anonymous machine inserts something generic like localhost, uniqueness is no longer guaranteed). Then, the part to the left of the at sign is designed to be unique within that machine; a good way to do this is to append several constantly-changing strings that programs have access to. In this case, four different numbers were inserted, with dots between them: the rightmost one is a timestamp of the number of seconds since January 1, 1970, known as the Unix epoch; to the left of it is the process ID of the program that generated the message (on servers running Unix or Linux, each process has a number which is unique among the processes in progress at any moment, though they do repeat over time); to the left of that is a count of the number of messages generated so far by the current process; and the leftmost number is the number of parts in the current message that have been generated so far. Put together, these guarantee that the content ID will never repeat; even if multiple messages are generated within the same second, they either have different process IDs or a different count of messages generated by the same process.
That's just an example of how a unique content ID can be generated; different programs do it differently. It's only necessary that they remain unique, a requirement that is necessary to ensure that, even if a bunch of different messages are joined together as part of a bigger multi-part message (as happens when a message is forwarded as an attachment, or assembled into a MIME-format digest), you won't have two parts with the same content ID, which would be likely to confuse mail programs greatly.
There's a similar header called Message-ID which assigns a unique identifier to the message as a whole; this is not actually part of the MIME standards, since it can be used on non-MIME as well as MIME messages. If the originating mail program doesn't add a message ID, a server handling the message later on probably will, since a number of programs (both clients and servers) want every message to have one to keep track of them. Some headers discussed in the Other Headers article make use of message IDs.
When referenced in the form of a Web URI
, content IDs and message IDs are placed within the URI schemes cid and mid respectively, without the angle brackets:
cid:5.31.32252.1057009685@server01.example.net
of the message content, consisting of a type and subtype, for example
Content-Type: text/plain
Through the use of the multipart type, MIME allows messages to have parts arranged in a tree structure
where the leaf nodes are any non-multipart content type and the non-leaf nodes are any of a variety of multipart types.
This mechanism supports:
In addition to the presentation style, the content-disposition header also provides fields for specifying the name of the file, the creation date and modification date, which can be used by the reader's mail user agent to store the attachment.
The following example is taken from RFC 2183, where the header is defined
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 February 1997 16:29:51 -0500";
The filename may be encoded as defined by RFC 2231.
As of 2010, a good majority of mail user agents do not follow this prescription fully. The widely used Mozilla Thunderbird
mail client makes its own decisions about which MIME parts should be automatically displayed, ignoring the content-disposition headers in the messages. Thunderbird prior to version 3 also sends out newly composed messages with inline content-disposition for all MIME parts. Most users are unaware of how to set the content-disposition to attachment. Many mail user agents also send messages with the file name in the name parameter of the content-type header instead of the filename parameter of the content-disposition header. This practice is discouraged.
The RFC and the IANA's list of transfer encodings define the values shown below, which are not case sensitive. Note that '7bit', '8bit', and 'binary' mean that no binary-to-text encoding on top of the original encoding was used. In these cases, the header is actually redundant for the email client to decode the message body, but it may still be useful as an indicator of what type of object is being sent. Values 'quoted-printable
' and 'base64
' tell the email client that a binary-to-text encoding scheme was used and that appropriate initial decoding is necessary before the message can be read with its original encoding (e.g. UTF-8).
There is no encoding defined which is explicitly designed for sending arbitrary binary data through SMTP transports with the 8BITMIME extension. Thus base64 or quoted-printable (with their associated inefficiency) must sometimes still be used. This restriction does not apply to other uses of MIME such as Web Services with MIME attachments or MTOM
The form is: "
For example,
is interpreted as "Subject: ¡Hola, señor!".
The encoded-word format is not used for the names of the headers (for example
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="frontier"
This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain
This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg=
--frontier--
Each part consists of its own content header (zero or more Content- header fields) and a body. Multipart content can be nested. The content-transfer-encoding of a multipart type must always be "7bit", "8bit" or "binary" to avoid the complications that would be posed by multiple levels of decoding. The multipart block as a whole does not have a charset; non-ASCII characters in the part headers are handled by the Encoded-Word system, and the part bodies can have charsets specified if appropriate for their content-type.
Notes:
The RFC initially defined 4 subtypes: mixed, digest, alternative and parallel. A minimally compliant application must support mixed and digest; other subtypes are optional. Applications must treat unrecognised subtypes as "multipart/mixed". Additional subtypes, such as signed and form-data, have since been separately defined in other RFCs.
The following is a list of the most commonly used subtypes; it is not intended to be a comprehensive list.
Defined in RFC 2046, Section 5.1.3
, since the message may be a full MIME message. This is used for digests as well as for email forwarding
.
Defined in RFC 2046.
Defined in RFC 2046, Section 5.1.5
Since a client is unlikely to want to send a version that is less faithful than the plain text version, this structure places the plain text version (if present) first. This makes life easier for users of clients that do not understand multipart messages.
Most commonly, multipart/alternative is used for email with two parts, one plain text (text/plain) and one HTML (text/html). The plain text part provides backwards compatibility while the HTML part allows use of formatting and hyperlinks. Most email clients offer a user option to prefer plain text over HTML; this is an example of how local factors may affect how an application chooses which "best" part of the message to display.
While it is intended that each part of the message represent the same content, the standard does not require this to be enforced in any way. At one time, anti-spam filters would only examine the text/plain part of a message, because it is easier to parse than the text/html part. But spammers eventually took advantage of this, creating messages with an innocuous-looking text/plain part and advertising in the text/html part. Anti-spam software eventually caught up on this trick, penalizing messages with very different text in a multipart/alternative message.
Defined in RFC 2046, Section 5.1.4
One common usage of this subtype is to send a web page complete with images in a single message. The root part would contain the HTML
document, and use image tags to reference images stored in the latter parts.
Defined in RFC 2387
Defined in RFC 3462
to a message. It has two parts, a body part and a signature part. The whole of the body part, including mime headers, is used to create the signature part. Many signature types are possible, like application/pgp-signature (RFC 3156) and application/pkcs7-signature (S/MIME
).
Defined in RFC 1847, Section 2.1
identified by their separate content types for the control part. The most common types are
"application/pgp-encrypted" (RFC 3156) and "application/pkcs7-mime" (S/MIME
).
Defined in RFC 1847, Section 2.2
4.0, it is most commonly used for submitting files via HTTP.
Defined in RFC 2388
and streaming over HTTP.
All parts of a mixed-replace message have the same semantic meaning. However, each part invalidates - "replaces" - the previous parts as soon as it is received completely. Clients should process the individual parts as soon as they arrive and should not wait for the whole message to finish.
Originally developed by Netscape
, it is still supported by Mozilla
, Firefox
, Chrome
, Safari
(but not in Safari on the iPhone
) and Opera
, but traditionally ignored by Microsoft
. It is commonly used in IP camera
s as the MIME type for MJPEG
streams.
Internet standard
In computer network engineering, an Internet Standard is a normative specification of a technology or methodology applicable to the Internet. Internet Standards are created and published by the Internet Engineering Task Force .-Overview:...
that extends the format of email to support:
- Text in character sets other than ASCIIASCIIThe American Standard Code for Information Interchange is a character-encoding scheme based on the ordering of the English alphabet. ASCII codes represent text in computers, communications equipment, and other devices that use text...
- Non-text attachments
- Message bodies with multiple parts
- Header information in non-ASCII character sets
MIME's use, however, has grown beyond describing the content of email to describe content type in general, including for the web (see Internet media type
Internet media type
An Internet media type, originally called a MIME type after MIME and sometimes a Content-type after the name of a header in several protocols whose value is such a type, is a two-part identifier for file formats on the Internet.The identifiers were originally defined in RFC 2046 for use in email...
) and as a storage for rich content in some commercial products (e.g., IBM Lotus Domino
IBM Lotus Domino
Lotus Domino is an IBM server product that provides enterprise-grade e-mail, collaboration capabilities, and a custom application platform. Domino began life as Lotus Notes Server, the server component of Lotus Development Corporation's client-server messaging technology. It can be used as an...
and IBM Lotus Quickr
IBM Lotus Quickr
IBM Lotus Quickr is social team collaboration software, used by teams of people to share content. Lotus Quickr works inside and outside firewalls.Lotus Quickr can be described as three things:...
).
Virtually all human-written Internet
Internet
The Internet is a global system of interconnected computer networks that use the standard Internet protocol suite to serve billions of users worldwide...
email and a fairly large proportion of automated email is transmitted via SMTP
Simple Mail Transfer Protocol
Simple Mail Transfer Protocol is an Internet standard for electronic mail transmission across Internet Protocol networks. SMTP was first defined by RFC 821 , and last updated by RFC 5321 which includes the extended SMTP additions, and is the protocol in widespread use today...
in MIME format. Internet email is so closely associated with the SMTP and MIME standards that it is sometimes called SMTP/MIME email.
The content types defined by MIME standards are also of importance outside of email, such as in communication protocols like HTTP
Hypertext Transfer Protocol
The Hypertext Transfer Protocol is a networking protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web....
for the World Wide Web
World Wide Web
The World Wide Web is a system of interlinked hypertext documents accessed via the Internet...
. HTTP requires that data be transmitted in the context of email-like messages, although the data most often is not actually email.
MIME is specified in six linked RFC memoranda
Request for Comments
In computer network engineering, a Request for Comments is a memorandum published by the Internet Engineering Task Force describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.Through the Internet Society, engineers and...
: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 and RFC 2049, which together define the specifications.
Introduction
The basic Internet email transmission protocol, SMTP, supports only 7-bit ASCIIASCII
The American Standard Code for Information Interchange is a character-encoding scheme based on the ordering of the English alphabet. ASCII codes represent text in computers, communications equipment, and other devices that use text...
characters (see also 8BITMIME).
This effectively limits Internet email to messages which, when transmitted, include only the characters sufficient for writing a small number of languages, primarily English
English language
English is a West Germanic language that arose in the Anglo-Saxon kingdoms of England and spread into what was to become south-east Scotland under the influence of the Anglian medieval kingdom of Northumbria...
. Other languages based on the Latin alphabet
Latin alphabet
The Latin alphabet, also called the Roman alphabet, is the most recognized alphabet used in the world today. It evolved from a western variety of the Greek alphabet called the Cumaean alphabet, which was adopted and modified by the Etruscans who ruled early Rome...
typically include diacritic
Diacritic
A diacritic is a glyph added to a letter, or basic glyph. The term derives from the Greek διακριτικός . Diacritic is both an adjective and a noun, whereas diacritical is only an adjective. Some diacritical marks, such as the acute and grave are often called accents...
s and are not supported in 7-bit ASCII, meaning text in these languages cannot be correctly represented in basic email.
MIME defines mechanisms for sending other kinds of information in email. These include text in languages other than English using character encoding
Character encoding
A character encoding system consists of a code that pairs each character from a given repertoire with something else, such as a sequence of natural numbers, octets or electrical pulses, in order to facilitate the transmission of data through telecommunication networks or storage of text in...
s other than ASCII, and 8-bit binary content such as files containing image
Image
An image is an artifact, for example a two-dimensional picture, that has a similar appearance to some subject—usually a physical object or a person.-Characteristics:...
s, sound
Sound
Sound is a mechanical wave that is an oscillation of pressure transmitted through a solid, liquid, or gas, composed of frequencies within the range of hearing and of a level sufficiently strong to be heard, or the sensation stimulated in organs of hearing by such vibrations.-Propagation of...
s, movies
Film
A film, also called a movie or motion picture, is a series of still or moving images. It is produced by recording photographic images with cameras, or by creating images using animation techniques or visual effects...
, and computer program
Computer program
A computer program is a sequence of instructions written to perform a specified task with a computer. A computer requires programs to function, typically executing the program's instructions in a central processor. The program has an executable form that the computer can use directly to execute...
s. MIME is also a fundamental component of communication protocols such as HTTP, which requires that data be transmitted in the context of email-like messages even though the data might not (and usually doesn't) actually have anything to do with email. Mapping messages into and out of MIME format is typically done automatically
by an email client or by mail servers
Mail transfer agent
Within Internet message handling services , a message transfer agent or mail transfer agent or mail relay is software that transfers electronic mail messages from one computer to another using a client–server application architecture...
when sending or receiving Internet (SMTP/MIME) email.
The basic format of Internet email is defined in RFC 5322, which is an updated version of RFC 2822 and RFC 822. These standards specify the familiar formats for text email headers
Header (information technology)
In information technology, header refers to supplemental data placed at the beginning of a block of data being stored or transmitted. In data transmission, the data following the header are sometimes called the payload or body....
and body and rules pertaining to commonly used header fields such as "To:", "Subject:", "From:", and "Date:".
MIME defines a collection of email headers for specifying additional attributes of a message including content type, and defines a set of transfer encodings which can be used to represent 8-bit binary data using characters from the 7-bit ASCII character set.
MIME also specifies rules for encoding non-ASCII characters in email message headers, such as "Subject:", allowing these header fields to contain non-English characters.
MIME is extensible. Its definition includes a method to register new content types and other MIME attribute values.
The goals of the MIME definition included requiring no changes to existent email servers and allowing plain text email to function in both directions with existing clients. These goals were achieved by using additional RFC 822-style headers for all MIME message attributes and by making the MIME headers optional with default values ensuring a non-MIME message is interpreted correctly by a MIME-capable client. A simple MIME text message is therefore likely to be interpreted correctly by a non-MIME client even if it has email headers which the non-MIME client won't know how to interpret. Similarly, if the quoted printable transfer encoding (see below) is used, the ASCII part of the message will be intelligible to users with non-MIME clients.
MIME-Version
The presence of this header indicates the message is MIME-formatted. The value is typically "1.0" so this header appears asMIME-Version: 1.0
According to MIME co-creator Nathaniel Borenstein
Nathaniel Borenstein
Nathaniel S. Borenstein is an American computer scientist.He is one of the original designers of the MIME protocol for formatting multimedia Internet electronic mail.-Biography:...
, the intention was to allow MIME to change, to advance to version 2.0 and so forth, but this decision led to the opposite outcome, making it nearly impossible to create a new version of the standard.
"We did not adequately specify how to handle a future MIME version," Borenstein said. "So if you write something that knows 1.0, what should you do if you encounter 2.0 or 1.1? I sort of thought it was obvious but it turned out everyone implemented that in different ways. And the result is that it would be just about impossible for the Internet to ever define a 2.0 or a 1.1."
Content-ID
The Content-ID header is primarily of use in multi-part messages (as discussed below); a Content-ID is a permanently globally unique identifier for a message part, allowing each part to be universally referred to by its Content-ID (e.g., in IMG tags of an HTML message allowing the inline display of attached images). The content ID is contained within angle brackets in the Content-ID header. Here is an example:Content-ID: <5.31.32252.1057009685@server01.example.net>
The standards don't really have a lot to say about exactly what is in a Content-ID; they're only supposed to be globally and permanently unique (meaning that no two are ever the same, even when generated by different people in different times and places). To achieve this, some conventions have been adopted; one of them is to include an at sign (@), with the hostname of the computer which created the content ID to the right of it. This ensures the content ID is different from any created by other computers (well, at least it is when the originating computer has a unique Internet hostname; if, as sometimes happens, an anonymous machine inserts something generic like localhost, uniqueness is no longer guaranteed). Then, the part to the left of the at sign is designed to be unique within that machine; a good way to do this is to append several constantly-changing strings that programs have access to. In this case, four different numbers were inserted, with dots between them: the rightmost one is a timestamp of the number of seconds since January 1, 1970, known as the Unix epoch; to the left of it is the process ID of the program that generated the message (on servers running Unix or Linux, each process has a number which is unique among the processes in progress at any moment, though they do repeat over time); to the left of that is a count of the number of messages generated so far by the current process; and the leftmost number is the number of parts in the current message that have been generated so far. Put together, these guarantee that the content ID will never repeat; even if multiple messages are generated within the same second, they either have different process IDs or a different count of messages generated by the same process.
That's just an example of how a unique content ID can be generated; different programs do it differently. It's only necessary that they remain unique, a requirement that is necessary to ensure that, even if a bunch of different messages are joined together as part of a bigger multi-part message (as happens when a message is forwarded as an attachment, or assembled into a MIME-format digest), you won't have two parts with the same content ID, which would be likely to confuse mail programs greatly.
There's a similar header called Message-ID which assigns a unique identifier to the message as a whole; this is not actually part of the MIME standards, since it can be used on non-MIME as well as MIME messages. If the originating mail program doesn't add a message ID, a server handling the message later on probably will, since a number of programs (both clients and servers) want every message to have one to keep track of them. Some headers discussed in the Other Headers article make use of message IDs.
When referenced in the form of a Web URI
Úri
Úriis a village and commune in the comitatus of Pest in Hungary....
, content IDs and message IDs are placed within the URI schemes cid and mid respectively, without the angle brackets:
cid:5.31.32252.1057009685@server01.example.net
Content-Type
This header indicates the Internet media typeInternet media type
An Internet media type, originally called a MIME type after MIME and sometimes a Content-type after the name of a header in several protocols whose value is such a type, is a two-part identifier for file formats on the Internet.The identifiers were originally defined in RFC 2046 for use in email...
of the message content, consisting of a type and subtype, for example
Content-Type: text/plain
Through the use of the multipart type, MIME allows messages to have parts arranged in a tree structure
Tree structure
A tree structure is a way of representing the hierarchical nature of a structure in a graphical form. It is named a "tree structure" because the classic representation resembles a tree, even though the chart is generally upside down compared to an actual tree, with the "root" at the top and the...
where the leaf nodes are any non-multipart content type and the non-leaf nodes are any of a variety of multipart types.
This mechanism supports:
- simple text messages using text/plain (the default value for "Content-Type: ")
- text plus attachments (multipart/mixed with a text/plain part and other non-text parts). A MIME message including an attached file generally indicates the file's original name with the "Content-disposition:" header, so the type of file is indicated both by the MIME content-type and the (usually OSOperating systemAn operating system is a set of programs that manage computer hardware resources and provide common services for application software. The operating system is the most important type of system software in a computer system...
-specific) filename extensionFilename extensionA filename extension is a suffix to the name of a computer file applied to indicate the encoding of its contents or usage.... - reply with original attached (multipart/mixed with a text/plain part and the original message as a message/rfc822 part)
- alternative content, such as a message sent in both plain text and another format such as HTMLHTMLHyperText Markup Language is the predominant markup language for web pages. HTML elements are the basic building-blocks of webpages....
(multipart/alternative with the same content in text/plain and text/html forms) - image, audio, video and application (for example, image/jpeg, audio/mp3, video/mp4, and application/msword and so on)
- many other message constructs
Content-Disposition
The original MIME specifications only described the structure of mail messages. They did not address the issue of presentation styles. The content-disposition header field was added in RFC 2183 to specify the presentation style. A MIME part can have:- an inline content-disposition, which means that it should be automatically displayed when the message is displayed, or
- an attachment content-disposition, in which case it is not displayed automatically and requires some form of action from the user to open it.
In addition to the presentation style, the content-disposition header also provides fields for specifying the name of the file, the creation date and modification date, which can be used by the reader's mail user agent to store the attachment.
The following example is taken from RFC 2183, where the header is defined
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 February 1997 16:29:51 -0500";
The filename may be encoded as defined by RFC 2231.
As of 2010, a good majority of mail user agents do not follow this prescription fully. The widely used Mozilla Thunderbird
Mozilla Thunderbird
Mozilla Thunderbird is a free, open source, cross-platform e-mail and news client developed by the Mozilla Foundation. The project strategy is modeled after Mozilla Firefox, a project aimed at creating a web browser...
mail client makes its own decisions about which MIME parts should be automatically displayed, ignoring the content-disposition headers in the messages. Thunderbird prior to version 3 also sends out newly composed messages with inline content-disposition for all MIME parts. Most users are unaware of how to set the content-disposition to attachment. Many mail user agents also send messages with the file name in the name parameter of the content-type header instead of the filename parameter of the content-disposition header. This practice is discouraged.
Content-Transfer-Encoding
In June 1992, MIME (RFC 1341, since made obsolete by RFC 2045) defined a set of methods for representing binary data in ASCII text format. The content-transfer-encoding: MIME header has 2-sided significance:- It indicates whether or not a binary-to-text encoding scheme has been used on top of the original encoding as specified within the Content-Type header:
- If such a binary-to-text encoding method has been used, it states which one.
- If not, it provides a descriptive label for the format of content, with respect to the presence of 8 bit or binary content.
The RFC and the IANA's list of transfer encodings define the values shown below, which are not case sensitive. Note that '7bit', '8bit', and 'binary' mean that no binary-to-text encoding on top of the original encoding was used. In these cases, the header is actually redundant for the email client to decode the message body, but it may still be useful as an indicator of what type of object is being sent. Values 'quoted-printable
Quoted-printable
Quoted-printable, or QP encoding, is an encoding using printable ASCII characters to transmit 8-bit data over a 7-bit data path or, generally, over a medium which is not 8-bit clean...
' and 'base64
Base64
Base64 is a group of similar encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation...
' tell the email client that a binary-to-text encoding scheme was used and that appropriate initial decoding is necessary before the message can be read with its original encoding (e.g. UTF-8).
- Suitable for use with normal SMTP:
- 7bit – up to 998 octetsOctet (computing)An octet is a unit of digital information in computing and telecommunications that consists of eight bits. The term is often used when the term byte might be ambiguous, as there is no standard for the size of the byte.-Overview:...
per line of the code range 1..127 with CR and LF (codes 13 and 10 respectively) only allowed to appear as part of a CRLF line ending. This is the default value. - quoted-printableQuoted-printableQuoted-printable, or QP encoding, is an encoding using printable ASCII characters to transmit 8-bit data over a 7-bit data path or, generally, over a medium which is not 8-bit clean...
– used to encode arbitrary octet sequences into a form that satisfies the rules of 7bit. Designed to be efficient and mostly human readable when used for text data consisting primarily of US-ASCII characters but also containing a small proportion of bytes with values outside that range. - base64Base64Base64 is a group of similar encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation...
– used to encode arbitrary octet sequences into a form that satisfies the rules of 7bit. Designed to be efficient for non-text 8 bit and binary data. Sometimes used for text data that frequently uses non-US-ASCII characters.
- 7bit – up to 998 octets
- Suitable for use with SMTP servers that support the 8BITMIME SMTP extension:
- 8bit – up to 998 octets per line with CR and LF (codes 13 and 10 respectively) only allowed to appear as part of a CRLF line ending.
- Suitable only for use with SMTP servers that support the BINARYMIME SMTP extension (RFC 3030):
- binary – any sequence of octets.
There is no encoding defined which is explicitly designed for sending arbitrary binary data through SMTP transports with the 8BITMIME extension. Thus base64 or quoted-printable (with their associated inefficiency) must sometimes still be used. This restriction does not apply to other uses of MIME such as Web Services with MIME attachments or MTOM
MTOM
MTOM is the W3C Message Transmission Optimization Mechanism,a method of efficiently sending binary data to and from Web services.MTOM is usually used with XOP .-Status:MTOM is a W3C Recommendation....
Encoded-Word
Since RFC 2822, conforming message header names and values should be ASCII characters; values that contain non-ASCII data should use the MIME encoded-word syntax (RFC 2047) instead of a literal string. This syntax uses a string of ASCII characters indicating both the original character encoding (the "charset") and the content-transfer-encoding used to map the bytes of the charset into ASCII characters.The form is: "
=?charset?encoding?encoded text?=".
- charset may be any character set registered with IANAInternet Assigned Numbers AuthorityThe Internet Assigned Numbers Authority is the entity that oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System , media types, and other Internet Protocol-related symbols and numbers...
. Typically it would be the same charset as the message body. - encoding can be either "
Q" denoting Q-encoding that is similar to the quoted-printableQuoted-printableQuoted-printable, or QP encoding, is an encoding using printable ASCII characters to transmit 8-bit data over a 7-bit data path or, generally, over a medium which is not 8-bit clean...
encoding, or "B" denoting base64Base64Base64 is a group of similar encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation...
encoding. - encoded text is the Q-encoded or base64-encoded text.
Difference between Q-encoding and quoted-printable
The ASCII codes for the question mark ("?") and equals sign ("=") may not be represented directly as they are used to delimit the encoded-word. The ASCII code for space may not be represented directly because it could cause older parsers to split up the encoded word undesirably. To make the encoding smaller and easier to read the underscore is used to represent the ASCII code for space creating the side effect that underscore cannot be represented directly. Use of encoded words in certain parts of headers imposes further restrictions on which characters may be represented directly.For example,
Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=is interpreted as "Subject: ¡Hola, señor!".
The encoded-word format is not used for the names of the headers (for example
Subject). These header names are always in English in the raw message. When viewing a message with a non-English email client, the header names are usually translated by the client.Multipart messages
A MIME multipart message contains a boundary in the "Content-Type: " header; this boundary, which must not occur in any of the parts, is placed between the parts, and at the beginning and end of the body of the message, as follows:MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="frontier"
This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain
This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg=
--frontier--
Each part consists of its own content header (zero or more Content- header fields) and a body. Multipart content can be nested. The content-transfer-encoding of a multipart type must always be "7bit", "8bit" or "binary" to avoid the complications that would be posed by multiple levels of decoding. The multipart block as a whole does not have a charset; non-ASCII characters in the part headers are handled by the Encoded-Word system, and the part bodies can have charsets specified if appropriate for their content-type.
Notes:
- Before the first boundary is an area that is ignored by MIME-compliant clients. This area is generally used to put a message to users of old non-MIME clients.
- It is up to the sending mail client to choose a boundary string that doesn't clash with the body text. Typically this is done by inserting a long random string.
- The last boundary must have two hyphens at the end.
Multipart subtypes
The MIME standard defines various multipart-message subtypes, which specify the nature of the message parts and their relationship to one another. The subtype is specified in the "Content-Type" header of the overall message. For example, a multipart MIME message using the digest subtype would have its Content-Type set as "multipart/digest".The RFC initially defined 4 subtypes: mixed, digest, alternative and parallel. A minimally compliant application must support mixed and digest; other subtypes are optional. Applications must treat unrecognised subtypes as "multipart/mixed". Additional subtypes, such as signed and form-data, have since been separately defined in other RFCs.
The following is a list of the most commonly used subtypes; it is not intended to be a comprehensive list.
Mixed
Multipart/mixed is used for sending files with different "Content-Type" headers inline (or as attachments). If sending pictures or other easily readable files, most mail clients will display them inline (unless otherwise specified with the "Content-disposition" header). Otherwise it will offer them as attachments. The default content-type for each part is "text/plain".Defined in RFC 2046, Section 5.1.3
Message
A message/rfc822 part contains an email message, including any headers. Rfc822 is a misnomerMisnomer
A misnomer is a term which suggests an interpretation that is known to be untrue. Such incorrect terms sometimes derive their names because of the form, action, or origin of the subject becoming named popularly or widely referenced—long before their true natures were known.- Sources of misnomers...
, since the message may be a full MIME message. This is used for digests as well as for email forwarding
Email forwarding
Email forwarding generically refers to the operation of re-sending an email message delivered to one email address on to a possibly different email address...
.
Defined in RFC 2046.
Digest
Multipart/digest is a simple way to send multiple text messages. The default content-type for each part is "message/rfc822".Defined in RFC 2046, Section 5.1.5
Alternative
The multipart/alternative subtype indicates that each part is an "alternative" version of the same (or similar) content, each in a different format denoted by its "Content-Type" header. The formats are ordered by how faithful they are to the original, with the least faithful first and the most faithful last. Systems can then choose the "best" representation they are capable of processing; in general, this will be the last part that the system can understand, although other factors may affect this.Since a client is unlikely to want to send a version that is less faithful than the plain text version, this structure places the plain text version (if present) first. This makes life easier for users of clients that do not understand multipart messages.
Most commonly, multipart/alternative is used for email with two parts, one plain text (text/plain) and one HTML (text/html). The plain text part provides backwards compatibility while the HTML part allows use of formatting and hyperlinks. Most email clients offer a user option to prefer plain text over HTML; this is an example of how local factors may affect how an application chooses which "best" part of the message to display.
While it is intended that each part of the message represent the same content, the standard does not require this to be enforced in any way. At one time, anti-spam filters would only examine the text/plain part of a message, because it is easier to parse than the text/html part. But spammers eventually took advantage of this, creating messages with an innocuous-looking text/plain part and advertising in the text/html part. Anti-spam software eventually caught up on this trick, penalizing messages with very different text in a multipart/alternative message.
Defined in RFC 2046, Section 5.1.4
Related
A multipart/related is used to indicate that each message part is a component of an aggregate whole. It is for compound objects consisting of several inter-related components - proper display cannot be achieved by individually displaying the constituent parts. The message consists of a root part (by default, the first) which reference other parts inline, which may in turn reference other parts. Message parts are commonly referenced by the "Content-ID" part header. The syntax of a reference is unspecified and is instead dictated by the encoding or protocol used in the part.One common usage of this subtype is to send a web page complete with images in a single message. The root part would contain the HTML
HTML
HyperText Markup Language is the predominant markup language for web pages. HTML elements are the basic building-blocks of webpages....
document, and use image tags to reference images stored in the latter parts.
Defined in RFC 2387
Report
Multipart/report is a message type that contains data formatted for a mail server to read. It is split between a text/plain (or some other content/type easily readable) and a message/delivery-status, which contains the data formatted for the mail server to read.Defined in RFC 3462
Signed
A multipart/signed message is used to attach a digital signatureDigital signature
A digital signature or digital signature scheme is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, and that it was not altered in transit...
to a message. It has two parts, a body part and a signature part. The whole of the body part, including mime headers, is used to create the signature part. Many signature types are possible, like application/pgp-signature (RFC 3156) and application/pkcs7-signature (S/MIME
S/MIME
S/MIME is a standard for public key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFCs. S/MIME was originally developed by RSA Data Security Inc...
).
Defined in RFC 1847, Section 2.1
Encrypted
A multipart/encrypted message has two parts. The first part has control information that is needed to decrypt the application/octet-stream second part. Similar to signed messages, there are different implementations which areidentified by their separate content types for the control part. The most common types are
"application/pgp-encrypted" (RFC 3156) and "application/pkcs7-mime" (S/MIME
S/MIME
S/MIME is a standard for public key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFCs. S/MIME was originally developed by RSA Data Security Inc...
).
Defined in RFC 1847, Section 2.2
Form Data
As its name implies, multipart/form-data is used to express values submitted through a form. Originally defined as part of HTMLHTML
HyperText Markup Language is the predominant markup language for web pages. HTML elements are the basic building-blocks of webpages....
4.0, it is most commonly used for submitting files via HTTP.
Defined in RFC 2388
Mixed-Replace (experimental)
The content type multipart/x-mixed-replace was developed as part of a technology to emulate server pushPush technology
Push technology, or server push, describes a style of Internet-based communication where the request for a given transaction is initiated by the publisher or central server...
and streaming over HTTP.
All parts of a mixed-replace message have the same semantic meaning. However, each part invalidates - "replaces" - the previous parts as soon as it is received completely. Clients should process the individual parts as soon as they arrive and should not wait for the whole message to finish.
Originally developed by Netscape
Netscape
Netscape Communications is a US computer services company, best known for Netscape Navigator, its web browser. When it was an independent company, its headquarters were in Mountain View, California...
, it is still supported by Mozilla
Mozilla
Mozilla is a term used in a number of ways in relation to the Mozilla.org project and the Mozilla Foundation, their defunct commercial predecessor Netscape Communications Corporation, and their related application software....
, Firefox
Mozilla Firefox
Mozilla Firefox is a free and open source web browser descended from the Mozilla Application Suite and managed by Mozilla Corporation. , Firefox is the second most widely used browser, with approximately 25% of worldwide usage share of web browsers...
, Chrome
Google Chrome
Google Chrome is a web browser developed by Google that uses the WebKit layout engine. It was first released as a beta version for Microsoft Windows on September 2, 2008, and the public stable release was on December 11, 2008. The name is derived from the graphical user interface frame, or...
, Safari
Safari (web browser)
Safari is a web browser developed by Apple Inc. and included with the Mac OS X and iOS operating systems. First released as a public beta on January 7, 2003 on the company's Mac OS X operating system, it became Apple's default browser beginning with Mac OS X v10.3 "Panther". Safari is also the...
(but not in Safari on the iPhone
IPhone
The iPhone is a line of Internet and multimedia-enabled smartphones marketed by Apple Inc. The first iPhone was unveiled by Steve Jobs, then CEO of Apple, on January 9, 2007, and released on June 29, 2007...
) and Opera
Opera (web browser)
Opera is a web browser and Internet suite developed by Opera Software with over 200 million users worldwide. The browser handles common Internet-related tasks such as displaying web sites, sending and receiving e-mail messages, managing contacts, chatting on IRC, downloading files via BitTorrent,...
, but traditionally ignored by Microsoft
Microsoft
Microsoft Corporation is an American public multinational corporation headquartered in Redmond, Washington, USA that develops, manufactures, licenses, and supports a wide range of products and services predominantly related to computing through its various product divisions...
. It is commonly used in IP camera
IP camera
An Internet protocol camera, or IP camera, is a type of digital video camera commonly employed for surveillance, and which unlike analog closed circuit television cameras can send and receive data via a computer network and the Internet...
s as the MIME type for MJPEG
MJPEG
In multimedia, Motion JPEG is an informal name for a class of video formats where each video frame or interlaced field of a digital video sequence is separately compressed as a JPEG image...
streams.
Byteranges
The multipart/byteranges is used to represent noncontiguous byte ranges of a single message. It is used by HTTP when a server returns multiple byte ranges and is defined in RFC 2616.See also
- 8BITMIME
- Binary-to-text encoding
- Direct Internet Message EncapsulationDirect Internet Message EncapsulationDirect Internet Message Encapsulation was a Microsoft-proposed internet standard in the early 2000s for the streaming of binary and other encapsulated data over the Internet....
(DIME)– a now superseded MicrosoftMicrosoftMicrosoft Corporation is an American public multinational corporation headquartered in Redmond, Washington, USA that develops, manufactures, licenses, and supports a wide range of products and services predominantly related to computing through its various product divisions...
-proposed protocol intended as a streamlined MIME, primarily for use in web serviceWeb serviceA Web service is a method of communication between two electronic devices over the web.The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network". It has an interface described in a machine-processable format...
s. - Extended SMTPExtended SMTPExtended SMTP , sometimes referred to as Enhanced SMTP, is a definition of protocol extensions to the Simple Mail Transfer Protocol standard...
(ESMTP) - Internet media typeInternet media typeAn Internet media type, originally called a MIME type after MIME and sometimes a Content-type after the name of a header in several protocols whose value is such a type, is a two-part identifier for file formats on the Internet.The identifiers were originally defined in RFC 2046 for use in email...
- MailcapMailcapA mailcap file can be used to find the correct program to open a file with, based on MIME information. While the name is "mailcap" and is related to MIME it actually has use outside the domain of electronic mail ....
mime.types- Object Linking and EmbeddingObject Linking and EmbeddingObject Linking and Embedding is a technology developed by Microsoft that allows embedding and linking to documents and other objects. For developers, it brought OLE Control eXtension , a way to develop and use custom user interface elements...
(OLE) - S/MIMES/MIMES/MIME is a standard for public key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFCs. S/MIME was originally developed by RSA Data Security Inc...
- SOAP with AttachmentsSOAP with AttachmentsSOAP with Attachments or MIME for Web Services refers to the method of using Web Services to send and receive files using a combination of SOAP and MIME, primarily over HTTP....
- UnicodeUnicodeUnicode is a computing industry standard for the consistent encoding, representation and handling of text expressed in most of the world's writing systems...
and emailEmailElectronic mail, commonly known as email or e-mail, is a method of exchanging digital messages from an author to one or more recipients. Modern email operates across the Internet or other computer networks. Some early email systems required that the author and the recipient both be online at the... - Uuencoding
External links
- A more detailed overview of MIME (1993)
- MIME Media Types - comprising a list of directories of content types and subtypes, maintained by Internet Assigned Numbers AuthorityInternet Assigned Numbers AuthorityThe Internet Assigned Numbers Authority is the entity that oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System , media types, and other Internet Protocol-related symbols and numbers...
. - List of Character Sets
- Properly Configuring Server MIME Types
- W3 School's Multimedia MIME Reference
- An easy to follow description of multipart messages from MH & nmh
- The MIME guys: How two Internet gurus changed email forever
- Free Online PHP MIME checker