MIME: Multipurpose Internet Mail Extensions

Multipurpose Internet Mail Extensions (MIME) is a standard which was proposed by Bell Communications in 1991 in order to expand limited capabilities of email.

images/webmaster/mime-multipurpose-internet-mail-extensions.jpg

It extends the format of email to support:

  • Text in character sets other than ASCII
  • Non-text attachments: audio, video, images, application programs
  • Message bodies with multiple parts
  • Header information in non-ASCII character sets

SMTP has a very simple structure and it can only send messages in 7-bit ASCII format. It cannot be used for languages that do not support 7-bit ASCII format. So, in order to extend email capability, MIME is used. MIME transforms non-ASCII data at sender side to 7-bit data and delivers it to the client SMTP. At the receiver side, the message is transferred back to the original data.

MIME Header

MIME Header is added to the original e-mail header section to define the transformation.

  1. MIME Version: Defines version of MIME protocol. It must have the parameter Value 1.0, which indicates that message is formatted using MIME.

  2. Content Type: Type of data used in the body of message. They are of different types like text data (plain, HTML), audio content or video content. It consists of a type and subtype.

  3. Content Type Encoding: It defines the method used for encoding the message.

Content-Type

This header is used to describe the content type of the message. The Content-Type header includes the type and subtype parts.

For example, Content-Type: text/plain

Simple text messages use text/plain. This is the default value.

  • Text plus attachments use 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.

  • Reply with original attached use 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 use multipart/alternative with the same content in text/plain and text/html forms).

  • Image, audio, video, and application use image/jpeg, audio/mp3, video/mp4, application/msword and so on.

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.

  1. An inline content-disposition, which means that it should be automatically displayed when the message is displayed

  2. An attachment content-disposition, in which case it is not displayed automatically and requires some form of action from the user to open it.

The content-disposition header also provides fields 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.

Content-Transfer-Encoding

Values '7bit', '8bit', and 'binary' mean that no binary-to-text encoding on top of the original encoding was used.

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).

Multipart Messages

The 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.

Each part consists of its own content header and a body.

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 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".

The multipart/digest is a simple way to send multiple text messages. The default content-type for each part is "message/rfc822".

The multipart/alternative subtype indicates that each part is an alternative version of the similar content, each in a different format denoted by its "Content-Type" header. The order of the parts is significant. In general, user agents that compose multipart/alternative entities should place the body parts in increasing order of preference, that is, with the preferred format last. 

Most commonly, multipart/alternative is used for email with two parts, one plain text (text/plain) and one HTML (text/html). The plain text part provides backwards compatibility while the HTML part allows use of formatting and hyperlinks.