Multipurpose Internet Mail Extensions (MIME)

The SMTP protocol can be used to send only NVT 7-bit ASCII text. It cannot work with some languages (French, German, etc. ...). Furthermore, it cannot be used to send multimedia data (binary files, video, audio, etc.). Here is where the Multipurpose Internet Mail Extensions (MIME) protocol extends SMTP to allow for non-ASCII data to be sent. We should note that it is not an email transfer/access/retrieval protocol, unlike SMTP, POP, and IMAP.

The way MIME works is quite simple from a conceptual viewpoint. MIME transforms non-ASCII data at the sender’s end into NVT ASCII and delivers it to the client SMTP for transmission. At the receiver’s end, it receives NVT ASCII data from the SMTP server and transforms it back into the original (possibly non-ASCII) data. This is shown in Fig. 5.23.

Fig. 5.23 MIME concept

While it is okay to say this conceptually, how is this done in actual practice? To convert non-ASCII data to ASCII format, MIME uses the concept of Base64 encoding. It is a very interesting and effective process. In Base64 encoding, three bytes are considered at a time, each of which consists of eight bits. Thus, we have 3 × 8 = 24 bits. Base64 then represents these 24 bits as four printable characters, each consisting of 6 bits, in the ASCII standard. Why is this done? Let us understand.

The whole aim of MIME is to transform non-ASCII data to ASCII. We know that ASCII is 7-bit in the basic form. That is, in ASCII, each character occupies 7 bits. Hence, if something has to be transformed into or represented in ASCII, it must occupy not more than 7 bits per character. Therefore, Base64 encoding chooses something closest to this pattern of 7 bits per character, which happens to be 6 bits per character. We know that Base64 only uses 6 bits (corresponding to 2⁶ = 64 characters) to ensure that encoded data is printable and humanly readable. Therefore, special ASCII characters are not used. The 64 characters (hence the name Base64) consist of 10 digits, 26 lowercase characters, 26 uppercase characters as well as the + and / characters.

These steps in Base64 encoding are outlined in Fig. 5.24 with an example.

125

Step 1 Here, we convert three 8-bit bytes to four 6-bit characters.

Suppose that our non-ASCII data that needs to be conver ted into ASCII using Base64 encoding is 100110111010001011101001. Using 8-bit ASCII, it looks as follows:

10011011 in binary = 155 in decimal 10100010 in binary = 162 in decimal 11101001 in binary = 233 in decimal

We split the bit pattern into four 6-bit bytes, as follows:

100110 in binary = 38 in decimal 111010 in binary = 58 in decimal 001011 in binary = 11 in decimal 101001 in binary = 41 in decimal

Step 2 Here, we assign the symbols equivalent to the above bit patterns by using the Base64 table. The table is as shown below.

Hence, our four 6-bit slots can now be mapped to the corresponding Base64 letters, as follows:

100110 in binary = 38 in decimal = m as per the Base64 mapping table 111010 in binary = 58 in decimal = 6 as per the Base64 mapping table 001011 in binary = 11 in decimal = L as per the Base64 mapping table 101001 in binary = 41 in decimal = p as per the Base64 mapping table

Hence, our original non-ASCII text of 155, 162, and 233 in decimal (or 100110111010001011101001 in binary) would be sent as m6Lp (i.e., as the binary equivalent of this text).

Fig. 5.24 MIME example

For performing all these operations, the concept of MIME headers is used. MIME defines five headers that can be added to the original SMTP header section to define the transformation parameters. These five headers are given below.

n MIME-Version

n Content-Type

n Content-Transfer-Encoding

n Content-Id

n Content-Description

Such an email message looks as shown in Fig. 5.25.

126

Fig. 5.25 MIME headers Table 5.9 explains the five MIME headers.

Table 5.9 MIME header details

MIME header Description

MIME-Version This contains the MIME version number. Currently, it has a value of 1.1. This field is reserved for the future use, when newer versions of MIME are expected to emerge.

This field indicates that the message conforms to RFCs 2045 and 2046.

Content-Type Describes the data contained in the body of the message. The details provided are sufficient so that the receiver email system can deal with the received email message in an appropriate manner. The contents are specified as: Type/Sub-type.

MIME specifies 7 content types, and 15 content sub-types. These types and sub-types are shown later.

Content-Transfer- Specifies the type of transformation that has been used to represent the body of the Encoding message. In other words, the method used to encode the messages into zeroes and

ones is defined here. There are five content encoding methods, as shown later.

Content-Id Identifies the whole message in a multiple-message environment.

Content-Description Defines whether the body is image, audio, or video.

The Content-Type header can contain the following types and sub-types, as shown in Table 5.10.

Table 5.10 MIME content types and sub-types

Type Sub-type Description

Text Plain Free form text.

Enriched Text with formatting details.

Multipart Mixed Email contains multiple parts. All parts must be delivered together, and in sequence.

(Contd)

127

Type Sub-type Description

Parallel Email contains multiple parts. All parts must be delivered differently, in different sequence.

Alternative Email contains multiple parts. These parts represent the alternative versions of the same information. They are sent so that the receiver’s email system can select the best fit from them.

Digest Similar to Mixed. Detailed discussion is out of scope of the current text.

Message RFC822 The body itself is an encapsulated message that conforms to RFC 822.

Partial Used in fragmentation of larger email messages.

External-body Contains a pointer to an object that exists somewhere else.

Image Jpeg An image in JPEG format.

Gif An image in GIF format.

Video Mpeg A video in MPEG format.

Audio Basic Sound format.

Application PostScript Adobe PostScript.

octet-stream General binary data (8-bit bytes).

The Content-Transfer-Encoding header can specify one of the following, as shown in Table 5.11.

Table 5.11 Content-Transfer-Encoding

Type Description

7-bit NVT ASCII characters and short lines

8-bit Non-ASCII characters and short lines

Binary Non-ASCII characters with unlimited-length lines Base-64 6-bit blocks of data encoded into 8-bit ASCII characters

Quoted-Printable Non-ASCII characters encoded as an equal to sign, followed by an ASCII code

Figure 5.26 shows an example of a real-life email message containing some MIME headers.

Microsoft Mail Internet Headers Version 2.0 Subject: Great news! We have done it!

Date: Wed, 27 Jun 2007 16:05:38 +0530

Message-ID: <[email protected]>

In-Reply-To: <[email protected]>

Table 5.10 contd...

(Contd)

128

X-MS-Has-Attach: yes

X-MS-TNEF-Correlator: <[email protected]>

From: “Umesh Aherwadikar-AMB” <[email protected]>

To: “Atul Kahate-AMB” <[email protected]>

Fig. 5.26 MIME example