|
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 (http://www.faqs.org/rfcs/rfc2822.html), 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
References - RFC 2045 - Full text of RFC 2045 (http://www.ietf.org/rfc/rfc2045.txt) 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 (http://www.ietf.org/rfc/rfc2046.txt) 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 (http://www.ietf.org/rfc/rfc2047.txt) 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 (http://www.ietf.org/rfc/rfc2048.txt) 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 (http://www.ietf.org/rfc/rfc2049.txt) 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 |
Feeds |
Contact