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 Electronic Mail Standard Message Format: RFC 822

TCP/IP Electronic Mail Standard Message Format: RFC 822 1 2 3 TCP/IP Electronic Mail RFC 822 Standard Message Format Header Field Definitions and Groups

Overview of RFC 822 Messages

Where RFC 822 differs from the field formats of other protocols is in expression. Most TCP/IP protocols encode header information into a compact set of bytes that are read and understood based on their location in the message and the semantic meaning assigned to them. Consider the Internet Protocol, for example. The 9th byte of every IP datagram is the Time To Live (TTL) field, which is encoded as a value from 0 to 255. A device reading an IP datagram simply knows that byte number 9 contains the TTL value. If it sees the binary value “00010011” there, it knows the TTL value for this datagram is the decimal value 19.

In contrast, RFC 822 messages do not use a binary format. They are entirely comprised of lines of regular ASCII text (as used in the United States, called US-ASCII by the standard), even the headers. Each line ends with an ASCII carriage return (CR) character, followed by a line feed (LF) character; the combination is collectively termed “CRLF”. Each line of text should be 78 characters or less (not including the terminating “CRLF”) and must not be more than 998 characters (again, excluding the “CRLF”). Also, the characters CR and LF must not appear by themselves within the text.

The RFC 822 message begins with a set of lines of text that collectively comprise the message header. Each header field is expressed in the following form, in text:

<header name>: <header value>

So, for example, if there were a Time To Live field in RFC 822 messages (there isn't, of course, as that concept has no meaning to e-mail) and a value of 19 needed to be expressed, the header field would appear like this:

Time To Live: 19

This expressing of all fields as simple text means each header takes up more space in each message; the string “Time To Live: 19” takes up 18 bytes including the terminating “CRLF”, where the binary-encoded Time To Live field in the IP header takes only a single byte. What we gain from this are two important benefits. First, any user can easily check the headers and immediately understand what headers are present and what their values are, which makes RFC 822 messages very readable. Second, since each header is explicitly labeled, RFC 822 messages can vary in terms of the number of headers they contain, and even in what order they appear, making them flexible.

TCP/IP Electronic Mail Standard Message Format: RFC 822 1 2 3 TCP/IP Electronic Mail RFC 822 Standard Message Format Header Field Definitions and Groups