Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Key Applications and Application Protocols            9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)                 9  TCP/IP Electronic Mail System: Concepts and Protocols (RFC 822, MIME, SMTP, POP3, IMAP)                      9  TCP/IP Electronic Mail Message Formats and Message Processing: RFC 822 and MIME                           9  TCP/IP Enhanced Electronic Mail Message Format: Multipurpose Internet Mail Extensions (MIME)

TCP/IP Enhanced Electronic Mail Message Format: Multipurpose Internet Mail Extensions (MIME) 1 2 3 MIME Basic Structures and Headers

I describe the reasons why universal standards are important in the Networking Fundamentals chapter of this Guide, and re-emphasize the point in many other places as well. Most protocols become successful for the specific reason that they are based on open standards that are widely accepted. The RFC 822 e-mail message format standard is an excellent example; it is used by millions of people every day to send and receive TCP/IP e-mail.

However, success of standards comes at a price: reliance on those standards. Once a standard is in wide use, it is very difficult to modify it, even when times change and those standards are no longer sufficient for the requirements of modern computing. Again here, unfortunately, the RFC 822 e-mail message format is an excellent example.

TCP/IP e-mail was developed in the 1960s and 1970s. Compared to the way the world of computers and networking is today, almost everything back then was small. The networks were small; the number of users was small; the computing capabilities of networked hosts was small; the capacity of network connections was small; the number of network applications was small. (The only thing that wasn't small back then was the size of the computers themselves!)

As a result of this, the requirements for electronic mail messaging were also rather… small. Most computer input and output back then was text-based, and it was therefore natural that the creators of SMTP and the RFC 822 standard would have envisioned e-mail as being strictly a text medium. Accordingly, they specified RFC 822 to carry text messages.

The fledgling Internet was also developed within the United States, and at first, the entire internetwork was within American borders. Most people in the United States speak English, a language that as you may know uses a relatively small number of characters that is well-represented using the ASCII character set. Defining the e-mail message format to support United States ASCII (US-ASCII) also made sense at the time.

However, as computers developed, they moved away from a strict text model towards graphical operating systems. And predictably, users became interested in sending more than just text. They wanted to be able to transmit diagrams, non-ASCII text documents (such as Microsoft Word files), binary program files, and eventually multimedia information: digital photographs, MP3 audio clips, slide presentations, movie files and much more. Also, as the Internet grew and became global, other countries came “online”, some of which used languages that simply could not be expressed with the US-ASCII character set.

Unfortunately, by this point, the die was cast. RFC 822 was in wide use and changing it would have also meant changes to how protocols such as SMTP, POP and IMAP worked, protocols that ran on millions of machines. Yet by the late 1980s, it was quite clear that the limitations of plain ASCII e-mail were a big problem that had to be resolved. A solution was needed, and it came in the form of the Multipurpose Internet Mail Extensions (MIME).

TCP/IP Enhanced Electronic Mail Message Format: Multipurpose Internet Mail Extensions (MIME) 1 2 3 MIME Basic Structures and Headers