Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

This application/octet-stream type is also very often used for transmitting executable files

(programs) especially on Windows systems. Unfortunately, while convenient, this can be a

serious security hazard. In recent years, the Internet has been subject to a steady stream of

viruses and worms that spread by sending themselves to other users through executable

file attachments in e-mail. This makes opening and running any unknown application/octet-

stream attachment potentially dangerous.

MIME Composite Media Types: Multipart and Encapsulated Message Structures

MIME discrete media types allow MIME to represent hundreds of different kinds of data in

e-mail messages. This alone would make MIME an incredibly useful technology, but the

MIME standard goes one step further, by defining composite media types. These allow

MIME to perform even more “spectacular feats”, such as sending many types of data at

once, or encapsulating other messages or information into e-mail.

The use of a MIME composite media type is indicated via the Content-Type header of an

RFC 822 message. Instead of one of the six discrete media types (text, image, audio,

video, model and application), one of these two composite media types is used:

☯ Multipart Media Type (multipart): Allows one or more sets of data to be sent in a

single MIME message. Each piece of data is represented as an individual discrete

media type.

☯ Message Media Type (message): Allows a message to encapsulate another

message. This may be another e-mail message previously sent, or a message of

some other kind. This media type also provides flexibility for sending partial messages

and other special types of communication.

Key Concept: There are two MIME composite media types: message, which allows

one message to encapsulate another, and multipart, which allows multiple individual

media types to be encoded into a single e-mail message.

MIME Multipart Message Type

The multipart media type is the more common of the two, and for good reason: it is an

incredibly powerful mechanism. It allows one message to contain many different kinds of

information that can be used in different ways. Each piece of data is encoded separately as

a MIME body part and the parts are combined into a single e-mail message. How these

parts are used depends on the semantics of the message, which is indicated by the MIME

subtype. RFC 2046 describes several of these, and a few new ones have also been defined

by the IANA registration scheme described in the previous topic.

MIME Multipart Message Subtypes

The following are the most common multipart media subtypes, and how they are used. The

first four are defined in RFC 2046, and the others as indicated:

☯ multipart/mixed: Indicates that the body parts are not really related, but have just

been bundled for transport in a single message for convenience. For example, this

might be used by someone to send an office memo along with a vacation snapshot

just for fun. This subtype is also used sometimes when the parts are related but the

relationship is communicated to the recipient in some other way (such as a description

in a distinct body part).

☯ multipart/alternative: Specifies that the body parts are alternative representations of

the same information. The recipient decodes the parts and chooses the one that is

best suited to his or her needs. A common use of this is in sending HTML-encoded e-

mail. Some e-mail clients can't display HTML, so it is courteous to send a multipart/

alternative message containing the message in both HTML and plain text forms.

The alternatives should be placed in the message in increasing order of preference,

meaning that the preferred format goes last. In the case of a document that includes

plain text and rich text alternatives—such as the example above with plain text and

HTML versions of a document—the plainest format should go first and the “fanciest”

last.

☯ multipart/parallel: Tells the recipient that the body parts should all be displayed at the

same time (“in parallel”). One example of how this might be used would be if someone

sent an audio clip along with explanatory text to be displayed alongside it as it played.

☯ multipart/digest: This is used to allow a message to carry a digest, such as a

collection of other e-mail messages.

☯ multipart/related: Indicates specifically that the body parts are related to each other.

Special parameters are used to provide more information on how they are to be inter-

preted. This subtype was defined in RFC 2387.

☯ multipart/encrypted: Used for encrypted data. The first body part contains infor-

mation on how the data is to be decrypted, and the second contains the data itself.

This subtype was defined in RFC 1847.

Multipart Message Encoding

You can see just from these different subtypes how much flexibility the multipart type

provides to MIME, and there are others. In all cases, the same syntax is used to encode the

constituent body parts into a single message. The basic process is as follows:

1. Each individual piece of data is processed as if it were to be transmitted as the body of

a discrete media type MIME message. This includes the specification of appropriate

headers, such as Content-Type, Content-ID and Content-Transfer-Encoding, as

needed.

2. A special boundary delimiter is chosen to separate the body parts. It must be selected

so that it will not appear in any of the body parts; a random string is sometimes used. It

is prepended with two dashes (“--”) when placed in the message to reduce the chance

of it being mistaken for data.

3. The multipart message is assembled. It consists of a preamble text area, then a

boundary line, followed by the first body part. Each subsequent body part is separated

from the previous one with another boundary line. After the last body part, another

boundary line appears, followed by an epilogue text area.

4. The special parameter boundary is included in the Content-Type header of the

message as a whole, to tell the recipient what pattern separates the body parts.

Key Concept: MIME multipart messages are formed by first processing each

individual data component to create a MIME body part. Each can have a distinct

encoding method and set of headers, as if it were a separate MIME message. These

body parts are then combined into a single multipart message, and separated with a

boundary delimiter. The identity of the delimiter is inserted into the boundary parameter of

the Content-Type header, so the recipient can easily separate the individual body parts

upon receipt of the message.

Multipart Message Structure

These rules seem rather complicated, but they really aren’t that bad; once you’ve seen a

couple of multipart messages the structure will make sense. To help clarify, I have provided

Figure 302, which shows graphically the overall structure of a multipart MIME message.

Figure 302: MIME Multipart Message Structure

A MIME multipart message consists of a set of main headers and a main body portion, like all messages.

Within the main body are one or more body parts, each of which has its own body-part-specific headers

followed by the body part itself; each body part is shown in blue. The Content-Type header of the message as

a whole (highlighted in green) indicates that the message type is multipart, and the boundary parameter

specifies the name of the delimiter, in this case just called “Delimiter” (how boring.) This delimiter is used to

separate the body parts from each other and from the preamble and epilogue that begin and end the message

body, respectively.

Body

Part #1

--Delimiter

Headers

Body

...

MIME

Message

Content-Type: multipart/mixed; boundary="Delimiter"

Epilogue

Preamble

Body

Part #2

--Delimiter

Headers

Body

Part #N

--Delimiter

Headers

Body

Main

Body

Main

Headers

MIME-Version: 1.0

--Delimiter

Example Multipart Message

Table 249 contains a specific example of a multipart message (with portions abbreviated to

keep length down), so you can see what one looks like in text form. (If you want to see

more, you probably have several in your own e-mail inbox right now!)

In this example, Joe is sending Jane a multipart message containing a JPEG photograph

and some explanatory text. The main header of the message specifies the multipart/mixed

type and a boundary string of “exampledelimtext123”. The message begins with the

preamble, which is ignored by the recipient e-mail client but can be seen by the human

reader. It is common to put a string here such as the one given in this example. That way, if

a person using a client that does not support MIME receives the message, the recipient will

know what it is.

Table 249: Example MIME Multipart Message

From: Joe Sender <joe@someplace.org>

To: Jane Receiver <jane@somewhereelse.com>

Date: Sun, 1 Jun 2003 13:28:19 —0800

Subject: Photo and discussion

MIME-Version: 1.0

Content-Type: multipart/mixed; boundary="exampledelimtext123"

This is a multipart message in MIME format

—exampledelimtext123

Content-Type: text/plain

Jane, here is the photo you wanted me for the new client.

Here are some notes on how it was processed.

(Blah blah blah…)

Talk to you soon,

Joe.

—exampledelimtext123

Content-Type: image/jpeg; name="clientphoto.jpg"

Content-Transfer-Encoding: base64

SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs

…

zv/wAARCADIARoDASIAAhEBAxEB/8QAHAAAAQUBA

—exampledelimtext123

(Epilogue)

The first delimiter string is then placed in the message, followed by the first body part, the

text Joe is sending Jane. This is preceded by whatever headers are needed by the body

part, in this case Content-Type: text/plain. (Note, however, that this is the default in MIME,

so it could be omitted here.) After the text message is another delimiter and then the

encoded JPEG photo in the second body part, with its own headers. Finally, one more

delimiter and then a space for the epilogue. This is ignored if present, and is often not used

at all.

It is possible to send a “multipart” message that has only a single body part. This is

sometimes done to take advantage of the preamble area to provide information about how

to decode a non-text media type. Of course, this can also be done by including such text

decoding instructions as a body part.

MIME Encapsulated Message Type

The other composite media type is the message type, which is devoted to the special

purpose of encapsulating existing e-mail messages within the body of a new message, or

for encapsulating other types of messages. The following are the subtypes defined in RFC

2046:

☯ message/rfc822: Indicates that the body contains an encapsulated e-mail itself

formatted according to the RFC 822 standard. Note that this doesn't necessarily mean

it is a plain text e-mail message; it could be a MIME message (though encapsulating

MIME within MIME must be done carefully…)

☯ message/partial: Used to allow the fragmentation of larger messages into pieces that

can later be reassembled. This is described in detail in RFC 2046.

☯ message/external-body: Indicates that the body of the message is not actually

contained in the message itself; instead, a reference is provided to where the actual

body is located. Sufficient information to locate the real message body must be

provided. Again, this “out of body experience” is described in RFC 2046. (Sorry,

couldn't resist! ☺)

MIME Content-Transfer-Encoding Header and Encoding Methods

One of the main reasons why MIME was created was the significant restrictions that the

RFC 822 standard places on how data in e-mail messages must be formatted. To follow the

rules, messages must be encoded in US ASCII, a 7-bit data representation. This means

that even though each byte can theoretically have any of 256 values, in ASCII only 128

values are valid. Furthermore, lines can be no longer than 1000 characters including the

carriage return and line feed (“CRLF”) characters at the end, and those two characters

cannot appear elsewhere.

For some types of data, such as text files, this is no big deal, but for others it is a serious

problem. This is especially the case with binary data. If you look at the data in a video clip or

MP3 file or executable program, it will appear to be “random gibberish”. In fact, such data is

not random but is represented using specific rules, but the data is expressed in raw binary

form, where any 8-bit byte can contain any value from 0 to 255, which is why it looks like

“junk” to humans. More importantly, this means that this data does not follow the rules for

RFC 822 files and cannot be sent directly in this form.

MIME Encoding Methods

To send non-ASCII data in MIME, it is necessary that it be encoded. The Content-Transfer-

Encoding header is used to specify how a MIME message or body part has been encoded,

so that it can be decoded by its recipient. The following types of encoding are defined:

☯ 7bit: This indicates that the message is already in ASCII form compatible with RFC

822. It is the default and is what is assumed if no Content-Transfer-Encoding header is

present.

☯ 8bit / binary: These synonymous values mean the message has been encoded

directly in 8-bit binary form. Yes, I did just say that this would violate the rules of RFC

822. These options appear to have been included to support future mechanisms for

transporting binary data directly. RFC 1652 describes an SMTP extension that

discusses this in part: SMTP Service Extension for 8bit-MIMEtransport

(sic, there is no

space between “MIME” and “transport”). However, the standard is clear that this still

does not allow the transfer of raw binary data using SMTP and RFC 822.

☯ quoted-printable: This is a special encoding that is used when most of the data is

ASCII text, but when it contains certain violations of the rules of RFC 822. These illegal

sections are converted using special encoding rules so the data as a whole is

consistent with RFC 822.

☯ base64: An encoding used to allow arbitrary binary data to be represented in ASCII

form. The data is then sent as ASCII and decoded back into binary form by the

recipient.

The quoted-printable and base64 encodings are the most interesting ones, because they

are what allow non-RFC-822 data to be sent using RFC 822.

Key Concept: MIME supports four encoding methods: 7bit, 8bit (binary), quoted-

printable and base64. 7bit encoding is standard ASCII and is used for text; quoted-

printable encoding is for output that is mostly text but has some special characters

that must be encoded; base64 is used for arbitrary binary files. (The 8bit encoding method

is defined in MIME but not used for RFC 822 messages.)

quoted-printable Encoding

This encoding method is used when the message is “mostly” ASCII; only the problem bytes

are encoded. The result is that RFC 822 compatibility is achieved while maintaining most of

the data as regular text so it can still be easily understood by a human.

An example of where this would be letters with tildes or accents, such as those used in

French or Spanish. Another would be a text message formed using an editor that inserts

carriage return characters in the middle of a line. Most of the message is still text. The

quoted-printable encoding can be used here, with the carriage return characters repre-

sented as “=0D” (the hexadecimal value of the character prepended by an equal sign). RFC

2046 contains more details on how this is done.

base64 Encoding

In contrast, the base64 encoding is more often used for raw binary data that is not in

human-readable form anyway, such as graphical images, audio, video and application files.

The idea behind it is simple: the data that needs to be sent can have any value for each 8-

bit byte, which is not allowed. So, why not rearrange the bits so the data “fits” into the 7-bit

ASCII limits of RFC 822?

This is done by processing the data to be sent three bytes at a time. There are 24 bits in

each three-byte block, which are carved into 4 sets of 6 bits each. Each 6-bit group has a

value from 0 to 63, and is represented by a single ASCII character as presented in Tab le

250.

For example, suppose the first three bytes of the data to be sent were the decimal values

212, 39 and 247. These cannot all be expressed in 7-bit ASCII. In binary form they are:

11010100 00100111 11110111

Table 250: MIME Base64 Encoding Groups

6-bit

Value

Encoding

6-bit

Value

Encoding

6-bit

Value

Encoding

6-bit

Value

Encoding

0 A 16 Q 32 g 48 w

1 B 17 R 33 h 49 x

2 C 18 S 34 i 50 y

3 D 19 T 35 j 51 z

4 E 20 U 36 k 52 0

5 F 21 V 37 l 53 1

6 G 22 W 38 m 54 2

7 H 23 X 39 n 55 3

8 I 24 Y 40 o 56 4

9 J 25 Z 41 p 57 5

10 K 26 a 42 q 58 6

11 L 27 b 43 r 59 7

12 M 28 c 44 s 60 8

13 N 29 d 45 t 61 9

14 O 30 e 46 u 62 +

15 P 31 f 47 v 63 /

We can divide these into four 6-bit groups:

110101 - 00 0010 - 0111 11 - 110111

Which yields the four values 53, 2, 31 and 55. Thus, the values 214, 39 and 247 would be

encoded as the three ASCII characters “1Cf3”. The conceptual steps of this process are

shown in Figure 303.

Note: The sequence of steps for the encoding that I mentioned above and showed

in the figure are intended to help you understand the process. Computers inher-

ently deal directly with bits, and so would not bother with converting to decimal

before encoding the 6-bit groups into ASCII characters.

This 3-to-4 encoding is done for all the data. The converted ASCII characters are then

placed into the body of the entity instead of the raw binary data, 76 characters to a line. I

showed how this is done in the second body part in the example of Table 249 (except I

didn't put 76 characters per line, to keep the line lengths short). One final character is

involved in this scheme, the equal sign (“=”), which is used as a padding character when

needed.

Since base64 characters are regular ASCII, they appear to SMTP like a “regular text

message”. Of course the data looks like gibberish to us, but that's not a problem since it will

be converted back to its regular form and displayed to the recipient as an image, movie,

audio or whatever.

Figure 303: MIME Base64 Encoding

In this simplified example, three binary data bytes are encoded as four ASCII characters using MIME base64

encoding. Instead of transmitting those three bytes, two of which would not be valid in RFC 822, the four

ASCII characters “1Cf3” are sent.

212 39 247

11010100 00100111 11110111

110101 000010 011111 110111

53 2 31 55

1 C f 3

Data Bytes in

Decimal Form

Data Bytes In

Binary Form

Data Rearranged Into

6-Bit Groups

In Decimal Form

Groups Converted To

ASCII Characters

Key Concept: MIME uses base64 encoding to transform arbitrary 8-bit files into a

form that is acceptable for communication in e-mail. Each set of three 8-bit bytes is

divided into four 6-bit groups, and each 6-bit group represented by an ASCII

character. Since the data is ASCII, it conforms to the RFC 822 message format standard,

even if it is not human-readable. The receiving device reverses the encoding, changing

each four-character block back into three 8-bit bytes.

The main drawback of the base64 method? It is about 33% less efficient than sending

binary data directly, using something like FTP. The reason is that three 8-bit bytes of binary

data are sent as four ASCII characters, but of course, each ASCII character is represented

using 8 bits itself. So there is 1/3 extra overhead when using base64. In most cases this is

not a big deal, but it can be significant if downloading very large e-mail files over a slow

Internet connection.

Note that RFC 2046 also defines two other encodings: ietf-token and x-token. These are

included to allow new encoding types to be defined in the future.

MIME Extension for Non-ASCII Mail Message Headers

All of the MIME mechanisms discussed in this section up to this point deal with ways of

encoding different kinds of ASCII and non-ASCII data into the body of an RFC 822

message. In addition to these capabilities, MIME also includes a way in which non-ASCII

data can be encoded into headers of an RFC 822 message.

The Need for MIME-Encoded Headers

At this point you might be wondering why anyone would want to do this. Sure, it makes

sense to be able to use MIME to encode binary data such as an image into an e-mail, but

why do it in a header? Well, if you can't see the need for this, chances are that you are a

native English speaker. ☺ ASCII does a great job of representing English, but isn't so hot

with many other languages. With RFC 822, the speakers of languages that use non-ASCII

characters were unable to fully use descriptive headers such as the Subject and Comments

headers. Some could not even properly express their own names!

The solution to this problem is the subject of RFC 2047, the third of the five main MIME

standards. It describes how to encode non-ASCII text into ASCII RFC 822 message

headers. The idea is straight-forward: just as with message bodies, the non-ASCII text is

replaced with ASCII, and information is provided to describe how this was done.

MIME Encoded-Word Syntax

In the MIME non-ASCII header technique, the value of a regular header is replaced by a

MIME encoded-word that has the following syntax:

=?<charset>?<encoding>?<encoded-text>?=