Inside Email Attachments

Understanding the not-so-simple mail transfer protocol

I often hear this question from my customers. They want to know why TCP/IP's Simple Mail Transfer Protocol (SMTP) doesn't simply transfer mail. Transferring simple text mail between two machines that run a basic mail program and use TCP/IP as their network stack is pretty simple. In the Internet's early days, SMTP's ability to send mail to an individual user rather than a machine was revolutionary, so SMTP became popular. However, email started getting complicated when users expected more than SMTP could deliver. This article examines the main factors that facilitate and complicate message transfer over the Internet.

Request for Comments (RFC) 821 and RFC 822 illustrate how SMTP works. These RFCs define the two sections that an SMTP message consists of. The first section is the Envelope, which contains a destination address and a return address. The second section is the Bodypart, which consists of only 7-bit ASCII text. (For more information about SMTP's basics, see Mark Minasi, Inside Out, "Untangling Email," April 1998.)

Great Expectations
Nowadays, users want to send text mail between different kinds of messaging systems and to include word processing, spreadsheet, presentation, and other files in a form recipients can use. This expectation is easy to meet for a LAN mail system in which everybody uses the same mail program. Sending mail between different messaging systems is an entirely different matter.

Suppose you've selected SMTP as the common transfer mechanism for your company's messaging products. SMTP allows only ASCII characters 0 through 127. So, what's the low-order ASCII character for a 12-point bold Helvetica J? SMTP needs help transferring complex files, such as binaries.

UUencode. One SMTP helper is UUencode. UUencode uses low-order ASCII characters to describe complex binaries by using an algorithm to perform the conversion. Think of UUencode as a type of encryption. The sending system uses UUencoding to convert the binary file and sends the message. The receiving system gets the UUencoded message, uses UUdecode to translate it into its original form, and gives the message to the recipient in its native format.

The UUencoded file begins with a header that tells the receiving system the original filename. The receiving system's UUdecoding software sees the header and translates the data that follows until it reaches end. This translation usually results in a usable file that the system delivers to the user.

However, UUencoding has a few problems. First, no RFC describes the algorithm UUencoding and UUdecoding use to convert binaries. Consequently, various software's implementations of UUencoding can differ. Second, some UUencode implementations can handle multiple attachments, and some can't. Finally, UUencoding converts formatted text of many kinds, but it can convert only text. Therefore, it can handle the aforementioned 12-point bold Helvetica J; however, UUencode can't translate images of any kind.

MIME. Recognizing the limitations of SMTP binary attachment mechanisms, such as UUencode, developers created RFC 1341, "MIME: Mechanisms for Specifying and Describing the Format of Internet Message Bodies." This alternative to UUencode changed the paradigm for handling binary attachments. MIME's developers recognized that the types and structures of attachments users send over the Internet are constantly changing, so they developed an extensible solution to SMTP's translation problem.

MIME uses low-order ASCII characters to create a header, which MIME wraps around each attachment and encodes the attachment. The encoding scheme MIME uses is base64. Unlike UUencode, base64 is well defined and includes a broad set of encoding definitions. MIME can encode sounds and images. And any MIME-compliant system can exchange complex binary attachments with any other MIME-compliant system.

A MIME-encoded attachment includes the encoded data and header and trailer information. The sending system sends the attachment in 7-bit ASCII text, as Figure 1 shows.

The boundary ID at the beginning and end of the message delimits this message for the receiving system. Between the boundary IDs is a series of headers that defines the content of the attachment. In addition, these headers separate attachments in a message that contains multiple attachments. The headers clearly identify the attachment type, original filename, and encoding mechanism. RFC 1521 discusses the details of base64 encoding.

MIME or UUencode
Microsoft Exchange Server Internet Mail Service (IMS) can send UUencoded or MIME-encoded messages and receive either type of encoded message. To configure the encoding mechanism, double-click Internet Mail on the Connections menu in Exchange Administrator. Next select MIME or UUENCODE in the Send Attachments Using option box.

A MIME-encoded attachment is useless to a mail system that understands only UUencode. Therefore, you might need to set up two servers' IMSs to handle your network's translations to and from SMTP. You can set up one server to be MIME-enabled and the second server to use UUencode. On the server using UUencode, insert the addresses of destinations that require UUencoding in the Internet Mail Service Properties window, which Screen 1 shows. When Exchange Server determines how to route the outgoing message, it will select the IMS on the server that uses UUencoding to deliver messages destined for domains listed in this window.

Not-So-Simple Mail Transfer
The progression of Internet mail from a simple, text-based environment to the complex interchange of information in a variety of forms has complicated simple mail. SMTP gateways provide functions necessary for completing this data interchange. Capable gateways, such as the IMS, can convert binary attachments to a format you can transmit over the Internet via SMTP. Currently, users deal with two kinds of mail systems—those that understand only UUencode or MIME-compliant systems. Although SMTP will never be as simple as its name suggests, MIME-compliant system development might simplify configuring email servers in the future.

Corrections to this Article: