Charles M. Kozierok The TCP-IP Guide

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

Key Concept: The SMTP sender performs operations using a set of SMTP

commands. Each command is identifies using a four-letter code. Since SMTP only

supports a limited number of functions, it has a small command set.

Obsolete SMTP Commands

The commands in the preceding table are the ones that are most commonly used in SMTP

today. In addition to those, there are also certain commands that were originally defined in

RFC 821 but have since become obsolete. These include the following:

☯ SEND, SAML (“send and mail”) and SOML (“send or mail”): RFC 821 defined a

distinct mechanism for delivering mail directly to a user's terminal as opposed to a

mailbox, optionally in combination with conventional e-mail delivery. These were rarely

implemented and obsoleted in RFC 2821.

☯ TURN: Reverses the role of the SMTP sender and receiver as described in the SMTP

special features topic. This had a number of implementation and security issues and

was removed from the standard in RFC 2821.

SMTP Replies and Reply Codes

SMTP communication begins with the establishment of an SMTP session between an

SMTP sender (the device acting as a client) and an SMTP receiver (the device acting as a

server). All protocol operations then consist of plain ASCII text SMTP commands issued by

the sender to the receiver. The receiver analyzes each command, carries out the instruction

requested by the sender if possible, and then responds back with a reply to the sender. The

reply serves several functions: confirming command receipt; indicating if the command was

accepted or not; and communicating the result of processing the command.

Just as SMTP commands are sent in a manner reminiscent of how FTP internal commands

work, SMTP replies are formatted and interpreted in a way almost identical to that of FTP

replies. As with FTP, the reply consists not just of a string of reply text, but a combination of

reply text and a numerical reply code. And as with FTP, these reply codes use three digits to

encode various information about the reply, with each digit having a particular significance.

The reply code is really the key part of the reply, with the reply text being merely descriptive.

Note: The topic on FTP reply codes contains a thorough explanation of the

benefits of using these structure numeric reply codes. Since the SMTP system is

so similar, I won't duplicate that discussion in this topic. I will, however, fully

describe the syntax and semantics of SMTP reply codes here, in order both to keep this

section on SMTP self-contained, and to indicate where the differences are between FTP

and SMTP reply codes.

Reply Code Structure and Digit Interpretation

SMTP reply codes can be considered to be of the form “xyz”, where “x” is the first digit, “y”

the second and “z” the third. Here is how these digits are used.

First Reply Code Digit (“x”)

The leading reply code digit indicates the success or failure of the command in general

terms, whether a successful command is complete or incomplete, and whether an unsuc-

cessful one should be tried again or not. This particular digit is interpreted in exactly the

same way as it is in FTP, as shown in Table 254.

Table 254: SMTP Reply Code Format: First Digit Interpretation

Code

Format

Meaning Description

1yz

Positive

Preliminary Reply

An initial response indicating that the command has been accepted and

processing of it is still in progress. The SMTP sender should expect

another reply before a new command may be sent.

Note that while this first digit type is formally defined in the SMTP speci-

fication for completeness, it is not currently actually used by any of the

SMTP commands. That is to say, there are no reply codes between 100

and 199 in SMTP.

2yz

Positive

Completion Reply

The command has been successfully processed and completed.

3yz

Positive

Intermediate Reply

The command was accepted, but processing of it has been delayed,

pending receipt of additional information. One example of where this

type of reply is often made is after receipt of a DATA command, to

prompt the SMTP sender to then send the actual e-mail message to be

transferred.

4yz

Transient Negative

Completion Reply

The command was not accepted and no action was taken, but the error

is temporary and the command may be tried again. This is used for

errors that may be a result of temporary glitches or conditions that may

change, such as a resource on the SMTP server being temporarily

busy.

5yz

Permanent

Negative

Completion Reply

The command was not accepted and no action was taken. Trying the

same command again is likely to result in another error. An example

would be sending an invalid command.

Second Reply Code Digit (“y”)

The middle digit categorizes messages into functional groups. This digit is used in the same

general way as in FTP, but some of the functional groups are different in SMTP, as you can

see in Table 255.

Third Reply Code Digit (“z”)

The last digit indicates a specific type of message within each of the functional groups

described by the second digit. The third digit allows each functional group to have 10

different reply codes for each reply type given by the first code digit (preliminary success,

transient failure and so on.)

Combining Digit Values to Make Specific Reply Codes

Again, as in FTP, these “x”, “y” and “z” digit meanings are combined to make specific reply

codes. For example, the reply code “250” is a positive reply indicating command

completion, related to the mail system. It usually is used to indicate that a requested mail

command was completed successfully.

Common SMTP Reply Codes

Table 256 contains a list of some of the more common SMTP reply codes taken from RFC

2821, in numerical order. For each, I have shown the “typical” reply text specified in the

standard, and provided additional descriptive information where I felt it was needed.

Table 255: SMTP Reply Code Format: Second Digit Interpretation

Code

Format

Meaning Description

x0z Syntax Syntax errors or miscellaneous messages.

x1z Information Replies to requests for information, such as status requests.

x2z Connections

Replies related to the connection between the SMTP sender and SMTP

receiver.

x3z Unspecified Not defined.

x4z Unspecified Not defined.

x5z Mail System Replies related to the SMTP mail service itself.

Table 256: SMTP Reply Codes (Page 1 of 3)

Code

Reply Text Description

211

System status or system help

reply.

214 <Help message…> Used for text sent in reply to the HELP command.

220 <servername> Service ready.

Greeting message sent when TCP connection is first

established to an SMTP server.

221

<servername> closing trans-

mission channel.

Goodbye message sent in response to a QUIT message.

250

Requested mail action okay,

completed

Indicates successful execution of a variety of commands.

251

User not local; will forward to

<forward-path>

Used when the SMTP receiver agrees to forward a

message to a non-local user.

252

Cannot VRFY user, but will accept

message and attempt delivery

Indicates that a server tried to verify an e-mail address, but

was not able to do so completely. Usually means the

address appears to be valid but it was not possible to

positively ascertain this to be true.

354

Start mail input; end with

Intermediate reply to a DATA command.

421

<servername> Service not

available, closing transmission

channel

Sent in response to any command when the SMTP

receiver prematurely terminates the connection. A

common reason for this is receipt of a local shutdown

command, due for example to a hardware reboot.

450

Requested mail action not taken:

mailbox unavailable

Sent when a mailbox is busy due to another process

accessing it.

451

Requested action aborted: local

error in processing

Local processing problem on the server.

452

Requested action not taken:

insufficient system storage.

Time to clean out the server's hard disk! ☺

500

Syntax error, command

unrecognized

Response to a bad command or one that was too long.

501

Syntax error in parameters or

arguments

502 Command not implemented

Command is valid for SMTP in general but not supported

by this particular server.

503 Bad sequence of commands

Commands were not sent in the correct order, such as

sending the DATA command before the MAIL command.

504

Command parameter not

implemented.

550

Requested action not taken:

mailbox unavailable

Generic response given due to a problem with a specified

mailbox. This includes trying to send mail to an invalid

address, refusal to relay to a non-local mailbox and so

forth.

551

User not local; please try

<forward-path>

Tells the SMTP sender to try a different path; may be used

to support mailbox forwarding.

Table 256: SMTP Reply Codes (Page 2 of 3)

Code

Reply Text Description

As mentioned before, the actual text string for each reply code is implementation-specific.

While the standard specifies “dry” response text such as “Requested action completed” for

a 250 message, some servers customize this code, or even give different replies to different

250 messages depending on context. Again, there are examples of this in other topics.

SMTP Multiple-Line Text Replies

Again, as in FTP, it is possible for a reply to contain more than one line of text. In this case,

each line starts with the reply code, and all lines but the last have a hyphen between the

reply code and the reply text, to indicate that the reply continues. The last line has a space

between the reply code and text, just like a single-line reply. An example of this was given in

the topic on SMTP connections where I showed a multi-line response to a EHLO command.

Enhanced Status Code Replies

When the ENHANCEDSTATUSCODES SMTP extension is enabled, this causes supple-

mental reply codes to be issued by the SMTP receiver in response to each command.

These codes are similar in some respects to the standard reply codes; they also use three

digits, but the digits are separated by periods. These enhanced codes provide more infor-

mation about the results of operations, especially errors.

For example, if you try to issue a RCPT command specifying a non-local mailbox on a

server not supporting this feature, it will send back a “550” reply, which is a generic error

(“requested action not taken: mailbox unavailable”). When enhanced status codes are

active, the response will be “550 5.7.1”, the more specific message “delivery not authorized,

request refused”. A full description of these enhanced codes can be found in RFC 1893.

Key Concept: Each time the SMTP sender issues a command, it receives a reply

from the SMTP receiver. SMTP replies are similar to FTP replies, using both a three-

digit reply code and a descriptive text line. A special enhanced status codes SMTP

extension is also defined; when enabled, this causes the SMTP receiver to return more

detailed result information after processing a command.

552

Requested mail action aborted:

exceeded storage allocation

User's mailbox is full.

553

Requested action not taken:

mailbox name not allowed

Specification of an invalid mailbox address.

554 Transaction failed. General failure of a transaction.

Table 256: SMTP Reply Codes (Page 3 of 3)

Code

Reply Text Description

TCP/IP Electronic Mail Access and Retrieval Protocols and Methods

The Simple Mail Transfer Protocol (SMTP) is responsible for most of the process of sending

an e-mail message from the originator to the recipient. SMTP's job ends when the message

has been successfully deposited into the recipient's mailbox on his or her local SMTP

server.

In some cases this mailbox is the end of the message's travels through cyberspace. More

often, however, it is only a “rest stop”—the last step of the journey is for the message to be

actually accessed and read by the user to whom it was sent. This may require that it be

retrieved from the mailbox and transferred to another client machine. For a variety of

reasons, SMTP is not used for the process of accessing a mailbox, but rather a special set

of protocols and methods designed specifically for electronic mail access and retrieval.

In this section, I describe some of the more common techniques used for TCP/IP e-mail

access and retrieval. I begin with an overview of the subject that describes in general the

different paradigms used for e-mail access and gives an overview of the protocols. I then

have subsections that cover the two mail TCP/IP e-mail access and retrieval protocols: the

Post Office Protocol (POP) and the Internet Message Access Protocol (IMAP). I also have a

third, smaller subsection that discusses other methods of e-mail access.

Note that this section assumes that you already have familiarity with SMTP and the

operation of the TCP/IP e-mail system as a whole.

TCP/IP Electronic Mail Mailbox Access Model, Method and Protocol Overview

In an ideal world… we would all be born knowing everything there is to know about

computers and networking, and I'd have become a famous novelist instead of writing

thousands of pages of this stuff. ☺ Well, that may be asking a bit too much, but wouldn't it

have been nice if every device on the Internet simply ran SMTP server software? If so, then

that one protocol would be sufficient to implement the entire TCP/IP e-mail system. You

would just compose e-mail on your machine, and your SMTP software would send it to your

recipient's, and he or she would read it. Nice and simple.

Back here in the real world, however, this is really not possible in general terms. As I

explained in the overview section on e-mail and the discussion of SMTP, an SMTP server

must be connected to the Internet and available around the clock to receive e-mail sent at

any time by any of the millions of other computers in the world. Most of us either cannot or

do not want to run machines continuously connected to the Internet, nor do we want to

configure and maintain potentially-complex SMTP software. This is the reason why a

complete e-mail exchange normally involves not two devices but four: a message is

composed on the sender's client machine, transferred to the sender's SMTP server, then to

the recipient's SMTP server, and finally, to the recipient's machine.

The Advantages of Specialized Mail Access and Retrieval Protocols

The communication between SMTP servers is of course done with SMTP. So is the initial

step of sending the e-mail from the sender's machine to the sender's SMTP server.

However, SMTP is not used for the last part of the process, accessing the recipient's

mailbox. Instead, a set of mailbox access and retrieval protocols and methods were

devised.

A fair question is… why was this done? Why not simply have mail sit “pending” on the

recipient's SMTP server and then have it send the mail to the recipient client device when it

comes online, using SMTP? There are two main reasons for this. The first is that SMTP

was designed for the specific purpose of transporting e-mail only. Having it responsible for

client mailbox access would require adding more functionality, making it difficult to keep

SMTP “simple”. Also, SMTP works on a “push” model, with transactions being initiated by

the sender. It would need changes to allow it to respond to requests from a client device

that is only online intermittently.

But the second reason is probably more important: flexibility in how electronic mail is

accessed. If we used SMTP, all we would be able to do is transfer e-mail to the recipient's

client machine. This would be functional, but would greatly limit the capabilities of how e-

mail is used. For example, some users might wish to access mail directly on the server and

manipulate it there. Also consider the problem of people with special requirements, such as

those who travel and may need to access e-mail from a number of different client devices.

E-Mail Access and Retrieval Models

For the reasons just examined, there is an advantage to providing more than one way to

access a mailbox. RFC 1733, Distributed Electronic Mail Models In IMAP4, describes three

different paradigms or models for mail access and retrieval:

☯ Online Access Model: This is the mode of access that we would all be using in my

“ideal world” scenario, where every machine was always connected to the Internet

running an SMTP server. You would have constant, direct online access to your

mailbox. In the real world, this model is still used by some Internet users, especially

those who have UNIX accounts or run their own SMTP servers. I call this direct server

access.

☯ Offline Access Model: In this paradigm, a user establishes a connection to a server

where his or her mailbox is located. The user downloads received messages to the

client device, and then deletes them from the server mailbox. All reading and other

activity performed on the mail can be done “offline” once the mail has been retrieved.

☯ Disconnected Access Model: This is a hybrid of online and offline access. The user

downloads messages from the server, so he or she can read or otherwise manipulate

them without requiring a continuous connection to the server. However, the mail is not

deleted from the server, like in the offline model. At some time in the future, the user

connects back with the server and synchronizes any changes made on the local

device with the mailbox on the server.

What sort of changes? Examples include marking whether or not a message has been

read, to keep track of unread mail, and marking messages to which the user has

already replied. These are important tools to help those with busy mailboxes keep

track of what they need to do.

Comparing E-Mail Access and Retrieval Models

Of the three, which is best? You should know better than to ask me that question. ☺ Each

has advantages and disadvantages, which is why it is good that we have these options

rather than the single SMTP protocol for mail access.

Direct server access has the main benefits of instant speed and universal access from any

location. It has the disadvantage that you must be online to read mail, and that it usually

requires you to use UNIX e-mail clients that most people are not familiar with. However, the

Internet Message Access Protocol (IMAP) can also be used for online access.

Offline access has the main advantages of simplicity and short connection time require-

ments; you can easily connect to the mailbox, download messages and then read them

locally. But that makes this method somewhat inflexible, and poorly-suited to access from

different machines. Still, it is right now the most popular access method, because simplicity

is important; it is best typified by the popular Post Office Protocol (POP).

Disconnected access attempts to combine the advantages of offline and online access

without combining their disadvantages, and does a pretty good job. The advantages are

significant: the ability to quickly access mail and use it offline, while retaining and updating

the mailbox on the server to allow access from different client machines. IMAP is the

protocol popularly used for disconnected access. In the IMAP overview I explore its advan-

tages over offline access, as well as its main disadvantages: complexity and far less

universal support than POP (though acceptance of IMAP is slowly increasing).

Finally, in recent years, a somewhat new mailbox access method has become popular: e-

mail access using the World Wide Web. This technique allows a user to access his or her

mailbox from any computer with an Internet connection and a Web browser. It is a good

example of “line blurring”, not only between the access models discussed here, but

between TCP/IP applications, in this case the Web and e-mail.

Key Concept: For flexibility, TCP/IP uses a variety of mailbox access and retrieval

protocols and methods to allow users to read e-mail. Three different models describe

how these different methods work: the online model, in which e-mail is accessed and

read on the server; the offline model, in which mail is transferred to the client device and

used there; and the disconnected model, where mail is retrieved and read offline but

remains on the server with changes synchronized for consistency.

TCP/IP Post Office Protocol (POP/POP3)

The overall communication model used for TCP/IP e-mail gives many options to an e-mail

user for accessing his or her electronic mailbox. The most popular access method today is

the simple offline access model, where a client device accesses a server, retrieves mail and

deletes it from the server. The Post Office Protocol (POP) was designed for quick, simple

and efficient mail access; it is used by millions of people to access billions of e-mail

messages every day.

In this section I describe the operation of the Post Office Protocol, focusing on version 3

(POP3). I begin by looking at the protocol in general terms, discussing its history, the

various versions of the protocol and the standards that define them. I describe POP3's

general operation and the communication between a client and server, concentrating on the

three main states through which the session transitions. I then describe each of these

states in sequence: the Authorization state, Transaction state and Update state. For each, I

explain the communication processes that take place and the commands and replies that

implement them.

POP Overview, History, Versions and Standards

Of the three mailbox access paradigms, online, offline and disconnected, the offline model

is probably the least capable in terms of features. And it is also the most popular! This may

seem counter-intuitive, but it is in fact a pattern that repeats itself over and over in the

worlds of computing and networking: a good example would be Ethernet beating Token

Ring in the LAN market. The reason is that simplicity and ease of implementation are keys

to the success of any technology, and the offline mail access model beats the other two in

these areas.

The history of offline e-mail access goes back farther than one might expect—to the early

1980s. Two decades ago, we didn't have nearly everyone and his brother accessing the

Internet to check e-mail the way we do today. In fact, there were only a relatively small

number of machines connected using TCP/IP, and most users of these machines had the

ability to access their e-mail on-server, using the online access model.

However, even back then, developers recognized the advantages of being able to retrieve

e-mail from a server directly to a client computer, rather than accessing the mailbox on the

server using Teln et or NFS. In 1984, RFC 918 was published, defining the Post Office

Protocol (POP). The idea behind POP was to provide a simple way for a client computer to

retrieve e-mail from a mailbox on an SMTP server so it could used locally.

The emphasis was on simple; the RFC for this first version of POP is only 5 pages long,

and the standard it defined is extremely rudimentary. It describes only a simple sequence of

operations where a user gives a name and password for authentication, and then

downloads the entire contents of a mailbox. Simple is good, but there are limits.