Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

electronic mail system. Each user simply had a mailbox that resided on this machine, and

mail was “delivered” by moving messages from one mailbox to the next. Users sent and

received mail through a user interface program.

Such an early electronic mail system was useful for local communication, but not for

sending messages to a person in another organization. Mainframe e-mail is somewhat

analogous to “local mail” being sent by one resident of a town to another. There is no way to

send mail to a person in a distant town without more infrastructure for delivery.

The power of internetworking is what really enables electronic mail to become a universal

method of communication. Internetworks link together systems the way the postal service's

fleet of airplanes and vehicles link together post offices. Mail is sent from user to user over

the underlying technology of the internetwork. TCP/IP is of course the most commonly used

internetworking protocol suite, and the modern Internet uses TCP/IP to tie together systems

across the globe. It is thus “the vehicle” for sending electronic mail.

The History of TCP/IP Electronic Mail

Like some other file and message transfer protocols, e-mail on TCP/IP actually goes back

to before TCP/IP and the Internet formally existed. The first protocols for e-mail were

developed during the days of the ARPAnet. Prior to the creation of e-mail, several Internet

RFCs, such as RFC 95 (yes 95, two digits, we are going back a long way here!) and RFC

155 describe physical mailing lists that were used for distributing documents in the early

1970s. It was this need to send documents that likely made TCP/IP pioneers realize how

useful an electronic messaging system would be using the technology they were

themselves creating.

The first Internet document describing electronic mail was probably RFC 196, published in

1971. It describes something called A Mail Box Protocol, a very rudimentary message

transfer method using the predecessors of TCP/IP. This protocol was designed for the

specific purpose of sending documents for remote printing. In those days it was not as

common for people to use computers at interactive terminals as it is today, but the idea of

electronically mailing documents was the same. The Mail Box Protocol was revised several

times in 1971.

In the mid-1970s, work began to develop a more comprehensive method of implementing

electronic mail on the fledgling Internet. The technique was originally described using a

number of then-existing application-layer transfer protocols, including the File Transfer

Protocol (FTP). In 1980 the Mail Transfer Protocol (MTP) was published in RFC 772. This

was the first precursor of today's TCP/IP e-mail, and was defined using principles from the

Teln et remote access protocol as well as FTP.

During the time that e-mail protocols were being developed in the 1970s, mail was being

exchanged between host systems using a variety of different techniques. One of the most

common used the Unix-to-Unix Copy Protocol (UUCP), which was designed to allow files to

be transferred between UNIX systems, moving them from one connected system to the

next. UUCP was also used for communicating Usenet newsgroup articles and other files.

In 1981, the modern TCP/IP electronic mail era came into being with the definition of the

Simple Mail Transfer Protocol (SMTP). SMTP described in detail how mail could be moved

directly or indirectly from one TCP/IP host to another without the need to use FTP or

another file transfer method. It has its own detailed history and discussion in this Guide.

Other complementary specifications were created at around the same time, which

formalized or defined other components and elements of the system. We'll explore these

pieces of the puzzle in the next two topics.

Overview of the TCP/IP Electronic Mail System

One of the most important general concepts in the modern electronic mail system is that a

distinction is made between protocols that deliver electronic mail between SMTP hosts on

the internetwork, and those that let users access received mail on their local hosts. To

continue our analogy, different protocols are used for sending mail between post offices,

and for “home delivery”. As we'll see, this was done intentionally, to make it possible to send

mail to users even if they are not connected to the Internet at the time mail was sent. This

decoupling is critical as it enables delayed communication, where mail can be sent when

the sender wants to transmit it, and received when the recipient wants to read it.

Over the years, the basic components defined in the early 1980s have not changed

substantially, but how they are used has evolved and been improved. Early electronic mail

delivery involved the use of route specifications by one SMTP host to dictate how mail was

to be delivered through intermediate systems; today, the Domain Name System makes

much of that obsolete, facilitating nearly immediate direct mail delivery in most cases. Early

electronic mail supported only simple text, where we can now send graphical images,

programs and other files in e-mail. Modern high-speed Internet connections and updated

access protocols allow modern e-mail to be the realization of the ultimate goal of nearly

instantaneous communication even across continents.

Key Concept: One of the most important TCP/IP applications is the internetworking

equivalent of the real-world postal delivery system, commonly called electronic mail

or e-mail. The history of e-mail goes back to the very earliest days of TCP/IP’s devel-

opment; today it is used by millions of people every day to send both simple and complex

messages around the world. TCP/IP e-mail is not a single application, but rather a complete

system that includes several protocols, software elements and components.

TCP/IP Electronic Mail Communication Overview: Message Composition,

Submission, Delivery, Receipt, Processing and Access

TCP/IP electronic mail is implemented as a complete system, with a number of different

elements that perform different portions of the complete job of electronic mail communi-

cation. These included a standard message format, a specific syntax for recipient

addressing, and protocols to both deliver mail and allow access to mailboxes from intermit-

tently-connected TCP/IP clients.

To help set the groundwork for examining these components, I want to provide an overview

of the complete end-to-end process of e-mail communication, so you can see how every-

thing works. I will show the basic steps in simplified form, and continue the analogy to the

regular mail system for comparison.

E-Mail Communication Process Steps

The modern TCP/IP e-mail communication process consists of the following five basic

steps.

1. Mail Composition

A user begins the e-mail journey by creating an electronic mail message. The message

contains two sections: the header and the body. The body of the message is the actual

information to be communicated; the header contains data that describes the message and

controls how it is delivered and processed. The message must be created so that it

matches the standard message format for the e-mail system so that it can be processed. It

must also specify the e-mail addresses of the intended recipients for the message.

By way of analogy to real mail, the body of the message is like a letter, and the header is

like the envelope into which the letter is placed.

2. Mail Submission

As we'll see in greater detail in the next topic, electronic mail is different from many other

internetworking applications in that the sender and receiver of a message do not neces-

sarily need to be connected to the network simultaneously, nor even continuously, to use it.

The system is designed so that after composing the message, the user decides when to

submit it to the electronic mail system so it can be delivered. This is done using the Simple

Mail Transfer Protocol (SMTP).

This is analogous to dropping off an envelope at the post office, or to a postal worker

picking up an envelope from a mailbox and carrying it to the local post office to insert into

the mail delivery stream.

3. Mail Delivery

The electronic mail message is accepted by the sender's local SMTP system for delivery

through the mail system to the destination user. Today, this is accomplished by performing a

Domain Name System (DNS) lookup of the intended recipient's host system and estab-

lishing an SMTP connection to that system. SMTP also supports the ability to specify a

sequence of SMTP servers through which a message must be passed to reach a desti-

nation. One way or the other, eventually the message arrives at the recipient's local SMTP

system

This is like the transportation of the envelope through the postal system's internal “inter-

network” of trucks, airplanes and other equipment to the intended recipient's local post

office.

4. Mail Receipt and Processing

The local SMTP server accepts the e-mail message and processes it. It places the mail into

the intended recipient's mail box, where it waits for the user to retrieve it.

In our physical analogy, this is the step where the recipient's local post office sorts mail

coming in from the postal delivery system and puts the mail into individual post office boxes

or bins for delivery.

5. Mail Access and Retrieval

The intended recipient periodically checks with its local SMTP server to see if any mail has

arrived. If so, the recipient retrieves the mail, opens it and reads its content. This is done

using not SMTP but a special mail access protocol or method. To save time, the access

protocol and client e-mail software may allow the user to scan the headers of received mail

(such as the subject and sender's identity) to decide which mail messages to download.

This is the step where mail is physically picked up at the post office or delivered to the

home.

Modifications to the General Communication Process

In some cases not all of these steps are performed. If a user is sending e-mail from a device

that is already an SMTP server, then step #2 can be omitted; if the recipient is logged in to a

device that is also an SMTP server, step #5 will be skipped, as the user can read mail

directly on the server. Thus, in the simplest case all that occurs is composition, delivery and

receipt; this occurs when one user of a dial-up UNIX host sends mail to another. In most

cases, today, however, all five steps occur.

Key Concept: TCP/IP electronic mail communication normally involves a sequence

of five steps, each of which is analogous to a portion of the journey taken by a

regular letter through the postal system. First, e-mail is composed (written); second,

it is submitted to the e-mail system; third, it is delivered to recipient’s server; fourth, it is

received and processed; and finally, fifth, it is accessed and retrieved by its recipient.

Again, this is simplified. I have, for example, omitted the step where the recipient notices

that the mail is in fact an advertisement from a spammer for how he can “make money fast”,

eliminate debt or lose weight overnight, then mutters under his breath and deletes the

message. Hey, I never said there were no disadvantages to electronic mail being fast and

nearly free. ☺

TCP/IP Electronic Mail Message Communication Model and Device and

Protocol Roles

The purpose of the electronic mail system as a whole is to accomplish the transmission of

electronic mail messages from a user of a TCP/IP internetwork to one or more recipients. In

order to accomplish this, a special method of communication is required that makes the

electronic mail system quite different from that used by most other protocols. To understand

what I mean by this, you need only recognize the difference in communication between

sending a letter and making a phone call.

Most TCP/IP protocols are analogous to making a phone call in this respect: the sender and

the receiver must both be on the network at the same time. You can't call someone and talk

to them if they aren't around to answer the phone. (Yeah, yeah, answering machines and

voice mail. Stop interrupting, will you? ☺) Most TCP/IP protocols are like this: to send a file

using FTP, for example, you must make a direct connection from the sender's machine to

the recipient's machine. If the recipient's machine is not on the network at the exact time

that sender's is, no communication is possible.

For electronic mail, this type of communication is simply unacceptable. Electronic mail is

like its real-world counterpart; Joe wants to be able to put a message into the system at a

time that is convenient for him, and Ellen wants to be able to receive Joe's mail at a time

that works for her. For this to work, e-mail must use a “send and forget” model, just like real

mail, where Joe drops the “envelope” into the e-mail system and it eventually gets to its

destination.

This decoupling of the sender and receiver is critical to the design of the electronic mail

system. This is especially true because many of the users of Internet electronic mail are not

on the Internet all the time. Just as you wouldn't want real mail to be rejected if it arrived

when you are not home, you don't want electronic mail to not be delivered if you are not on

the Internet when it arrives. Similarly, you may not want to be connected to the Internet for

the entire time it takes to write a message, especially if you have access to the Internet for

only a limited amount of time each day.

Also critical to the entire electronic mail system is that idea that communication is between

specific users, and not between particular machines. This makes e-mail inherently different

than many other types of communication on TCP/IP internetworks. We'll see more of why

this is important when we look at e-mail addressing.

The Delayed Delivery Model and Device Roles

To allow the type of communication needed for electronic mail, the entire system is

designed to facilitate the delayed delivery of e-mail messages from one user to another. To

see how this works, let's look again at the example communication we discussed in the

previous topic, but this time, considering the roles of the different devices in the exchange

(as shown in Figure 301):

☯ Sender's Client Host: The sender of the mail composes an electronic mail message,

generally using a mail client program on his or her local machine. The mail, once

composed, is not immediately sent out over the Internet; it is held in a buffer area

called a spool. This allows the user to be “detached” for the entire time that a number

of outgoing messages are created. When the user is done, all of the messages can be

sent at once.

☯ Sender's Local SMTP Server: When the user's mail is ready to be sent, he or she

connects to the internetwork. The messages are then communicated to the user's

designated local SMTP server, normally run by the user's Internet Service Provider

(ISP). The mail is sent from the client machine to the local SMTP server using SMTP.

(It is possible in some cases for the sender to be working directly on a device with a

local SMTP server, in which case sending is simplified.)

☯ Recipient's Local SMTP Server: The sender's SMTP server sends the e-mail using

SMTP to the recipient's local SMTP server over the Internetwork. There, the e-mail is

placed into the recipient's incoming mailbox (inbox). This is comparable to the

outgoing spool that existed on the sender's client machine. It allows the recipient to

accumulate mail from many sources over a period of time, and retrieve them when it is

convenient.

☯ Recipient's Client Host: In certain cases the recipient may access his or her

mailboxes directly on the local SMTP server. More often, however, a mail access and

retrieval protocol, such as POP3 or IMAP, is used to read the mail from the SMTP

server and display it on the recipient's local machine. There, it is displayed using an e-

mail client program, similar to the one the sender used to compose the message in the

first place.

Protocol Roles In Electronic Mail Communication

You may have noticed that SMTP is used for most of this communication process. In fact, if

the recipient uses a machine that runs SMTP software, which is common for those using

dialup UNIX shell Internet access, the process of sending e-mail uses SMTP exclusively.

Figure 301: Electronic Mail (E-Mail) Communication Model

This diagram shows the four devices that are involved in a typical e-mail communication between two users.

(Yes, they are identical twins, imagine that! ☺) Each device consists of a number of different elements, which

communicate as indicated by the black arrows. Note the inherent asymmetry, because the method used to

send an e-mail from a user is not the same as that used to retrieve it from the server. The large green arrows

show a typical transaction: the sender composes mail and it goes to her local e-mail spool. It is sent to the

sender’s local SMTP server using SMTP, and then to the recipient’s SMTP server, where it goes into that

user’s inbox. It is then retrieved, usually using a protocol such as POP or IMAP.

Sender's Client

E-M ail

Reader/Editor &

POP/IMAP Client

SMTP

Client

Sender

Local

E-M ail

Spool

Sender's Local

SMTP Server

POP/IM AP Serv er

SMTP

Server

File

System

Recipient's Local

SMTP Server

POP/IM AP Serv er

SMTP

Server

File

System

Recipient's Client

E-M ail

Reader/Editor &

POP/IMAP Client

SMTP

Client

Recipient

Local

E-M ail

Spool

SMTP servers must, however, always be available on the Internet and ready to accept mail.

Most people access the internetwork using devices that aren't always online or that don't

run SMTP software. That is why the last step, mail access and retrieval, is usually required.

It might have been possible to define the electronic mail system so that this last step of

communication was carried out using SMTP as well, which would mean the entire system

used the same protocol. However, SMTP was tailored for the specific purpose of trans-

porting and delivering e-mail, not for remote mailbox access. It made more sense to leave

the function of mailbox access to dedicated, separate protocols. This not only allows these

protocols to be tailored to the needs of e-mail recipients, but provides flexibility by giving

users more than one option for how e-mail is retrieved. I discuss mail access protocols and

methods in a separate section of the Guide, highlighting the two most common protocols:

the Post Office Protocol (POP) and the Internet Message Access Protocol (IMAP).

The three protocols discussed above—SMTP, POP3 and IMAP—get the “lead billing” on

the TCP/IP electronic mail stage, but they rely on two other elements to play “supporting

roles”. The first is a method of addressing e-mail messages to ensure that they arrive at

their destinations. The second is the set of message formats used to encode messages and

control how they are delivered and used. These don't usually get as much attention as they

deserve, but they do here, as I have devoted the next two sections to them.

Key Concept: One of the critical requirements of an electronic mail system is that

the sender and receiver of a message not be required to both be on the system at

the time mail is sent. TCP/IP therefore uses a communication model with several

devices that allow the sender and recipient to be decoupled. The sender’s client device

spools mail and moves it to the sender’s local SMTP server when it is ready for trans-

mission; the e-mail is then transmitted to the receiver’s SMTP server using SMTP. The e-

mail can remain on the recipient’s server for an indefinite period of time. When the recipient

is ready to read it, he or she retrieves it using one or more of a set of mail access protocols

and methods, the two most popular of which are POP and IMAP.

TCP/IP Electronic Mail Addresses and Addressing

The entire concept of electronic mail is based on an analogy: the comparison of sending

electronic messages to the sending of paper messages. The analogy works well because

e-mail was indeed intended to be like regular mail, only with the advantages of the

electronic era: speed and flexibility.

One of the many similarities between electronic and regular mail is the need for addressing.

In order for a message to be delivered, it is necessary that the sender specify who the

recipient is, and provide a reasonable amount of information to indicate how the recipient

can be reached. In TCP/IP electronic mail, a standard electronic mail address format is

used for this, and support is also provided for alternative addressing schemes that may be

used in special cases.

In this section I describe how electronic mail messages are addressed. I begin with a

discussion of standard electronic mail addressing in TCP/IP, and how those addresses are

used to determine where e-mail should be sent. I then provide a brief discussion of

historical and special e-mail addresses that you may encounter from time to time. I also

discuss the use of e-mail address books (aliases) and how multiple recipients may be

addressed, as well as providing an overview of electronic mailing lists, one of the earliest

ways in which electronic group communication was implemented.

TCP/IP Electronic Mail Addressing and Address Resolution

All communication on an internetwork requires some way of specifying the identify of the

intended recipient of the communication. Most application protocols, such as FTP and

HTTP for example, use conventional TCP/IP constructs—IP addresses and port numbers—

to specify the destination of information to be sent. The IP address normally identifies a

particular host computer, and the port number a software process or application running on

that computer.

Electronic mail, however, uses a very different model for communication than most applica-

tions. As we saw in our discussion of the e-mail model, one element that sets e-mail apart

from many other systems is that communication is user-oriented. E-mail is not sent from

one machine to another the way a file is transferred using FTP. It is sent from one user to

another. This is critical to the operation of the entire system; for one thing, it is what allows

someone to retrieve e-mail that has been sent from any number of different client

computers. This allows e-mail to be received even when traveling, for example.

Since e-mail messaging is user-based, it is necessary that the addressing scheme be user-

based as well. We cannot use conventional IP addresses and ports, but need a distinct

system that specifies two primary pieces of information: who the user is, and where the

user is located. These are, of course, analogous to a name and address on a regular mail

envelope.

The idea of a user name is relatively straight-forward, but identifying the location of the user

is not. In regular mail, an address refers to a physical place. It would have been possible to

define e-mail addresses in the same way: have it refer to the user's client machine.

However, recall the other important characteristic of e-mail delivery: it is indirect, and based

on the concept of a user's local SMTP server holding received messages until they can be

retrieved. The machine that the user employs to access his or her e-mail may not even

routinely be on the Internet, and it may thus not be easy to identify it. And again, we want a

user to be able to access mail from multiple machines.

For all of these reasons, we want addresses to identify not the user's specific location at

any particular time, but the place where the user's permanent mailbox lives. This is on the

user's SMTP server, which is permanently connected to the Internet.

Standard DNS-Based E-Mail Addresses

In TCP/IP, the system used for identifying servers (and other machines) is the Domain

Name System (DNS). DNS is a big system and is described in its own large section in this

Guide; I would refer you to it if you want to learn more. For our purposes, what is important

is that in DNS, all devices on the Internet are arranged into a device naming hierarchy, and

any device can be identified using a domain name consisting of a series of text labels

separated by dots.

So, the complete TCP/IP address consists of two components: a user name specification

and a domain name specification. The two are connected together using the special “at”

symbol (“@”) to form the TCP/IP e-mail address syntax that almost all of us are familiar with

today:

The format of <domainname> follows the syntax rules of DNS, containing only numbers

and digits for each label, and periods to separate the labels. The format of <username> is

slightly less restrictive, allowing the use of special characters such as the underscore (“_”).

Other special characters and spaces are also allowed in the <username> if they are

surrounded by quotes (or otherwise marked as being part the name, such as through the

use of an escape character.) Domain names are case-insensitive; user names may be

case-sensitive, depending on the system.

So, an example of a valid e-mail address might be the following address I used when I was

in school many years ago:

cmk@athena.mit.edu

Where “cmk” is my user name (my initials) and the “athena.mit.edu” is the name of the host

where I was receiving mail. “athena” is a particular system at MIT (“mit”), which is an educa-

tional institution, and so uses the “.edu” top-level domain.