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.
Although the MIME formalism was designed mainly for SMTP, its content types are also important in other communication protocols.
However, Borenstein admitted short-comings in the specification that hindered the implementation of this feature: "We did not adequately specify how to handle a future MIME version.
This mechanism supports (non-exhaustively): The original MIME specifications only described the structure of mail messages.
A MIME part can have: 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 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.
The content-transfer-encoding: MIME header field has 2-sided significance: The RFC and the IANA's list of transfer encodings define the values shown below, which are not case sensitive.
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.
There is no encoding defined which is explicitly designed for sending arbitrary binary data through SMTP transports with the 8BITMIME extension.
The ASCII code for space may not be represented directly because it could cause older parsers to split up the encoded word undesirably.
The use of encoded words in certain parts of header fields imposes further restrictions on which characters may be represented directly.
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.
Notes: The MIME standard defines various multipart-message subtypes, which specify the nature of the message parts and their relationship to one another.
[6] 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.
This makes life easier for users of clients that do not understand multipart messages.
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.
One common usage of this subtype is to send a web page complete with images in a single message.
Similar to signed messages, there are different implementations which are identified by their separate content types for the control part.
Originally defined as part of HTML 4.0, it is most commonly used for submitting files with HTTP.
Clients should process the individual parts as soon as they arrive and should not wait for the whole message to finish.