Electronic mail (or e-mail) was one of the earliest applications on the Internet and is still among the most heavily used today. With e-mail, users create and send messages to one user, several users, or all users on a distribution list. Most e-mail software enables users to send text messages and attach files from word processors, spreadsheets, graphics programs, and so on. Many e-mail packages also permit you to filter or organize messages by priority.
Several standards have been developed to ensure compatibility between different e-mail software packages. Any software package that conforms to a certain standard can send messages that are formatted using its rules. Any other package that understands that particular standard can then relay the message to its correct destination; however, if an e-mail package receives a mail message in a different format, it may be unable to process it correctly. Many e-mail packages send using one standard but can understand messages sent in several different standards. The most commonly used standard is SMTP (Simple Mail Transfer Protocol). Other common standards are X.400 and CMC (Common Messaging Calls). In this topic, we will discuss only SMTP, but CMC and X.400 both work essentially the same way. SMTP, X.400, and CMC are different from one another (in the same way that English differs from French or Spanish), but several software packages are available that translate between them, so that companies that use one standard (e.g., CMC) can translate messages they receive that use a different standard (e.g., SMTP) into their usual standard as they first enter the company and then treat them as "normal" e-mail messages after that.
How E-mail Works
The Simple Mail Transfer Protocol (SMTP) is the most commonly used e-mail standard simply because it is the e-mail standard used on the Internet.2 E-mail works similarly to how the Web works, but it is a bit more complex. SMTP e-mail is usually implemented as a two-tier thick client-server application, but not always. We first explain how the normal two-tier thick client architecture works and then quickly contrast that with two alternate architectures.
Two-Tier E-mail Architecture With a two-tier thick client-server architecture, each client computer runs an application layer software package called a mail user agent, which is usually more commonly called an e-mail client (Figure 2.11). There are many common e-mail client software packages such as Eudora and Outlook. The user creates the e-mail message using one of these e-mail clients, which formats the message into an SMTP packet that includes information such as the sender’s address and the destination address.
The user agent then sends the SMTP packet to a mail server that runs a special application layer software package called a mail transfer agent, which is more commonly called mail server software (see Figure 2.12).
This e-mail server reads the SMTP packet to find the destination address and then sends the packet on its way through the network—often over the Internet—from mail server to mail server, until it reaches the mail server specified in the destination address (see Figure 2.12). The mail transfer agent on the destination server then stores the message in the receiver’s mailbox on that server. The message sits in the mailbox assigned to the user who is to receive the message until he or she checks for new mail.
The SMTP standard covers message transmission between mail servers (i.e., mail server to mail server) and between the originating e-mail client and its mail server. A different standard is used to communicate between the receiver’s e-mail client and his or her mail server. Two commonly used standards for communication between e-mail client and mail server are Post Office Protocol (POP) and Internet Message Access Protocol (IMAP).
Figure 2.12 How SMTP (Simple Mail Transfer Protocol) e-mail works. IMAP = Internet Message Access Protocol; LAN = local area network
Although there are several important technical differences between POP and IMAP, the most noticeable difference is that before a user can read a mail message with a POP (version 3) e-mail client, the e-mail message must be copied to the client computer’s hard disk and deleted from the mail server. With IMAP, e-mail messages can remain stored on the mail server after they are read. IMAP therefore offers considerable benefits to users who read their e-mail from many different computers (e.g., home, office, computer labs) because they no longer need to worry about having old e-mail messages scattered across several client computers; all e-mail is stored on the server until it is deleted.
In our example in Figure 2.12, when the receiver next accesses his or her e-mail, the e-mail client on his or her computer contacts the mail server by sending an IMAP or POP packet that asks for the contents of the user’s mailbox. In Figure 2.12, we show this as an IMAP packet, but it could just as easily be a POP packet. When the mail server receives the IMAP or POP request, it sends the original SMTP packet created by the message sender to the client computer, which the user reads with the e-mail client. Therefore, any e-mail client using POP or IMAP must also understand SMTP to create messages and to read messages it receives. Both POP and IMAP provide a host of functions that enable the user to manage his or her e-mail, such as creating mail folders, deleting mail, creating address books, and so on. If the user sends a POP or IMAP request for one of these functions, the mail server will perform the function and send back a POP or IMAP response packet that is much like an HTTP response packet.
Host-Based E-mail Architectures When SMTP was first developed, host-based architectures were the rule, so SMTP was first designed to run on mainframe computers. If you use a text-based version of Linux or UNIX, chances are you are using a host-based architecture for your e-mail.
With this architecture, the client computer in Figure 2.12 would be replaced by a terminal that would send all of the user’s keystrokes to the server for processing. The server would then send characters back to the terminal to display. All software would reside on the server. This software would take the user’s keystrokes, create the SMTP packet, and then send it on its way to the next mail server.
Likewise, the receiver would use a terminal that would send keystrokes to the server and receive letters back to display. The server itself would be responsible for understanding the user’s commands to read a mail message and sending the appropriate characters to the user’s terminal so he or she could read the e-mail message. If you had been wondering why the SMTP standard does not include the delivery of the message to the receiver’s client computer, you should now understand. Because no software existed on the receiver’s terminal, the SMTP standard did not include any specification about how the receiver’s mail server software should display messages. Communication between the mail server and the receiver’s terminal was left to the e-mail software package running on the server. Because each package and each terminal was different, no standards were developed to cover communication between the terminal and the server.
Three-Tier Thin Client-Server Architecture The three-tier thin client-server e-mail architecture uses a Web server and Web browser to provide access to your e-mail. With this architecture, you do not need an e-mail client on your client computer. Instead, you use your Web browser. This type of e-mail is sometimes called Web-based e-mail and is provided by a variety of companies such as Hotmail and Yahoo.
You use your browser to connect to a page on a Web server that lets you write the e-mail message by filling in a form. When you click the send button, your Web browser sends the form information to the Web server inside an HTTP request (Figure 2.13). The Web server runs a program (written in C or Perl, for example) that takes the information from the HTTP request and builds an SMTP packet that contains the e-mail message. Although not important to our example, it also sends an HTTP response back to the client. The Web server then sends the SMTP packet to the mail server, which processes the SMTP packet as though it came from a client computer. The SMTP packet flows through the network in the same manner as before. When it arrives at the destination mail server, it is placed in the receiver’s mailbox.
When the receiver wants to check his or her mail, he or she uses a Web browser to send an HTTP request to a Web server (see Figure 2.13). A program on the Web server (in C or Perl, for example) processes the request and sends the appropriate IMAP (or POP) request to the mail server. The mail server responds with an IMAP (or POP) packet, which a program on the Web server converts into an HTTP response and sends to the client. The client then displays the e-mail message in the Web browser.
Figure 2.13 Inside the Web. HTTP = Hypertext Transfer Protocol; IMAP = Internet Message Access Protocol; LAN = local area network; SMTP = Simple Mail Transfer Protocol
A simple comparison of Figures 2.12 and 2.13 will quickly show that the three-tier approach using a Web browser is much more complicated than the normal two-tier approach. So why do it? Well, it is simpler to have just a Web browser on the client computer rather than to require the user to install a special e-mail client on his or her computer and then set up the special e-mail client to connect to the correct mail server using either POP or IMAP. It is simpler for the user to just type the URL of the Web server providing the mail services into his or her browser and begin using mail. This also means that users can check their e-mail from a public computer anywhere on the Internet.
It is also important to note that the sender and receiver do not have to use the same architecture for their e-mail. The sender could use a two-tier client-server architecture, and the receiver, a host-based or three-tier client-server architecture. Because all communication is standardized using SMTP between the different mail servers, how the users interact with their mail servers is unimportant. Each organization can use a different approach.
In fact, there is nothing to prevent one organization from using all three architectures simultaneously. At Indiana University, we usually access our e-mail through an e-mail client (e.g., Microsoft Outlook), but we also access it over the Web because many of us travel internationally and find it easier to borrow a Web browser with Internet access than to borrow an e-mail client and set it up to use the Indiana University mail server.
SMTP Transmission
TECHNICAL FOCUS
SMTP (Simple Mail Transfer Protocol) is an older protocol, and transmission using it is rather complicated. If we were going to design it again, we would likely find a simpler transmission method. Conceptually, we think of an SMTP packet as one packet. However, SMTP mail transfer agents transmit each element within the SMTP packet as a separate packet and wait for the receiver to respond with an ”OK” before sending the next element.
For example, in Figure 2.14, the sending mail transfer agent would send the from address and wait for an OK from the receiver. Then it would send the to address and wait for an OK. Then it would send the date, and so on, with the last item being the entire message sent as one element.
Inside an SMTP Packet
SMTP defines how message transfer agents operate and how they format messages sent to other message transfer agents. An SMTP packet has two parts:
• The header, which lists source and destination e-mail addresses (possibly in text form [e.g., "Pat Smith"]) as well as the address itself (e.g., psmith@ somewhere.com), date, subject, and so on.
• The body, which is the word DATA, followed by the message itself.
Figure 2.14 shows a simple e-mail message formatted using SMTP. The header of an SMTP message has a series of fields that provide specific information, such as the sender’s e-mail address, the receiver’s address, date, and so on. The information in quotes on the from and to lines is ignored by SMTP; only the information in the angle brackets is used in e-mail addresses. The message ID field is used to provide a unique identification code so that the message can be tracked. The message body contains the actual text of the message itself.
Figure 2.14 An example of an e-mail message using the SMTP (Simple Mail Transfer Protocol) standard
Listserv Discussion Groups
A list server (or Listserv) group is simply a mailing list of users who have joined together to discuss some topic. Listserv groups are formed around just about every topic imaginable, including cooking, skydiving, politics, education, and British comedy. Some are short lived, whereas others continue indefinitely. Some permit any member to post messages; others permit only certain members to post messages. Most businesses have Listservs organized around job functions, so that it is easy to reach everyone in a particular department.
There are two parts to every Listserv. The first part, the Listserv processor, processes commands such as requests to subscribe, unsubscribe, or to provide more information about the Listserv. The second part is the Listserv mailer. Any message sent to the Listserv mailer is resent to everyone on the mailing list. To use a Listserv, you need to know the addresses of both the processor and the mailer.
To subscribe to a Listserv, you send an e-mail message to the Listserv processor, which adds your name to the list (see "Listserv Commands" for the message format). It is important that you send this message to the processor, not the mailer; otherwise, your subscription message will be sent to everyone on the mailing list, which might be embarrassing.
For example, suppose you want to join a Listserv on widgets that has a processor address of listerv @abc.com, and the mailer address is widget-1 @abc.com. To subscribe, you send an e-mail message to listerv @abc.com containing the text: subscribe widget-1 your name. To send a message to everyone on this Listserv, you would e-mail your message to widget-1 @abc.com.
Attachments in Multipurpose Internet Mail Extension
As the name suggests, SMTP is a simple standard that permits only the transfer of text messages. It was developed in the early days of computing, when no one had even thought about using e-mail to transfer nontext files such as graphics or word processing documents. Several standards for nontext files have been developed that can operate together with SMTP, such as Multipurpose Internet Mail Extension (MIME), uuencode, and binhex.
Each of the standards is different, but all work in the same general way. The MIME software, which exists as part of the e-mail client, takes the nontext file such as a Power-Point graphic file, and translates each byte in the file into a special code that looks like regular text. This encoded section of "text" is then labeled with a series of special fields understood by SMTP as identifying a MIME-encoded attachment and specifying information about the attachment (e.g., name of file, type of file). When the receiver’s e-mail client receives the SMTP message with the MIME attachment, it recognizes the MIME "text" and uses its MIME software (that is part of the e-mail client) to translate the file from MIME "text" back into its original format.
Listserv Commands
TECHNICAL FOCUS
There are many different commands that can be sent to the Listserv processor to perform a variety of functions. These commands are included as lines of text in the e-mail message sent to the processor. Each command must be placed on a separate line. Some useful commands include
• SUBSCRIBE: listserv-mailer-name your-name: Subscribes you to a mailing list (e.g., subscribe maps-1 robin jones)
• UNSUBSCRIBE: listserv-mailer-name your-name: Unsubscribes you from the mailing list (e.g., unsubscribe maps-1 robin jones)
• HELP: Requests the Listserv to e-mail you a list of its commands
• LIST: Requests the Listserv to e-mail you a list of all Listserv groups that are available on this Listserv processor
• LIST DETAILED: Requests the Listserv to e-mail you a detailed description of all Listserv groups that are available on this Listserv processor and are public
