|
Multipurpose Internet Mail Extensions (MIME) is an Internet Standard that extends the format of e-mail to support text in character sets other than US-ASCII, non-text attachments, multi-part message bodies, and header information in non-ASCII character sets. Virtually all human-written Internet e-mail and a fairly large proportion of automated 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. Internet standards are defined by the Internet Engineering Task Force (IETF). ...
Wikipedia does not yet have an article with this exact name. ...
A character encoding is a code that pairs a set of characters (such as an alphabet or syllabary) with a set of something else, such as numbers or electrical pulses. ...
There are 95 printable ASCII characters, numbered 32 to 126. ...
Simple Mail Transfer Protocol (SMTP) is the de facto standard for e-mail transmissions across the Internet. ...
The content types defined by MIME standards are also of importance outside of e-mail, such as in communication protocols like HTTP for the World Wide Web. HTTP requires that data be transmitted in the context of e-mail-like messages, even though the data may not actually be e-mail. To meet Wikipedias quality standards, this article or section may require cleanup. ...
HTTP (for HyperText Transfer Protocol) is the primary method used to convey information on the World Wide Web. ...
WWWs historical logo designed by Robert Cailliau The World Wide Web (WWW or simply the Web) is a system of interlinked, hypertext documents that runs over the Internet. ...
MIME is specified in five RFCs : RFC 2045, RFC 2046, RFC 2047, RFC 2048 and RFC 2077. In internetworking and computer network engineering, Request for Comments (RFC) documents are a series of memoranda encompassing new research, innovations, and methodologies applicable to Internet technologies. ...
Introduction
The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters (see also 8BITMIME). This effectively limits Internet e-mail 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 diacritics not supported in 7-bit ASCII, meaning text in these languages cannot be correctly represented in basic e-mail. There are 95 printable ASCII characters, numbered 32 to 126. ...
8BITMIME (RFC 1652) is an SMTP extension standardized in 1994 that facilitates the exchange of e-mail messages containing octets outside the seven-bit ASCII range. ...
The English language is a West Germanic language that originates in England. ...
The Latin alphabet, also called the Roman alphabet, is the most widely used alphabetic writing system in the world today. ...
A diacritical mark or diacritic, sometimes called an accent mark, is a mark added to a letter to alter a words pronunciation (i. ...
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 e-mail client or by mail servers when sending or receiving Internet (SMTP/MIME) e-mail. A character encoding consists of a code that pairs a sequence of characters from a given set with something else, such as a sequence of natural numbers, octets or electrical pulses, in order to facilitate the storage of text in computers and the transmission of text through telecommunication networks. ...
In common usage, an image (from Latin imago) or picture is an artifact that reproduces the likeness of some subject—usually a physical object or a person. ...
Sound is a disturbance of mechanical energy that propagates through matter as a wave. ...
Film is a term that encompasses motion pictures as individual projects, as well as the field in general. ...
A computer program is a collection of instructions that describe a task, or set of tasks, to be carried out by a computer. ...
HTTP (for HyperText Transfer Protocol) is the primary method used to convey information on the World Wide Web. ...
An email client An e-mail client, also called a Mail User Agent (MUA), is a computer program that is used to read and send e-mail. ...
A mail transfer agent or MTA (also called a mail transport agent, mail server, or a mail exchange server in the context of the Domain Name System) is a computer program or software agent that transfer electronic mail messages from one computer to another. ...
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. In information technology, Header refers to supplemental data placed at the beginning of a block of data being stored or transmitted, which contain information for the handling of the data block. ...
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, and to allow plain text e-mail to function in both directions with pre-existing 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. 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 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 Internet media type 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: A tree structure is a way of representing the hierarchical nature of a structure in a graphical form. ...
- 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
An operating system (OS) is a computer program that manages the hardware and software resources of a computer. ...
A filename extension is an extra set of (usually) alphanumeric characters that is appended to the end of a filename to allow computer users (as well as various pieces of software on the computer system) to quickly determine the type of data stored in the file. ...
In computing, HyperText Markup Language (HTML) is the predominant markup language for the creation of web pages. ...
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. The RFC and the IANA's list of transfer encodings define the following values, which are not case sensitive: - 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 byte values outside that range.
- base64 - used to encode arbitrary octet sequences into a form that satisfies the rules of 7bit. Has a fixed overhead and is intended for non text data and text that is not ASCII heavy.
- Suitable for use with SMTP servers that support the 8BITMIME transport 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.
- Not suitable for use with SMTP:
- binary - any sequence of octets. Not usable with SMTP mail.
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. Quoted-printable is an encoding using ASCII characters for non-ASCII text. ...
Base 64 is a positional numeral system using a base of 64. ...
8BITMIME (RFC 1652) is an SMTP extension standardized in 1994 that facilitates the exchange of e-mail messages containing octets outside the seven-bit ASCII range. ...
Extended SMTP (ESMTP) is a definition of protocol extensions to the Simple Mail Transfer Protocol standard. ...
MTOM MTOM is the W3C Message Transmission Optimization Mechanism, A method of efficiently sending binary data to and from web services See WC3 Reference Category: ...
Encoded-Word Since RFC 2822, message header names and values are always ASCII characters; values that contain non-ASCII data must 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.
Difference between Q-encoding and quoted-printable For other uses of IANA, see IANA (disambiguation). ...
Quoted-printable is an encoding using ASCII characters for non-ASCII text. ...
Base 64 is a positional numeral system using a base of 64. ...
The ascii codes for the question mark (?) and equals sign may not be represented directly as they are used to delminate 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 bringing the side affect 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: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=
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 e-mail 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: Delimiters are marks which are used to seperate subfields of data. ...
-
Content-type: multipart/mixed; boundary="frontier" MIME-version: 1.0 This is a multi-part message 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 large random string.
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, alternate, digest and parallel. A minimally compliant application must support mixed and digest; other subtypes are optional. 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 RFC2231, 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".
Defined in RFC2231, 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 and one 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, it is not 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. View of a modern spam email, containing an advertising image. ...
This article is about spam, the abuse of electronic communications media to send unsolicited bulk messages. ...
Defined in RFC2231, Section 5.1.4
Related A multipart/related is used to indicate that message parts should not be considered individually but rather as parts of an aggregate whole. 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 referring 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 document, and use image tags to reference images stored in the latter parts. In computing, HyperText Markup Language (HTML) is the predominant markup language for the creation of web pages. ...
Defined in RFC2387
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 RFC3462
Signed A multipart/signed message is used to attach a digital signature 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 and application/x-pkcs7-signature. Digital signature is a term with confusing reference. ...
Defined in RFC1847, 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.
Defined in RFC1847, 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 HTML 4.0, it is most commonly used for submitting files via HTTP. In computing, HyperText Markup Language (HTML) is the predominant markup language for the creation of web pages. ...
HTTP (for HyperText Transfer Protocol) is the primary method used to convey information on the World Wide Web. ...
Defined in RFC2388
See also SOAP with Attachments (SwA) 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. Note that SwA is not a new specification, but rather a mechanism for using the existing SOAP and...
DIME is a Microsoft-proposed internet standard for the transfer of binary and other encapsulated data over SOAP. According to the IETF web site, the standard has been withdrawn and never made RFC status. ...
Microsoft Corporation, (NASDAQ: MSFT, HKSE: 4338) is a multinational computer technology corporation with global annual revenue of US$44. ...
By the mid 20th century humans had achieved a level of technological mastery sufficient to leave the surface of the planet for the first time and explore space. ...
The W3C defines a Web service[1] as a software system designed to support interoperable machine-to-machine interaction over a network. ...
S/MIME (Secure / Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of e-mail encapsulated in MIME. // S/MIME was originally developed by RSA Data Security Inc. ...
Many e-mail clients are now able to use Unicode. ...
References - RFC 1847
- Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
- RFC 2045
- MIME Part One: Format of Internet Message Bodies.
- RFC 2046
- MIME Part Two: Media Types. N. Freed, Nathaniel Borenstein. November 1996.
- RFC 2047
- MIME Part Three: Message Header Extensions for Non-ASCII Text. Keith Moore. November 1996.
- RFC 4288
- MIME Part Four: Media Type Specifications and Registration Procedures.
- RFC 4289
- MIME Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005.
- RFC 2049
- MIME Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996.
- RFC 2231
- MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.
- RFC 2387
- The MIME Multipart/Related Content-type
Nathaniel Borenstein is one of the original designers of the MIME protocol for sending multimedia Internet electronic mail. ...
Keith Moore (born 12 October 1960) is the author and co-author of several IETF RFCs related to the MIME and SMTP protocols for electronic mail, among others: RFC 1870, defining a mechanism to allow SMTP clients and servers to avoid transferring messages so large that they will be rejected...
External links | 
Feeds |
Contact