Multipurpose Internet Mail Extensions (MIME) is a standard that extends the format of email messages to support text in character sets other than ASCII, as well as attachments of audio, video, images, and application programs. Message bodies may consist of multiple parts, and header information may be specified in non-ASCII character sets. Email messages with MIME formatting are typically transmitted with standard protocols, such as the Simple Mail Transfer Protocol (SMTP), the Post Office Protocol (POP), and the Internet Message Access Protocol (IMAP).
MIME is an Internet standard specified in the following request for comments (RFC) publications: , , , , and . The integration with SMTP email is specified in and .
Although the MIME formalism was designed mainly for SMTP, its content types are also important in other communication protocols. In the Hypertext Transfer Protocol (HTTP) for the World Wide Web, servers insert a MIME header field at the beginning of any Web transmission. Clients use the content type header to select an appropriate viewer application for the type of data indicated.
History
MIME originated from the Andrew Messaging System, which was part of Andrew Project developed at Carnegie Mellon University (CMU), as a cross-platform alternative to the Andrew-specific data format.
MIME header fields MIME-Version The presence of this header field indicates the message is MIME-formatted. The value is typically "1.0". The field appears as follows: MIME-Version: 1.0
According to MIME co-creator Nathaniel Borenstein, the version number was introduced to permit changes to the MIME protocol in subsequent versions. However, Borenstein admitted short-comings in the specification that hindered the implementation of this feature:
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 field Content-Disposition also provides parameters 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 field is defined: Content-Disposition: attachment; filename=genome.jpeg; modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
The filename may be encoded as defined in RFC 2231.
As of 2010, a majority of mail user agents did not follow this prescription fully. The widely used Mozilla Thunderbird mail client ignores the content-disposition fields in the messages and uses independent algorithms for selecting the MIME parts to display automatically. 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 header field Content-Disposition. This practice is discouraged, as the file name should be specified either with the parameter filename, or with both the parameters filename and name.
In HTTP, the response header field Content-Disposition: attachment is usually used as a hint to the client to present the response body as a downloadable file. Typically, when receiving such a response, a Web browser prompts the user to save its content as a file, instead of displaying it as a page in a browser window, with filename suggesting the default file name.
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 formats other than ASCII text format. The content-transfer-encoding: MIME header field 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. '7bit', '8bit', and 'binary' mean that no binary-to-text encoding on top of the original encoding was used. In these cases, the header field 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). Suitable for use with normal SMTP: 7bit – up to 998 octets 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-printable – 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. base64 – 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. Suitable for use with SMTP servers that support the 8BITMIME SMTP extension (RFC 6152): 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 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, if BINARYMIME isn't supported, base64 or quoted-printable (with their associated inefficiency) are sometimes still useful. This restriction does not apply to other uses of MIME such as Web Services with MIME attachments or MTOM.
Encoded-Word Since RFC 2822, conforming message header field names and values use 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 IANA. 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-printable encoding, or "B" denoting base64 encoding. encoded text is the Q-encoded or base64-encoded text. An encoded-word may not be more than 75 characters long, including charset, encoding, encoded text, and delimiters. If it is desirable to encode more text than will fit in an encoded-word of 75 characters, multiple encoded-words (separated by CRLF SPACE) may be used.
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. The use of encoded words in certain parts of header fields 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 fields (for example Subject). These names are usually English terms and always in ASCII in the raw message. When viewing a message with a non-English email client, the header field names might be translated by the client.
Multipart messages The MIME multipart message contains a boundary in the header field ; 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 header fields) and a body. Multipart content can be nested. The 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 header field of the overall message. For example, a multipart MIME message using the digest subtype would have its set as "multipart/digest".
The RFC initially defined four subtypes: mixed, digest, alternative and parallel. A minimally compliant application must support mixed and digest; other subtypes are optional. Applications must treat unrecognized subtypes as "multipart/mixed". Additional subtypes, such as signed and form-data, have since been separately defined in other RFCs.
mixed multipart/mixed is used for sending files with different header fields inline (or as attachments). If sending pictures or other easily readable files, most mail clients will display them inline (unless explicitly specified with Content-Disposition: attachment in which case offered as attachments). The default content-type for each part is "text/plain".
The type is defined in RFC 2046.RFC 2046, Section 5.1.3
digest multipart/digest is a simple way to send multiple text messages. The default content-type for each part is "message/rfc822".
The MIME type is defined in RFC 2046.RFC 2046, Section 5.1.5
alternative