A non-technical overview of the basic concepts and common conventions of electronic mail (E-mail) including:
• Elements of a message
• MIME
• User Agents
• Message Transport Agents
• Addressing protocols
· The Postmaster
• Directory services
This chapter is not about the Post.Office mail system; rather, it is a brief introduction to some of the basic concepts that apply to most E-mail systems. It will be useful if you are new to the world of E-mail administration.
A more specific discussion of Post.Office follows in the next chapter, so if you already know what E-mail is and what kinds of programs comprise a mail system you may want to skip ahead.
E-mail is all about messages; that is, E-mail provides a way for two or more people to exchange messages. Just as the postal service is used to send postcards, letters, and magazines, E-mail is used to send various kinds of messages. An electronic message can range from a simple memo or letter to a complex multimedia presentation designed to overload and delight your senses. Regardless of its content, the message is the fundamental currency of electronic mail.
The most rudimentary method of leaving a message for someone who uses a computer is to tape a hand-written note on their monitor. The next step, an electronic message in its most basic form, occurs when you type a few words in an open window on the computer screen hoping the next person who comes along will find it. This basic electronic message system works if nobody else needs to use that particular computer and if you don't mind leaving the computer and monitor on.
However, if more than two people are using this computer, then the electronic message must be stored (as a file on a disk) until the recipient comes along. Only when the message is safely put in a file can the computer be used for other purposes, employed by other users, or shut off. As long as the two users who wish to communicate agree upon a common file where they will store messages and responses for each other, this system works.
However, using a large, single file is clumsy. Users may elect to agree upon a directory rather than a large single file, in which to store messages. Each message could then be stored as an individual file with a descriptive file name. Even so, a large volume of messages between several users can fill up a directory awfully fast, and it can become difficult to make heads or tails out of the resultant mess.
When confronted with a large number of message files, it would be nice to know several things about the message without opening the file, such as: who a message is for, what it's about, and when it was sent. If more than two users share this system, it's also useful to know who a message is from before reading it.
Historically, postal mail solved this problem of message organization with various conventions of encapsulation. Envelopes tell you who sent them. Letters almost invariably start off with an indication of who they're for. Often other information, such as where the letter was written and what the letter is about precede the main body of the message. In this manner encapsulation allows mail to be processed efficiently.
An envelope includes only the necessary information for the postal service to deliver a message (as well as a return address in the event a message cannot be delivered). Once a message is delivered, the header information (that is, any information that precedes the body of the message) allows recipients to sort and prioritize their mail before taking the time to examine the body of the message.
The headers which encapsulate the body of E-mail messages allow not only recipients, but the programs that serve them to process messages expediently.
Corporations and other institutions have long used messages (often called memos) that have key pieces of information laid out in a series of headers at the beginning of the message (see Figure 1-1). Header information allows institutional mail services to deliver memos and gives memo recipients an initial idea of what the message is about before delving into the full content.
To: Jane D. From: John S. Subject: Toga contract termination Date: July 27, 1994 ------------------------------------------------------------------- Jane, I have decided to terminate our contract with the Toga company. The togas don't seem to convey the corporate image which we require. Let's meet at 3:30 to discuss the details. OK? John
Headers can be just as effective in managing a gaggle of electronic messages jumbled up in a directory. One can make sense of a message file only by opening it and checking the header information to see who a message is for, what it's about, who sent it, and when. This is tedious work. Fortunately, the dull, tedious, and repetitive work of opening a large number of message files and examining their headers is exactly the kind of thing that computers are good at.
As long as headers are consistently formatted, an E-mail program can easily scan through a pile of messages and find all the messages that begin with, for example, the line
"To: Jane." Similarly, if other header information indicates when messages were written, a computer can organize these messages and present them to Jane in chronological order.
The key to headers as far as computers are concerned is that they be absolutely consistent. E-mail interoperability depends on an agreement (or standard protocol, as the people working on such things like to call agreements) for the formatting of the headers. While different E-mail systems do things differently, all have some kind of header information; and for two systems to be interoperable, any differences must be eliminated or somehow resolved.
It is the tight regulation of the use and format of headers which allows users with disparate E-mail programs to send each other electronic mail. At the same time headers provide users with valuable information about their E-mail.
Just as the body of a letter tends to make up the bulk of traditional postal mail, in general the body makes up the bulk of an E-mail message. While users must cater to the needs of computers and programs when writing headers, there are no such restrictions on the body of a message. As a result, the body of an E-mail message tends to look a lot like the body of a postal letter.
Although often limited to the rather rudimentary ASCII character set, newer and more sophisticated electronic mail programs are increasingly allowing users to send each other elaborately formatted text and graphics, sound, and even video clips (multimedia). The more complex the message medium, the larger the amount of data that must be transferred when a message is sent from one user to another. In some systems sending a large, complex file can create a bottleneck, a sort of traffic jam on the information highway. As increasing bandwidth allows larger data streams on networks, E-mail users will be able to make more and more use of data-intensive E-mail features.
One example of how multimedia is used in E-mail is a system called MIME: Multi-Purpose Internet Mail Extension.
MIME: Multipurpose Internet Mail Extensions
Back in the days when people were still relieved about not having to use punch cards any more, people thought that sending each other any kind of text message was pretty cool.
E-mail evolved without any allowances for multimedia: video and audio files, or even rich text, the highly formatted text with bold, italics, and all the other spiffy stuff we've gotten used to since the word-processor consigned the typewriter to the trash can and a few obstinate technophobe hold-outs.
In order to incorporate multimedia into the Simple Mail Transfer Protocol (SMTP), which is currently the most common existing E-mail protocol, a new protocol, called MIME (Multipurpose Internet Mail Extension) was developed, which allows you to incorporate anything from a recording of your newborn's voice to a short movie in an
E-mail message.
As long as both parties have MIME-enabled E-mail programs (not all E-mail programs support MIME), people can exchange any kind of multimedia file they want by simply appending the file to their message. Since multimedia is still in the early stages, you should check to make sure that someone has MIME before you send them a pile of stuff.
I described previously how formatted headers allow E-mail programs to sort through messages and present important information to the user. When delivering a message from one user to another, however, an E-mail program only needs to know two things:
• where a message is going, and
• who it was from, in case it needs to be returned.
This information is used to create an envelope, which is directly analogous to a postal envelope: both are labeled with "to" and "from" addresses and contain the message (header and body) within.
Only programs use envelopes. All users ever get to see are the headers and body of a message. Still, it's good to know that envelopes exist in case we ever need to really pin down an ontological definition of E-mail.
User Agents are programs which assist users in carrying out all tasks related to electronic mail. These include creating and submitting messages for delivery, checking for new incoming mail, reading received messages, and organizing the volumes of saved messages generated by high usage. The user agent is the only element in the maze of networks and E-mail handling programs with which most users have any contact (see Figure 1-2).
Figure 1-2 A User Agent is the only E-mail program with which most users have
any contact (network not shown to scale).
If you ask users what E-mail program they use, they will generally tell you the name of their user agent. This is because it takes care of most of the tasks required to send and receive messages. Other tasks are delegated to programs which are hidden from the user.
In its simplest form, a user agent is a program which allows you to create a text message for another person which can be read by the other person with the help of a similar program. User agents which can send and receive graphics and multimedia work along the same lines as their simpler cousins. While all user agents can handle plain text messages, the exchange of complex multimedia messages requires that the user agents follow an agreed upon standard format for the body of such messages. One of the most successful such formats is the Internet standard known as MIME which was described earlier.
To create a new E-mail message, users agents frequently provide users with a template, so that users need only fill in the blanks in order to complete the headers. User agents leave the body blank, so that users can fill it in as they please. The user agent operates in this manner as a more or less sophisticated word processor and most offer at least minimal editing functions. Once a message is complete, the user agent will forward the message to a more specialized E-mail program (a message transport agent) for delivery.
Together, these editing features allow users to include any amount of supplementary textual (and often multimedia) information in their messages.
Generally user agents list incoming messages on a menu or in a window which may be called, for example, the "In Box." Often this list indicates who the message is from, when it was sent, and what the subject of the message is. (This information is retrieved from the message headers by the user agent.) Users select the message they wish to read, and it is displayed for them on the monitor. (Junk mail you throw away without reading, just like you already do with postal mail; but for once it doesn't end up in a landfill.)
Frequently users will want to save messages that they may need to look at again at a later date. Rather than maintain a single directory filled with a random assortment of messages, many user agents help users organize their messages into a set of directories or mailboxes, so that messages can be organized by subject or according to whatever taxonomy the user prefers.
In today's world of huge networks connecting bazillions of users, user agents are not up to the task of transferring messages to their recipients. This task is relegated to specialized programs called message transport agents (which are described in Section 1.4).
To send a message, a user agent only needs to give it to a message transport agent. This generally requires only a single command on the part of the user. The message is whisked away across the networks. As long as networks are functioning correctly, a message can be delivered around the world in a matter of seconds.
|
|
User agents can receive messages in a couple of different ways. One option is to have the message transport agent place messages directly into a specific directory (on the same computer as the message transport agent, but in the user's directory). This directory functions as the user's mailbox. In this case the user agent consults this directory any time that a user asks it to check for mail. Any messages found in this directory are retrieved and listed for the user. This type of delivery is often used on UNIX machines. |
A second and increasingly popular method of message delivery is directly supervised by the message transport agent. Rather than place incoming messages in a mailbox for the user, the message transport agent itself acts as a mailbox, and holds onto messages until the user checks for mail. When the user does this (remember, the user probably doesn't even know that he has a message transport agent secretly working on his behalf), he uses the check mail command on his user agent, and the user agent checks with the message transport agent. If the message transport agent has any messages for that user, they are made available to the user agent, which in turn makes them available to the user. This second method employs the Post Office Protocol (POP).
The advantage of the POP delivery method is that it does not require that the message transport agent have access to the user's mailbox directory. This is advantageous in today's networked environment where more and more often the user agent and the message transport agent are located on different computers. In this case, the message transport agent is at the disposal of the user agent, which contacts it when it wants to send out a message or check for mail (see Figure 1-3).
Figure 1-3 Often, when the user agent and the message transport agent are located on two different computers, the message transport agent does not deliver messages until the user agent checks for mail.
A Message Transport Agent (MTA) is a specialized program designed to deliver messages across today's increasingly large networks. MTAs generally interact with other programs -- primarily user agents and other MTAs -- rather than with users. The most common task which message transport agents carry out is to accept a message from one user agent and deliver it to another.
Post.Office is an MTA.
Late at night, in post offices around the globe, thousands of insomniacs sort through mountains of bills, catalogs, and coupon mailers, so that in the morning postal carriers can deliver these missives to our doors. If we think of a user agent as a personal secretary who helps us write our messages, we can liken message transport agents to the thousands of letter-sorters and others who work behind the scenes to ensure that we get our mail.
Message transport agents are daemon programs, which means that they are running 24 hours a day, ready and anxious to serve. When a user agent (or another MTA) wants to give a message to an MTA, it contacts it and gives it the message. In contrast, user agents are usually only active when a user is interested in writing, sending, receiving, or perusing her E-mail.
When messages need to travel between user agents, it is commonly one or more message transport agents that carry out the task. Figure 1-4 illustrates how MTAs such as Post.Office and sendmail transport messages between user agents such as Eudora and Pine:
Figure 1-4 In a direct transmission, a message is forwarded between the two MTAs
If a message must travel from a writer at Software.com to his brother who is attending the University of Washington, the writer and his user agent create a message together. The user agent then gives the message to the MTA at Software.com. This MTA then forwards the message to another MTA at the University of Washington, and this second MTA then delivers the message to the writer's brother. Broken down, this process consists of five steps, shown in Figure 1-5. Sometimes a message must be relayed by an intermediate MTA. In such a case it would be handled by three (or more) MTAs: one MTA that accepts the message from a user agent, another that relays it, and the last MTA which delivers it to the recipient's user agent. (In such a case, Step 3 of Figure 1-5 would be repeated one or more times):
1. User to UA (sender creates message)
2. UA to MTA (message forwarded)
3. MTA to MTA (message forwarded)
4. MTA to UA (message forwarded)
5. UA to user (recipient reads message)
We know that when mail is placed in a postal mail box, its next stop is a post office. There it is sorted and a forwarding decision is made. For local mail this may mean putting the letter in a mail delivery person's mail pouch, while mail destined for a distant city may require that the process of sorting and forwarding be repeated several times at various post offices in different cities along the way.
This is the same method that is used in E-mail delivery. As an E-mail message travels from one user agent to another via one or more message transport agents, decisions are made as to the routing of the message at each step along the way. Using the addressing information provided on the electronic "envelopes", MTAs sort through messages and make decisions about where to forward them. In some cases a message needs to be sorted only once and can then be forwarded directly to its recipient. In other cases this process must be repeated several times along the way.
All MTAs are daemons waiting for other E-mail programs to contact them and give them a message. The conversation can look something like the illustration shown in Figure 1-6. Like all E-mail transactions, the conversation is a client/server transaction, a kind of call and response conversation where one computer asks for something and another provides it. In this case the MTA that is accepting the message is a server, while the client that is transmitting the message could be a UA or another MTA.
Hello this is Computer1 (UA or MTA) >>> Hello this is Computer2 (MTA) I want to send you a message from Bob >>> OK It's for Jane >>> OK Here's the message, ending with our secret handshake >>> OK Data, data, ... data, secret handshake >>> Message received Good-bye. >>> Good-bye.
When an MTA places a message in a user's mailbox, it is simply creating and saving a file in the user's directory. The alternative is for the MTA to hold onto a message in a mailbox of its own until a user agent retrieves any accumulated messages from another computer. The MTA will again act as a server while the UA literally impersonates the recipient it is representing (Figure 1-7):
Hello? Anyone there? >>> Hi, this is your MTA This is Jane >>> Jane, your mailbox has 2 new messages Give me the first one >>> Data, data, data... secret handshake Give me the second one >>> Data, data, data... secret handshake Thanks, Got them. Good-bye >>>You're Welcome, Good-bye
Besides delivering a message to another MTA or to a UA, there are a couple of other ways that an MTA can deliver a message: to special programs or to an error handling routine.
In the first case an MTA can be told to deliver all messages addressed in such-and-such a way to a special program. This could be, for example, a mail sorting program or a mail list exploder. When it receives a message for this type of program, the MTA starts the program and gives it the message. Mail sorting programs are especially popular with people who receive large volumes of E-mail and want, for example, to separate personal messages from mailing list messages.
The second case involves the disposition of messages that the MTA cannot decide what to do with. While some MTAs reject such messages outright, others forward them to the Postmaster who must then decide what to do with them. An error handler is a program which assists the Postmaster in sorting through, responding to, and disposing of these "problem" messages.
A message transport agent accepts a message when it recognizes the address as a local address.
Often an MTA can function as a local post office for a network or a portion of a network. When used in this manner the MTA has a list of local recipients for whom it receives messages. This list translates, from the MTA's perspective, into a list of addresses which includes everybody in that MTA's "electronic neighborhood" (often a neighborhood like this is called a domain).
Often a single user will receive mail at multiple addresses, all of which the MTA funnels to that user's mailbox. The reason for having more than one address can stem from wearing several hats (so that a user may receive all the E-mail addressed to the Sales Department as well as to her own name) or simply because she wants it to be as easy as possible to get mail to her. E-mail programs are rather neurotic about how addresses are written. One way to compensate for this is to try to second guess how people will mess up your address; then you can tell the MTA that mail sent to any of these "guesses" is really meant for you. The specifics of E-mail addresses are illustrated in more detail below.
Addressing protocols are the key to allowing users and computers to contact each other across networks. This section describes addressing in general as well as providing some details on the most commonly used addressing protocol, the Domain Name System (DNS).
Back when there were only three channels to watch on television and computers were big enough to squash people, addressing systems were simple. You gave every computer a name, and then you compiled a list of those names and information about where each computer was. If you added a computer to your network you would add the name and location of the new computer to the address list maintained on every other computer on the network.
Nowadays there are too many channels on TV, and far, far too many computers on networks for lists like this to be maintained on each computer. Networks like the Internet are growing at exponential rates and there is simply no possible way for all computers to keep constant track of each other.
Addressing systems were developed to allow computers to find each other when they needed to, and these addresses are the key to today's electronic mail systems.
There are two common addressing systems (X.400 and DNS) which resolve the difficulty of providing addresses to millions of computers. Because DNS addresses are simpler (see Figure 1-8) and more common, we will describe DNS addressing in this section.
A Sample X.400 Address: /PN=SMITHJ/O=ORG/PRMD=COMPANY/ADMD=TELCOM/C=US A Sample DNS Address: Jane.Doe@Software.com
With the DNS each computer actually has two "names," one that is useful for people (a DNS address) and another that is better suited for computers (an IP address). For example, there is an entry in the DNS for a computer named chicago.software.com. The other name in the DNS that refers to this computer is [198.17.234.1]. This string of numbers is the computer's IP address (and is used almost exclusively by other computers).
The address chicago.software.com can be used to illustrate the hierarchical nature of the DNS. The right-most word (an abbreviation) indicates the type of organization (or sometimes the country) in which the computer is located. In this case the abbreviation com indicates a commercial organization.
Next comes the name of the organization which is unique within the com domain (for example, there is also a software.org, but there can be only one software.com). The name given to the computer is chicago.
Rules dictate there be only one organization named software in the com domain, and only one computer named chicago in the software.com domain. These rules ensure that each DNS address is unique.
In this way, a message that is addressed to Jane, who uses the computer chicago, could be addressed:
To: Jane@chicago.software.com
Larger organizations may decide to further divide their network by departments such as sales or support in order to keep track of what's what. Within such a scenario the address for chicago could be:
chicago.sales.software.com
Jane's address would become:
Jane@chicago.sales.software.com.
Although messages always travel from one computer to another when crossing a network such as the Internet, it is between users rather than computers that messages are addressed. Often specific computer names are not even included in the E-mail addresses people use. For example:
Jane@Software.com
This address indicates that the message is for Jane, who has some affiliation with the software.com domain. There is no computer with that name since software.com is the organization's domain name (the abbreviation com is always immediately preceded by the name of an organization). Yet the above address works because the DNS is a directory service, which allows computers to transform the above E-mail address into the address of a specific computer.
In order to deliver a message to Jane@Software.com, an E-mail program must determine the name of a computer that accepts mail for the software.com domain by asking the DNS. The DNS responds to this query by providing a list of computers that accept mail for that domain, one of which is chicago. The message is then sent to chicago.software.com where Jane will find it the next time she checks her mail.
There are a variety of reasons that you might want to assign users more than one address:
• You may want an address which indicates what department users are associated with in their organization.
• You may want both first name (casual) and last name (formal) addresses.
• You may want to include common misspellings as valid addresses just in case.
For all the aforementioned reasons, Jane Doe has all the following addresses registered as valid addresses:
Jane_Doe@Software.com
Jane.Doe@Software.com
Jane@Software.com
Sales@Software.com
Networks other than the Internet often use different addressing systems and directory services. When a network consists of only several dozen or even a few hundred machines, it is fairly easy for each computer to maintain a list of where all the other computers (and even all the other users) in that network are located. It is only with the advent of the huge Internet that it became impossible for every computer to keep track of the millions of other computers in the new virtual neighborhood.
For example, on some networks E-mail messages are simply handed from one computer to another until they reach the recipient, so that an address might look like this:
computer3!computer2!computer1!recipient
The above address indicates that the message needs to travel to computer3, then to computer2, and finally to computer1, where it is delivered to the intended recipient. This kind of addressing is clumsy and limited in comparison to the DNS system described in Section 1.5.1.
E-mail works beautifully -- most of the time. This section provides a quick overview of some of the defined standards, or protocols, which enable E-mail to work as smoothly as it does.
As E-mail has proliferated, it has done so in a variety of ways. The communications protocol used most often over TCP/IP links is the Simple Mail Transfer Protocol (SMTP). It has been tremendously successful as the protocol of choice on the popular Internet. The UNIX to UNIX Copy Protocol (UUCP) remains established on many older networks. X.400, part of the more recent Open Systems Interconnection (OSI) suite is used more widely in Europe, and can be used over TCP/IP connections.
X.400 has been less successful than SMTP perhaps because two different programs which are X.400 compliant are not necessarily able to exchange messages, due to the fact that the protocol is insufficiently specified. Despite these complications, some proprietary X.400, LAN-based E-mail systems have been successful on a smaller scale than SMTP. Such systems usually require a fairly homogeneous network and can in some cases become a liability when trying to communicate with the outside world.
While all of the various systems for message delivery work "domestically," trying to transfer E-mail between two locally disparate networks using different protocols can be difficult. In general it can be done once you know how (and in many cases if you can afford to pay for some fancy software). Learning the trick will remind you of how often Mr. Gore's information highway is still a dirt road where you have to experiment with various addressing formats to see what works.
Within a network such as the Internet these problems have been resolved. As long as UAs and MTAs are configured correctly (and this has historically been a fearsome task), mail transfer should be a cinch.
There is always somebody who supervises the electronic mail system. This person is known as the Postmaster.
As E-mail systems have evolved from a few users to the millions who currently send messages across a variety of public and private networks, a need has evolved for institutions such as corporations and universities to appoint individuals to supervise day to day E-mail operations. Often called Postmasters, they are entrusted with maintaining the software (UAs and MTAs) required to support E-mail as well as providing certain information and services to users.
In addition to installing MTAs and providing users with UAs, a Postmaster must in general keep an eye on the E-mail system to ensure that messages are being properly delivered in a timely manner. Postmasters receive error messages from the MTA when things go wrong. For instance, the Postmaster is usually the first to know that a disk is full or when a portion of the network is down since messages start to queue up abnormally. They can be notified of incorrectly addressed messages which the system failed to deliver. The Postmaster can then try to correct the problem so that the message can be delivered or have the message returned to its sender.
The Postmaster also functions as an E-mail guru for users, both by opening and closing E-mail accounts as well as by helping users with questions. Other E-mail related tasks that they may supervise include maintaining mailing lists, and establishing aliases (additional names under which users can receive mail). Many Postmasters are also responsible for general system maintenance, system security, and user training.
The addressing services used by computer programs to resolve an E-mail address were discussed in Section 1.5; but how do users find the correct address to put in a message header in the first place?
This has been a considerable problem for E-mail, especially for large and rapidly growing networks like the Internet. Unfortunately, the problem is not fully resolved yet. There are a few basic tools available, and although none provide a comprehensive "network phone book" they do provide limited assistance in locating someone's E-mail address or other information about them. The most widely available of these tools is finger service.
While the DNS is a directory service which helps computers to find information about where other computers are located, there are also directory services which allow users to obtain information about other users. The most widespread such directory service is the finger service, which allows you to "finger" someone - if you already know their E-mail address.
Many UAs can initiate finger queries, which can unearth interesting and sometimes useful information about the person who is queried. This could be their phone number and mailing address, some kind of humor, or whatever other kind of information that person wants you to know.
For example, a finger query for Jane@chicago.software.com could reveal the following information (Figure 1-10):
Jane Doe
Jane.Doe@Software.com
827 State Street
Santa Barbara, CA 93101
USA
Tel: (805) 882-2470
What do you call a thousand developers at the bottom
of the sea...?
Currently there is no completely comprehensive directory service that can find Jane Doe if you don't know her address at Software.com. Excellent directory services exist within certain small local networks, but none have yet achieved widespread success.
It is only a matter of time until some kind of virtual white pages arrives, and a server asks you demurely "what network please?"
An early attempt to create a comprehensive directory service is X.500, the general name given to directory services which are designed to the X.500 specifications. These specifications emerged (along with the second version of the X.400 specifications) as international standards in 1988. Due to the complexity of X.500 and its ties to the OSI protocol suite (which have never achieved a widespread market presence) implementations have been incomplete and incompatible. While there have been several experimental X.500 directory services, a ubiquitous and easy to use service has yet to emerge for the E-mail community.