Most email attachments are not text (ASCII) files. They may be graphical, audio, video, or word-processed files. A binary attachment must be converted by mimencode to a type of ASCII file. Otherwise it will not be supported by Internet email. The following steps are involved in the exchange of email attachments using MIME:
- The sender specifies the name of the file to be attached to the mail message and may choose to identify the file type (graphics, video, sounds, etc.). As a rule, the receiving mail program will automatically identify the file type if it is not specified. The file name extension indicates the format, such as .jpg, .doc, or .wav.
- If the attachment is binary or contains something other than ASCII characters, the sending program automatically converts it to ASCII. This process increases the size of the attachment, which is then sent along with the mail message to the recipient.
- If the recipient’s mail program supports MIME, it converts the attachment back to its original binary format and pastes an icon or a line of text in the received mail message to represent the attached file. If the recipient selects that icon while in the mail program, the application program will run and will automatically display the attached file.
MIME, an Internet format defined by the Internet Engineering Task Force (IETF), prescribes a simple standardized way to represent and encode a variety of media types for transmission via Internet mail, including textual data in non-ASCII character sets. MIME extends RFC 822 in a manner that is simple, backward-compatible, and flexible.
RFC 822, the Internet standard for message formats, is used widely beyond the boundaries of the Internet itself. Most email traffic is limited to ASCII text, which is unable to define characters found in non-English text, audio, or graphical information. To use multimedia mail on the Internet, extensions to RFC 822 are required. The RFC 822 message format and the RFC 821 Simple Mail Transfer Protocol (SMTP) transport method limit message content to seven-bit ASCII characters. RFC 822 defines a message as a structured header followed by a single, monolithic text body. This format creates problems for multipart mixed media mail. SMTP limits the length of lines within message headers and bodies. RFC 1049 defines a mechanism for single-part nontext mail, and RFC 1154 provides a mechanism for multipart mail.
An RFC 822-compliant Internet message consists of two parts: the header and the body. The header consists of a series of field names and field bodies. A blank line marks the end of the header and the beginning of the body, which may consist exclusively of US-ASCII text.
RFC 1049 introduced a new header field, content- type, which marked the entire message body as containing a certain type of data. If a content-type field is not present, the body is assumed to be US-ASCII text. A problem with RFC 1049 is the lack of support for multipart mail. A message body can contain only one item other than text.
MIME defines a new content-type, multipart. It may be used to encapsulate multiple body parts within a single RFC 822 message body. MIME describes the set of allowable content types, defines a subtype mechanism for content- types, and provides for standardized encoding of non-ASCII data.
The MIME format defines seven valid content types. In this way it differs from RFC 1049, which allowed users to define new content types freely. The seven defined content-type values are as follows:
- Text: The default subtype is plain text, with other subtypes associated with particular rich text formats. MIME defines the subtype richtext for formatted email.
- Image: Subtypes are image format names, image/gif and image/jpeg. A mail reader that does not identify an image format will at least recognize that the content is an image.
- Audio: Subtypes are audio format names; audio/basic is the default. Audio/basic denotes single-channel 8-kHz a-law audio data, which is the equivalent of pulse code modulation (PCM), for telephone-quality audio attached to email.
- Video: Subtypes are video format names; video/mpeg is the default.
- Message: This content-type is used to encapsulate an entire RFC 822 format message. There are two message subtypes: message/partial for dividing a message into several pieces for transport and message/ external-body for passing a large message body by reference, rather than including its entire contents within the message.
- Multipart: This content-type is used to pack several parts of various types and subtypes into a single RFC 822 message body.
- Application: This content-type is used for most other kinds of data that do not fit these categories.
If Internet mail transport (SMTP, as described by RFC 821) were upgraded to permit arbitrary binary data of unlimited length in message bodies, encoding a message for transport would not be necessary. The Internet Architecture Board (IAB) RFC 1341 defining MIME has been superseded by RFC 1521.
The MIME Types table lists MIME content types supported by most web servers and identifies their file extensions.