Seven-bit data is simple US-ASCII text, with the restrictions placed on it by RFC 821. No octets with ASCII decimal values of zero or more than 127 are allowed. Carriage return and linefeed characters occur only as part of a line-ending CRLF sequence. It is the only type of data that is guaranteed to be “safe” to transport across the Internet mail system. By safe, I mean that it will transit all RFC 821-compliant mail system elements without being chopped, changed, mutilated, or stripped. Further, since we are not relying on esoteric parts of the standard, we are hoping that most implementations (which are rarely 100 percent standards compliant) will handle the message.

Note that the quoted-printable and base64 encodings, used for attaching binary documents, result in 7-bit data. Therefore, they are also safe for Internet transit.

Seven-bit data may consist of any of the following characters:

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ
[]^_'abcdefghijklmnopqrstuvwxyz{|}~

plus spaces, tabs and the various control sequences (those with
values of 1-31 and 127 decimal).

Eight-bit data is much like 7-bit, except that ASCII characters with decimal values over 127 are also allowed. This type of data is allowable on some mail systems but not on systems built upon the Internet’s standard Simple Mail Transfer Protocol. If you are creating mail transiting the Internet, intervening mail servers (gateways) may translate this type of data to 7-bit, quoted-printable, or base64. If you are creating mail destined to route directly onto the Internet, don’t use this encoding type.

Binary data may contain any type of octets, irrespective of their possible translation to ASCII. The same restrictions and notes for 8-bit data apply to binary. Simply don’t use this encoding type for Internet use via SMTP. An MUA should translate binary data into the base64 encoding type as described in the section “base64,” later in this chapter.

All of the preceding information leaves us with a few simple rules for handling messages at MTAs and MUAs.

If you are writing an SMTP MTA, you will need to convert 8-bit MIME attachments to either quoted-printable or base64. Similarly, any binary attachments that you receive must be converted to base64. Many MUAs convert any non-7-bit ASCII data to base64 for simplicity.

If you are writing an MUA, you must deal with whatever types of data that you receive. You will need to parse the MIME headers of each and every attachment in a message and determine how to handle it. If you receive 7-bit ASCII data in an MUA, you do not need to do anything special, just display it. Similarly, you can simply display 8-bit data, presuming that you can display the full extended ASCII set. Binary data, of course, needs to be treated appropriately. Binary data can be handled based on Content-Type and Content-Disposition information. Quoted-printable and base64 decodings are discussed in detail in the next sections.

Let’s look at an example. Let’s say that a Lotus Notes user attaches a Microsoft Word document to an email message and sends it to a recipient via the Internet. The message will originally be in Lotus’ proprietary mail format. The attachment may be in a binary format. In routing to the Internet, the message will pass through an SMTP/ Lotus gateway MTA, which will convert the attachment from its binary format to a base64-encoded MIME attachment and will convert the rest of the message from Lotus format to SMTP RFC 822 format. When the recipient’s MUA receives the message, it will decode the base64 attachment back to a binary representation so that Microsoft Word can recognize it.