Multipurpose Internet Mail Extensions (MIME) is an Internet Standard for the format of e-mail. Virtually all Internet e-mail is transmitted via SMTP in MIME format. Internet e-mail is so closely associated with the SMTP and MIME standards that it is sometimes called SMTP/MIME e-mail.

Introduction

The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters. This effectively limits Internet e-mail to messages which, when transmitted, include only the characters used for the English language. MIME defines mechanisms for sending other kinds of information in e-mail, including text in languages other than English using character encodings other than ASCII as well as 8-bit binary content such as files containing images, sounds, movies, and computer programs. MIME is also a fundamental component of communication protocols such as HTTP, which requires that data be transmitted in the context of e-mail-like messages, even though the data may not actually be e-mail.

Mapping messages into and out of MIME format is typically done automatically by an email client or by proprietary mail servers when sending or receiving Internet (SMTP/MIME) e-mail.

The basic format of Internet e-mail is defined in RFC 2822, which is an updated version of RFC 822. These standards specify the familiar formats for text e-mail headers and body and rules pertaining to commonly used header fields such as "To:", "Subject:", "From:", and "Date:". MIME defines a collection of e-mail 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 e-mail 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.

One of the explicit goals of the MIME definition was to not require changes to pre-existing e-mail servers or clients. This goal is achieved by allowing all MIME message attributes to be optional, with default values making a non-MIME message likely to be interpreted correctly by a MIME-capable client. In addition, a simple MIME text message is likely to be interpreted correctly by a non-MIME client although it has e-mail headers the non-MIME client won't know how to interpret.

MIME headers

MIME-Version

The presence of this header indicates the message is MIME-formatted. The value is typically "1.0" so this header appears as

  MIME-Version: 1.0

Content-type

This header indicates the type and subtype of the message content, for example

  Content-type: text/plain

The combination of type and subtype is generally called a MIME type. A large number of file formats have registered MIME types. Any text type has an additional charset parameter that can be included to indicate the character encoding. A very large number of character encodings have registered MIME charset names.

Although originally defined for MIME e-mail, the content-type header and MIME type registry is reused in other Internet protocols such as HTTP.

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:

• 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 OS-specific) filename extension.
• 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 HTML (multipart/alternative with the same content in text/plain and text/html forms)
• many other message constructs

Content-Transfer-Encoding

MIME (RFC 2045) defines a set of methods for representing binary data in ASCII text format. The content-transfer-encoding: MIME header indicates the method that has been used. Typically encountered values for this header include:

• 7bit - up to 998 octets per line of the code range [1..127]\{CR, NL}. This is the default value.
• 8bit - up to 998 octets per line of the code range [1..255]\{CR, NL}. This can be used only if both the sending and receiving mail transfer agents support the 8bit MIME transport SMTP extension.
• binary - any sequence of octets
• quoted-printable - used for text data consisting primarily of US-ASCII characters
• base64 - used for arbitrary binary data

Encoded-Word

Through the use of MIME (RFC 2047) encoded-words non-ASCII text can be included in e-mail header fields, such as "Subject:". The character set for the content of these fields defaults to ASCII, so any non-ASCII text must be encoded. An encoded-word is a string of ASCII characters indicating both the original character set and the content-transfer-encoding used to map the original characters into ASCII characters.

Multipart Example

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:

Content-type: multipart/mixed; boundary="frontier"
MIME-version: 1.0

--frontier
Content-type: text/plain

This is the body of the message.
--frontier
Content-type: application/octet-stream
Content-transfer-encoding: base64

gajwO4+n2Fy4FV3V7zD9awd7uG8/TITP/vIocxXnnf/5mjgQjcipBUL1b3uyLwAVtBLOP4nV
LdIAhSzlZnyLAF8na0n7g6OSeej7aqIl3NIXCfxDsPsY6NQjSvV77j4hWEjlF/aglS6ghfju
FgRr+OX8QZMI1OmR4rUJUS7xgoknalqj3HJvaOpeb3CFlNI9VGZYz6H6zuQBOWZzNB8glwpC
--frontier--

See also

• DIME — Microsoft proposed a technology called DIME which would have streamlined MIME for use in web services. A specification for the standard was submitted to the Internet Engineering Task Force (IETF) but, according to the IETF web site, the standard has been withdrawn and never made RFC status.

• S/MIME
• Mailcap

References

• RFC 2045 - Full text of RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed, N. Borenstein. November 1996. (Format: TXT=72932 bytes) (Obsoletes RFC 1521, RFC 1522, RFC 1590) (Updated by RFC 2184, RFC 2231) (Status: DRAFT STANDARD)
• RFC 2046 - Full text of RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed, N. Borenstein. November 1996. (Format: TXT=105854 bytes) (Obsoletes RFC 1521, RFC 1522, RFC 1590) (Updated by RFC 2646) (Status: DRAFT STANDARD)
• RFC 2047 - Full text of RFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. K. Moore. November 1996. (Format: TXT=33262 bytes) (Obsoletes RFC 1521, RFC 1522, RFC 1590) (Updated by RFC 2184, RFC 2231) (Status: DRAFT STANDARD)
• RFC 2048 - Full text of RFC 2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin, Jon Postel. November 1996. (Format: TXT=45033 bytes) (Obsoletes RFC 1521, RFC 1522, RFC 1590) (Updated by RFC 3023) (Also BCP0013) (Status: BEST CURRENT PRACTICE)
• RFC 2049 - Full text of RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996. (Format: TXT=51207 bytes) (Obsoletes RFC 1521, RFC 1522, RFC 1590) (Status: DRAFT STANDARD)

External links

• Blog tracking Internet mail related drafts and standards
• List of IANA registered MIME Media Types
• List of Character Sets
• http://wiki.debian.net/index.cgi?MIME