|Overview of Internet Mail Standards
by Paul Hoffman, Internet Mail Consortium
People who are new to the Internet often think it is equivalent to "the Web" since that's what they have heard about most in the media. After a few weeks of using their new Internet account, they tend to say the Internet is "e-mail and the Web," in that order.
Business users have an even higher regard for e-mail. According to the American Management Association, most business people say that e-mail has surpassed the telephone in importance for business communication. While many companies believe that their Web site will be very important in a few years, their e-mail system is already extremely critical to them today.
Because mail is one of the oldest services on the Internet, the protocols used to move mail around are more stable and mature than those used for newer services. The flip side of this is that some of the protocols that are used to move the billions of pieces of mail a day are somewhat arcane and even quaint. The Internet Engineering Task Force (IETF) motto "if it isn't broken, don't fix it!" has prevented people from redesigning Internet mail. Instead, numerous extensions and enhancements have been added to the original set of mail standards, as we shall see later.
Historically, there have been many other mail systems, such as BIT-NET, Fidonet, MAPI, cc:Mail, and so on. Of course, users of these systems still exist, and there is quite an active market for systems that act as gateways between Internet mail and other systems. However, this article only covers the tried-and-true Internet mail system.
The Internet Mail Model
Many Internet protocols are simple client/server systems with a single message payload format. Mostly due to history, Internet mail doesn't have this luxury. Figure 1 shows the main protocols and formats used to move Internet mail.
A typical mail transaction goes from left to right in the figure. A Mail User Agent (MUA), which is most often run by a human but could be controlled by a program, submits a message using the Simple Mail Transfer Protocol (SMTP) to the initiating host. That host looks up the IP address associated with the destination host computer and sends the message to the destination host using SMTP. The destination host receives the message and writes it into the local message store (which almost always is a file or database on a hard drive).
The recipient MUA checks the mail store periodically and, if there is mail, retrieves it. Again, the recipient is often a human but might be an automated program such as an order entry system that is controlled by e-mail. The protocols that checks for and retrieves mail are usually the Post Office Protocol (POP) or Internet Message Access Protocol (IMAP), but it could also be any number of proprietary systems.
E-mail messages have a format that is quite easy to understand, so much so that many other protocols have adopted very similar formats. The message consists of ASCII text headers followed by one ASCII (or possibly binary) message body . The header format is defined in RFC 822 , thus the headers are called "RFC 822 headers" or just "822 headers." A simple message body is a single string of text; a complex body uses the Multipurpose Internet Mail Extensions (MIME) message format.
Moving Between Hosts: SMTP
Early host-to-host mail delivery was done using file transfer protocols. Since such methods offer little flexibility and requires knowledge of user names and file structures of the remote system, a more general purpose delivery mechanism evolved. The resulting protocol, SMTP was defined in 1982 and has proven to work effectively in the face of orders of magnitude increase in the size of the network.
Even though SMTP moves mail between two host computers, it is a client/server protocol. The host that initiates the contact always acts as a client , and the host that was contacted is the server . (There are a few rarely-used exceptions to this rule.) The client has a variety of text-based commands that it can give, and the server replies with short responses. The server in the relationship never gives commands on its own, so it is up to the client to ask enough questions, and to carefully watch the server's responses, to know how best to interact with the server.
When a host wants to send mail somewhere on the Internet, it determines where the mail should go and initiates contact with the target server. Thus, the sender is always the SMTP client, and the hosts that are listening for SMTP traffic are always servers. In reality, most SMTP server software can act both as clients and servers; MUAs almost always only participate in SMTP as clients.
The sending host uses the Domain Name System (DNS) to determine the IP address of the target host, contacts that host using TCP port 25, and uses SMTP to deliver the message. Sometimes, as we shall see later, this IP lookup involves a level of indirection, the target host may use a different host to receive mail on its behalf.
SMTP client commands consist of a keyword, possibly followed by command arguments. The server's response always starts with a three-digit number that is a status indicator, which is possibly followed by additional information.
Most SMTP interactions follow a typical set of steps, shown in Figure 2. The initiator who has mail to send (the client) is on the left and the host that is receiving the mail (the server) is on the right. The client first opens a TCP connection on port 25 on the the server. Next, the client and server exchange greetings (the HELO command and response). The client then prepares the server to receive the message by telling the server who the message is from and who it is to; the server gives a positive acknowledgment to each of these commands. The client then asks if the server is ready for the body of the message and, when the server says yes, sends the message as a stream of lines that is followed by a single period on a line by itself. After the server says that it has received the message fully, the client says good-bye and closes the connection.Figure 2: A Typical SMTP Exchange
*Note:Click above for larger view
Submission and Relay
After a message is created, the creator uses SMTP to submit the message to one of two places: a local mail-forwarding host (such as the mail server at the sender's Internet Service Provider (ISP) or corporate IS services) or the mail server that the DNS says is definitive for the recipient. The former is typically used by Internet users who do not have persistent network connections; the latter is more common on systems with network connections that are always available.
Messages may be forwarded hop-by-hop from the sending host, via intermediary hosts, to the recipient. This is called "relaying." In many cases, a message will go through more than two relays, for instance when the recipient's network is configured to accept all incoming messages on one machine that later relays messages to individual departmental hosts. Note that submission and relay uses the same SMTP commands described above (a recent change to this scheme is described near the end of this article).
The last host in the chain makes the message available to the recipient. This is done by moving the message to the message store, which usually means "write the message out on disk." There are, of course, many ways to write something on disk; some hosts write out each message as a separate file, some concatenate the message at the end of a file, while others write the message into a database.
Mail Addresses and MX Records
The initiating host's first job is to determine where a message is supposed to go, that is, how to contact the recipient's host. SMTP is a hop-by-hop protocol, meaning that a sending host does not know the true destination host for a message: it only knows the designated recipient host. Of course, this might be the recipient's final host, or it might be a host that will pass the message along further.
The domain name in mail addresses do not necessarily correspond to hosts on the Internet. For example, there is no host whose domain name is imc.org . When determining where to send a message, the initiating host first looks in the DNS for a Mail Exchange (MX) record that matches the domain name in the recipient's mail address. If there is no MX record, the initiating host looks for a DNS A record that matches the domain name. If there is no MX record or A record, the message cannot be delivered.
Many people find MX records to be somewhat tricky. Part of the confusion comes from the fact that an SMTP host is supposed to look up MX records before they look for A records; there are very few protocols that don't rely on A records. Another confusing aspect is that MX records may have wildcards in them. For instance, if a message is being sent to firstname.lastname@example.org , there may be no MX record for eng.example.com , but there may be one for *.example.com . Wildcard MX records tell the sending host that any message for a domain name that matches the wildcard specification should be sent to the named host.
Mordern Mail Extensions
All protocols must evolve, and SMTP has improved over the years. Early mail implementors realized that the initial set of SMTP commands would have to expand. Since the SMTP client gives all commands in an exchange, the client determines which SMTP commands a server will be able to handle. The SMTP Service Extensions (ESMTP), defined in RFC 1869 , is a small change to SMTP that allows an SMTP server to list the commands it knows at the beginning of an SMTP session.
The bootstrapping process for ESMTP is quite simple. Instead of starting with the "HELO" command, an ESMTP server starts with the "EHLO" command. If the SMTP host indicates that it has no idea what "EHLO" means, the client knows that the server doesn't understand ESMTP, and therefore doesn't understand any SMTP extensions. On the other hand, if the server does understand the "EHLO" greeting, the host responds with the entire list of SMTP extensions that the client is allowed to use during the session.
There have been over a dozen extensions to SMTP that are on standards track in the IETF, and many more have been proposed. However, most modern SMTP servers have only implemented a few of these.
Probably the most publicized SMTP extension in the past few years has been the SMTP Service Extension for Authentication (AUTH) for authenticating the SMTP client to the server. The AUTH extension, described in RFC 2554 , allows roaming users to submit mail from outside their local networks without forcing the servers to accept mail from just anyone. This new method, which is now starting to appear in both mail clients and servers, will reduce the hassle faced by many roaming users as they move from ISP to ISP.
Another significant SMTP extension that has become widely implemented is Delivery Status Notifications , or DSNs defined in RFC 1891 . These are similar to return receipts in postal mail, but with some significant differences. DSNs are issued by SMTP servers, not end users. Thus, the meaning of a DSN is interpreted as "the message was received by this SMTP host," not "the message was received by the intended recipient."
After the final SMTP server has received a message and written it into the message store, the recipient needs to be able to access the message. In the early days of Internet mail, the message store was nothing more than a text file on disk, and mail was read by reading the text file. In fact, many people still read their mail this way, albeit using somewhat more modern tools.
If the recipient is not directly logged into the host computer that has the message store, reading the disk file can be difficult. To alleviate this problem, the Post Office Protocol (POP), described in RFC 1939  introduced a client/server model for an MUA to get mail from the message store and store it on the local computer. The vast majority of mail users today use POP to retrieve their mail.
POP looks like many Internet protocols. The client connects to the server, logs in using a user name and password, checks if it has any messages waiting for it, then asks for the messages one by one. The client has the option of leaving messages that it has read on the server or deleting them after they have been retrieved.
Modern Mail Access with IMAP
Although POP works well for many people, it has its drawbacks. The mail client cannot preview a message to see whether or not it wants to download it. The client has only one mailbox which has no hierarchical structure. In most POP systems, leaving all your mail on the server makes retrieving new mail quite slow. To get around these problems, the mail community developed the Internet Message Access Protocol (IMAP), described in RFC 2060 .
IMAP is significantly more powerful than POP. IMAP clients give the user much more control over their mail, such as letting them keep some of their mail locally while leaving other mail on the server. IMAP even allows for mailboxes that are shared among users, such as group announcements lists. It also gives mail administrators many more opportunities to support novice users by keeping their mail in a central location. Most modern mail clients support IMAP, and IMAP servers are available from many vendors.
It should be noted that, although IMAP is considered much more useful than POP and is widely available, it has had very little adoption in the ISP market (it has been accepted much more readily in the enterprise mail market). The reasons for this are not clear. Many ISPs say they do not want to incur the costs and responsibilities of storing users' mail, even if this gives them greater ability to administer the mail. It is not clear what, if anything, will shift ISPs away from POP to IMAP.
Access Through Web Browsers
The ubiquity of the Web has introduced a new method for getting mail that has become surprisingly popular: the use of the HyperText Transfer Protocol (HTTP). Web access to e-mail lets users read their mail without a POP or IMAP client. Of course, this offers many fewer features than POP or IMAP; for instance, you can't easily store messages after reading them and getting file attachments in your mail takes many more steps. However, the big advantage of this method is that Web browsers are almost everywhere these days, and there are many situations where you don't care about being able to store your mail on your local computer.
Giving users Web browser access to their mail quickly became a commodity market. Now, almost every portal offers such services. In fact, many corporations and ISP also offer this service because it is a fairly easy add-on to POP and IMAP servers. As more and more users want to access their e-mail from small devices such as cellular phones, it is likely that these devices will include Web-like mail interfaces.
Both POP and IMAP are extensible, and developers have proposed many extensions for both protocols, although most work is being done on IMAP. Because of the slow adoption of IMAP by ISPs (who could make its advantages much more visible), it's not clear when these will appear in clients and servers, even though many of them add interesting functionality that is wanted by both users and administrators.
There are many client extensions that don't rely on either POP or IMAP, however. One of the most popular is Message Disposition Notifications (MDNs), which are quite similar to postal return receipts. Unlike DSNs, which say that a particular message got to one of the servers in an SMTP chain, MDNs are truly end-to-end, and are returned by recipients when they open their mail.
Some people find MDNs intrusive ("why should he know when I read this?"), and they aren't particularly reliable because not all mail clients (most notably Web browser readers) support them. However, they are a good example of what end users are seeing in terms of extensions that add desired functions to the Internet mail system.
The Format of Mail Messages
SMTP, POP, and (to a great extent) IMAP ignore the contents of a message. SMTP uses its own control information to find the recipient of a message; POP and IMAP retrieve messages based on user account names, which may or may not correspond to the address in a message. In users minds, however, the contents of the messages they read are almost always much more important than the way that the message got to them.
Mail messages consist of two parts: the headers and the body . The headers come first, followed by a blank line, followed by the body, as shown in Figure 3. The basic structure of messages has remained unchanged since it was defined in RFC 822. Originally, the headers were designed to look like inter-office memos, and also to contain control and debugging information; today, some parts of the headers are considered to be as important as the body of the message.
Because they were designed to be functional, message headers have a very straight-forward design. Each header has a single token, followed by a colon, followed by the parameters and options of the header. Headers usually consist of a single line, but you can create multi-line headers by starting the continuation lines with blanks.
There are dozens of common headers, and dozens more that are rarely used. Almost all mail users are familiar with "To:", "From:", "Subject:", and "Date:", and they may have seen additional common headers such as "Cc:" and "Received:". Depending on the interface of the MUA, users typically see some of these headers after they have retrieved a message with POP or IMAP but before they have "opened"the message to see the message body.
Basic and Advanced Message Bodies
Originally, the body of mail messages consisted of plain ASCII text. This was sufficient for the inventors of e-mail, who spoke mostly English and had access to other information transfer mechanisms such as FTP to move binary data around. Of course, such restrictions would not last.
Probably the biggest advance in Internet mail in the past ten years is in the format of mail messages, not in their transport. In the early 1990s, Internet mail went from being text-only to allowing the transfer of non-text messages and parts of messages. MIME, described in RFCs 2045-2047 [7, 8, 9], revolutionized the usefulness of Internet mail by allowing senders to include files with messages, to use styled text, to give their messages useful structure, and to provide the first interoperable support for international e-mail.
Unfortunately, the term "attachments" became associated with MIME even though it is much more powerful than just allowing files to be attached to a message. The majority of MIME-enabled messages today don't contain any attachments: instead, they use MIME's capability of labeling the type of a single message body part. MIME labeling can tell the receiving client the format of the message (for instance, an HTML message) and, if it is a text message, the type of characters in the message.
Another great feature of MIME is that it allows messages to have structure. For instance, Figure 4 shows a message with two representations of the same information: text and HTML. A mail client that cannot display HTML can skip that part of the message and just display the plain text. This allows message content to gradually migrate towards new technology. In the near future, it is likely that similar logic will be used for messages that contain XML, HTML, and plain text.
Because of the capability to structure messages, MIME can be used for multimedia and unified messaging. A single mail message can contain one or more movies, sound files, text files in a variety of formats, binary files such as word processing documents, calendar events, fax images, and so on. The MIME structure tells the recipient software which parts of the message contain particular types of data, as well the relationship between the parts (such as "this part contains three different alternative sound formats".
With the explosion of the popularity of the Web, users have come to expect that the content they read will look like Web pages. Most users don't understand that a "Web page" that "contains" graphics in fact isn't a single entity but is really a page of HTML that has links to other pages that contain individual images. They expect to be able to receive mail messages that look just like the things they see on the Web. The MHTML protocol (described in RFC 2557 ) describes how to structure MIME messages that contain both HTML parts and images so that they appear together in mail clients exactly like they appear in Web browsers.
MIME enables a plethora of other uses for e-mail. For example, secure e-mail using S/MIME and PGP uses MIME to structure the messages so that the cryptographic control information is separate from the message itself. For instance, in a digitally-signed message, the signature information (which is unreadable to the human recipient) is in a different part of the structure than the human-readable content. You can even have layers of encryption and signatures, all structured through MIME.
Internationalization of E-mail
You can use character sets other than ASCII in both the headers and body of Internet e-mail messages. Using different character sets in text bodies requires the use of the "charset" parameter in the "Content type:" header, as described in RFC 2046 . You can also use character sets in message headers with the methods described in RFC 2047 .
The Future of E-mail
E-mail is incredibly popular with Internet users, but it is far from finished. The next billion new e-mail users will most likely be much less technically savvy than today's Internet users, and they will come to the Internet with very different expectations. In order to give these users a more pleasant experience, the Internet mail industry will have to add many new features and make mail clients easier.
The number of ISPs is also increasing, although not as fast as the number of Internet users. Since e-mail is such an integral part of the service that an ISP offers, mail server software will also have to become easier to administer. Internet mail server vendors are working on such enhancements as a way of gaining a competitive advantage.
The most major change that users will see in the next few years are more highly enabled MUAs. These clients will be all-in-one messaging centers that will handle faxes, voice messages, paging, calendar and event management, and probably some sort of instant messaging. In this way, traditional mail will be only one part of what the user sees when they go to their messaging client.
The importance of Internet fax should not be underestimated. The recent standards for Internet fax, defined in RFCs 2301-2306 [11, 12, 13, 14, 15, 16] specify how faxes go through Internet mail. Although there have been a raft of proprietary real-time fax proposals, fax vendors have rallied around faxes in e-mail as an easy way to transition from fax over phone lines. Comparing the high cost of sending international faxes to the near zero cost of sending e-mail, many companies are quickly moving towards the new standards.
Other mail-enabled services are becoming standardized as well. For example, calendaring over Internet mail is nearing completion. This will allow users to coordinate schedules for meetings, even with people who are not online. E-mail fall-back for phone conversations that were not completed is also being researched.
The e-mail world five and ten years from now will not necessarily look completely different from the way it looks today. Certainly, there will be many more enriched text and multimedia messages being composed by end users. Mailing lists will grow and the mail on them will be more like Web pages than today's text messages. Many people predict that the face of e-mail will change radically if e-mail becomes the "universal inbox" for voicemail, faxes, and other types of communication. Many companies are discovering that regular newsletters sent through e-mail are more effective than expecting users to come to a web site regularly, and it is likely that there will be an increase in the number of publications that are delivered as e-mail.
There is still plenty of room for additions to Internet mail that resemble today's non-Internet services. For instance, users are already clamoring for features such as true message tracking, which is currently available from many package delivery services. Better security is clearly desired, although there seems to be major impediments caused by the need for trusted certificates before we can see wide deployment of secure mail. More problematic features such as message rescinding also have been proposed.
Forces outside the Internet mail world will also change how Internet mail works. For instance, the rapid increase in wireless users will change the way that large messages are handled by message stores. As more users start reading their mail from more than one system, IMAP may become more popular. At the same time, users will expect to be able to move their configuration information with them from machine to machine, probably using protocols such as the Application Configuration Access Protocol (ACAP) defined in RFC 2244 .
There are plenty of opportunities in the Internet mail market. The only significant dark cloud is the possibility that increasing unsolicited e-mail so called "spam" might scare away users. To date, the technical solutions for battling spam have been limited, and they probably won't scale well if the amount of spam increases by an order of magnitude. On the bright side, it appears that most legitimate marketers have been scared away from spam and are focusing on opt-in e-mail marketing. This could be a boon for ISPs who specialize in bringing interested e-mail users and potential advertisers together.
In such an environment, mail with rich media and lots of convenience could become the place where many users want to spend much of their time. To get there, we need to build on today's well-established mail protocols and to be creative in the kinds of features we add to both the transport and display of e-mail. Fortunately, we don't need to do much with SMTP, IMAP, and MIME in order to bring these new capabilities to the burgeoning numbers of new users waiting to get on the Internet.
 Crocker, D., "Standard for the format of ARPA Internet text messages," RFC 822, August 1982.
 Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D., "SMTP Service Extensions," RFC 1865, November 1995.
 Myers, J., "SMTP Service Extension for Authentication," RFC 2554, March 1999.
 Moore, K., "SMTP Service Extension for Delivery Status Notifications," RFC 1891, January 1996.
 Myers, J. and Rose, M., "Post Office Protocol-Version 3," RFC 1939, May 1996.
 Crispin, M., "Internet Message Access Protocol-Version 4rev1," RFC 2060, December 1996.
 Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies," RFC 2045, November 1996.
 Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part Two: Media," RFC 2046, November 1996.
 Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text," RFC 2047, November 1996.
 Palme, J., Hopmann, A., Shelness, N., "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)," RFC 2557, March 1999.
 McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G., Rafferty, J., "File Format for Internet Fax," RFC 2301, March 1998.
 Parsons, G., Rafferty, J., Zilles, S., "Tag Image File Format (TIFF)- image/tiff MIME Sub-type Registration," RFC 2302, March 1998.
 Allocchio, C., "Minimal PSTN address format in Internet Mail," RFC 2303, March 1998.
 Allocchio, C., "Minimal FAX address format in Internet Mail," RFC 2304, March 1998.
 Toyoda, K., Ohno, H., Murai, J., Wing, D., "A Simple Mode of Facsimile Using Internet Mail," RFC 2305, March 1998.
 Parsons, G., Rafferty, J., "Tag Image File Format (TIFF)-F Profile for Facsimile," RFC 2306, March 1998.
 Newman, C., Myers J. G., "ACAP-Application Configuration Access Protocol," RFC 2244, November 1997.
 Poor Richard's E-mail Publishing, by Chris Pirillo, ISBN 0966103254, Top Floor Publishing, 1999.
 Internet Messaging: From the Desktop to the Enterprise, by Marshall T. Rose and David Strom, ISBN 0-13-978610-4, Prentice Hall PTR, 1998.
 Essential Email Standards: RFCs and Protocols Made Practical, by Pete Loshin, ISBN 0-471-34597-0, Wiley, 1999.
 Internet Email Protocols: A Developer's Guide, by Kevin Johnson, ISBN 0-201-43288-9, Addison-Wesley, 1999.
PAUL HOFFMAN is the director of the Internet Mail Consortium (http://www.imc.org/ ) , which is the trade association for Internet mail software vendors and service providers. He is the editor of many recent mail standards, as well as Internet-related books such as Netscape For Dummies. He has been active on the Internet for twenty years. E-mail: email@example.com