The creators of the Multipurpose Internet Mail Extensions (MIME) standard had a difficult challenge on their hands: how to bring flexibility in the types of data contained in e-mail messages, when RFC 822 said that they had to be comprised of only ASCII text. To accomplish this, they had to exploit the areas of flexibility that had already been put into the existing RFC 822.

There were two such “opportunities” available. The first was the fact that RFC 822 message bodies are allowed to contain any type of ASCII text, as long as lines don't exceed 998 text characters and each line ends with a “CRLF” control code combination. Even though the creators of RFC 822 naturally assumed this ASCII text would be human-readable, there was nothing stopping it from being machine-readable code. The second was the facility built into RFC 822 (and the protocols that use it, such as SMTP) to allow custom “user-defined” header fields to be added to any e-mail message.

The non-specific nature of RFC 822 message bodies forms the basis for how MIME itself works. An e-mail client that supports the MIME standard uses special encoding algorithms that transform non-ASCII information into ASCII form. It then places this set of encoded ASCII characters into the body of the message, as if it had been typed by a user, using one of two special structures.

The ability to add new headers to RFC 822 is used to communicate information about the use of MIME from the sender to the recipient. The devices transporting a MIME message don't care that MIME was used, because they don't pay attention to the contents of the message body. However, when the message reaches its destination, the recipient’s e-mail client program must have some way of knowing that MIME was used, and must also be told how the information in the message was encoded. Otherwise, it might just present the encoded non-ASCII data to the user as ASCII text (which would look like random gibberish!)