Early Stages of TCP/IP

In the late 70's and early 80's, while ARPANET was beginning to become what would be known as the Internet, email was a very popular, albeit chaotic, application. Popular because it was quickly seen as a communications technology that would revolutionize the way people around the world exchanged ideas and chaotic because it was implemented by countless proprietary email technologies that could not interact with each other. It was quickly discerned that a protocol was needed to truly make email technology a universal way to exchange ideas.

The Development of Simple Mail Transfer Protocol (SMTP)

The Simple Mail Transfer Protocol was developed to be a reliable, efficient, and universal way to transport mail. The SMTP model is made up of two elements: mail transfer agents (MTAs) and user agents (UAs).

The mail transfer agent has two tasks:

• to send and receive messages from other mail transfer agents
• to interface with user agents

The user agent also has two tasks:

• to interface with mail transfer agents
• to provide a user friendly environment, shielding the user from the implementations of SMTP.

Through this model, the creators of SMTP had achieved a universal implementation. Because data is sent over TCP, they assured that it would be a reliable one as well.

So universal mail transport was achieved, although not perfectly. SMTP was not designed to handle two critical issues:

1. SMTP can only transport 7-bit data. When SMTP was designed, the only realistic use for it was to transfer plain ASCII text, which is 7-bit data. As a result, MTAs were all implemented to carry this form of data. This would cause some problems in the future with the advent of multimedia and the preponderance of 8-bit data (see MIME topic).
2. SMTP cannot queue messages at the receiving end. As a result, the mail server and associated local mail delivery system were needed to be resident and running at all times on the client. Most smaller computers, which were in the midst of an explosion in use, lacked the resources to have the mail delivery system resident and running. Multiple sustained connections were taking their toll on the mail servers as well. All this would necessitate the addition of new protocols in the future to handle the receiving of mail.

More info about the SMTP Protocol is available in the SMTP Protocol topic.

The Development of Post Office Protocol (POP)

Simple Mail Transfer Protocol succeeded in implementing universal, reliable, and efficient email transfer. However, the lack of a final "pick up" point resulted in sustained connections. Post Office Protocol (now in its third version and commonly called POP3) was implemented to provide a common system for queuing and delivering mail to the user agent. This protocol called for the creation of a "maildrop" on the mail server, in which mail, delivered by SMTP, would be placed and held for pickup by the recipient. POP basically works by allowing a user agent to interface with the mail drop. This interfacing takes the form of logging in, downloading messages, and logging out. The implementation of POP was a success as it required that the entire mail transfer system not always be connected and resident. The combination of SMTP and POP worked well, but was not perfect. Still missing was the ability to transfer non-ASCII data and a sophisticated way to manipulate email on the server. Solutions to these problems were found in the development of Multipurpose Internet Mail Extensions (MIME) and Internet Message Application Protocol (IMAP).

More info about the POP protocol is available in the POP Protocol topic.

The Development of Multipurpose Internet Mail Extensions (MIME)

The development of MIME was necessary because the ability to send only 7-bit ASCII text was extremely limiting, especially with the advent of multimedia files. Sending other, non-ASCII files was a challenge, as most of these file types in their natural state are 8-bit files. You may recall that mail transfer agents only have the ability to transfer 7-bit data. MIME specified a new way to structure messages, as well as algorithms to encode the 8-bit data so that non-ASCII files could be transported.

More info about the MIME is available in the MIME Overview topic.

The Development of Internet Message Application Protocol (IMAP)

POP, while useful in its current function, still was lacking in several areas. POP did not allow for email manipulation while it was still on the server, or for accessing mail from more than one computer (with POP, once messages are downloaded, they are deleted from the mail server and a single copy remains on the local machine). IMAP allows messages to be manipulated through the use of "mailboxes" on the server which are functionally equivalent to folders or directories. The user agent has the ability to create, delete, and rename mailboxes, as well as to move email into different mailboxes, download email, and delete email. Since the email remains on the mail server, IMAP also allows access from different computers. IMAP clearly is a more sophisticated protocol than POP but not all mail servers support IMAP, so POP is still very prevalent today.

More info about the IMAP protocol is available in the IMAP4 Protocol topic.

Internet Email Model Today

Today's email model is a hybrid of SMTP, POP, IMAP, and MIME (as well as many other technologies). SMTP is used to send messages, POP is used to queue messages on the receiver mail server for downloading, IMAP is used to store messages on the receiver's mail server for server side manipulation, and MIME specifies a method of sending non-ASCII data. The following diagram illustrates this: