Charles M. Kozierok The TCP-IP Guide

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

In February 1985, RFC 937 was published: Post Office Protocol - Version 2. POP2

expanded the capabilities of POP by defining a much richer set of commands and replies.

This includes the important ability of being able to read only certain messages, rather than

dumping a whole mailbox. Of course, this came at the cost of a slight increase in protocol

complexity, but POP2 was still quite simple as protocols go.

These two early versions of POP were used in the mid-1980s, but not very widely. Again,

this is simply because the need for an offline e-mail access protocol was limited at that time;

most people were not on the Internet before the 1990s.

In 1988, RFC 1081 was published, describing version 3 of the Post Office Protocol (POP3).

By this time, the personal computer (PC) was transitioning from a curiosity to a place of

importance in the worlds of computing and networking. POP3 was based closely on POP2,

but refined and enhanced with the idea of providing a simple and efficient way for PCs and

other clients not normally connected to the Internet to access and retrieve e-mail.

Development on POP3 continued through the 1990s, with several new RFCs published

every couple of years. RFC 1081 was obsoleted by, in turn, RFCs 1225, 1460, 1725 and

1939. Despite the large number of revisions, the protocol itself has not changed a great

deal since 1988; these RFCs contain only relatively minor tweaks to the original description

of the protocol. RFC 1939 was published in 1996 and POP3 has not been revised since that

time, though a few subsequent RFCs define optional extensions and additions to the basic

protocol, such as alternative authentication mechanisms.

While POP3 has been enhanced and refined, its developers have remained true to the

basic idea of a very simple protocol for quick and efficient e-mail transfer. POP3 is a

straight-forward state-based protocol, with a client and server proceeding through three

stages during a session. A very small number of commands are defined to perform simple

tasks, and even after all the changes and revisions described above, the protocol has a

minimum of “fluff”.

For reasons that are unclear to me, almost everyone refers to the Post Office Protocol with

its version number; that is, they say “POP3” instead of “POP”. This is true despite most

people not using version numbers with many other protocols, and almost nobody using any

other version of POP anyway. But it is the convention, and I will follow it in the rest of this

section.

Key Concept: The Post Office Protocol (POP) is currently the most popular TCP/IP

e-mail access and retrieval protocol. It implements the offline access model, allowing

users to retrieve mail from their SMTP server and use it on their local client

computers. It is specifically designed to be a very simple protocol and has only small

number of commands. The current revision of POP is version 3, and the protocol is usually

abbreviated POP3 for that reason.

Note: There are some implementations of POP that attempt to implement the

disconnected access model, with limited success. More often, however, IMAP is

used for this purpose, since it is better suited to that access model. See the

overview of IMAP for more details.

POP3 General Operation, Client/Server Communication and Session States

As I mentioned in the previous topic, the Post Office Protocol was designed to perform only

one main function, and to do it quickly and simply: allow a client computer to access and

retrieve e-mail from a server. The operation of the protocol is simple and straight-forward,

which is good news for you, the person trying to understand how it works.

Client/Server Communication

POP3 is a regular TCP/IP client/server protocol. To provide access to mailboxes, POP3

server software must be installed and continuously running on the server where the

mailboxes are located. This does not necessarily have to be the same physical hardware

device that runs the SMTP server software that receives mail for those boxes—a

mechanism such as NFS may be used to allow the POP3 and SMTP servers to both “see”

mailboxes locally. POP3 clients are regular end-user e-mail programs that make connec-

tions to POP3 servers to get mail; examples include Microsoft Outlook, Eudora Email and

so forth.

POP3 uses the Transmission Control Protocol (TCP) for communication, to ensure the

reliable transfer of commands, responses and message data. POP3 servers “listen” on

well-known port number 110 for incoming connection requests from POP3 clients. After a

TCP connection is established, the POP3 session is activated. The client sends commands

to the server, which replies with responses and/or e-mail message contents.

Commands and Response Codes

POP3 commands are three or four letters long and are case-insensitive. They are all sent in

plain ASCII text and terminated with a “CRLF” sequence, just as with FTP and SMTP

commands. POP3 replies are also textual, but the protocol does not use the complex three-

digit reply code mechanism of FTP (and SMTP). In fact, it defines only two basic responses:

☯ +OK: A positive response, sent when a command or action is successful; and

☯ -ERR: A negative response, sent to indicate that an error has occurred.

These messages may be accompanied by explanatory text, especially in the case of an

-ERR response, to provide more information about the nature of the error.

Session States

POP3 is described in terms of a finite state machine (FSM), with a session transitioning

through three states during the course of its “lifetime”, as shown in Figure 306.

Note: I describe the concepts behind Finite State Machines in the topic describing

the TCP FSM.

Before you get too intimidated, realize that unlike the FSMs of protocols like TCP, this one

really is simple, because it is linear. The session goes through each state once and only

once, in the following sequence:

1. Authorization State: The server provides a greeting to the client to indicate that it is

ready for commands. The client then provides authentication information to allow

access to the user's mailbox.

2. Transaction State: The client is allowed to perform various operations on the mailbox.

These include listing and retrieving messages, and marking retrieved messages for

deletion.

3. Update State: When the client is done with all of its tasks and issues the QUIT

command, the session enters this state automatically, where the server actually

deletes the messages marked for deletion in the Transaction state. The session is then

concluded and the TCP connection between the two terminated.

POP3 is designed so that only certain commands may be sent in each of these states. The

next three topics describe the activities that take place in these three states, including the

commands that are issued by the client in each.

Key Concept: POP3 is a client/server protocol that is described using a simple

linear sequence of states. A POP3 session begins with a POP3 client making a TCP

connection to a POP3 server, at which point the session is in the Authorization state.

After successful authentication, the session moves to the Transaction state, where the

client can perform mail access transactions. When it is done, the client ends the session

and the Update state is entered automatically, where cleanup functions are performed and

the POP3 session ended.

POP3

Authorization State: User Authentication Process and Commands

A session between a POP3 client and a POP3 server begins when the client sends a TCP

connection request to the server. The connection is established using the standard TCP

“three-way handshake”, and the POP3 session commences. The first of the three states of

a POP3 session is the Authorization state, which is responsible for authenticating the POP3

client with the server.

When the session first enters this state, the server sends a greeting message to the client.

This tells the client that the connection is alive and ready for the client to send the first

command. An example of such a greeting would be:

+OK POP3 server ready

The client is now required to authenticate the user who is trying to access a mailbox. This

both proves that the user has the right to access the server, and identifies the user so the

server knows which mailbox is being requested.

Standard POP3 Authentication

The normal method of authorization in POP3 is a standard “username / password” login.

This is pretty much identical to how a login is performed in FTP; even the commands are

the same. First the client issues a USER command along with the user's mailbox name (his

or her user name or e-mail address). The server responds with an intermediate acknowl-

edgment. The client then uses the PASS command to send the user's password. Assuming

the login is valid, the server responds to the client with an acknowledgment that indicates

successful authentication. The response will also typically specify the number of messages

waiting for the user in the mailbox. This process is illustrated in Figure 307.

Figure 306: Post Office Protocol (POP3) Finite State Machine

POP uses a finite state machine to describe its operation, but it is very simple because it is linear. Once a TCP

connection is established between a POP3 client and POP3 server, the session proceeds through three states

in sequence, after which the connection is terminated.

(No Connection)

AUTHORIZATION

TRANSACTION

UPDATE

Successful Authentication

Establish TCP Connection

Done With Transactions;

Issue QUIT Command

Delete Marked Messages,

Release Resources,

Terminate Connection

Table 257 shows an example POP3 authorization, with the client's commands highlighted

and the server's responses in italics.

Note: Some servers may require only the name of the user (“jane”) while others

require the full e-mail address as shown in the example. Also, I have not shown

Jane's password in Table 257; that wouldn't be very nice, would it? ☺

Figure 307: Post Office Protocol (POP3) User Authentication Process

Once the TCP connection is established from the client to the server, the server responds with a greeting

message, and the simple POP3 authentication process begins. The client sends a user name and password

to the server using the USER and PASS commands, and the server evaluates the information to determine

whether or not it will allow the client access.

Table 257: Example POP3 Authorization

+OK POP3 server ready

USER jane@somewhereelse.com

+OK

PASS *******

+OK jane@somewhereelse.com has 3 messages

POP3 ServerPOP3 Client

(TCP)

1. Establish TCP

Connection To Server

2. Establish TCP Connection,

Send +OK "Ready" Reply

3. Receive "Ready" Reply,

Send User Name

+OK (Ready)

USER

5. Receive Reply,

Send Password

7. Receive "Greeting"

Reply, Transition to

TRANSACTION State

4. Receive User Name,

Send +OK Reply

+OK

PASS

6. Receive Password, Send

+OK "Greeting" Reply With

Number Of Inbox Messages

+OK (Greeting)

If authorization is successful, the POP3 session transitions to the Transaction state where

mail access commands can be performed. If the user name or password are incorrect, an

error response is given and the session cannot proceed. The authorization may also fail

due to technical problems, such as an inability by the server to lock the mailbox (perhaps

due to new mail arriving via SMTP).

Alternative Authentication Using APOP

Since user/password authorization is considered by many people to be insufficient for the

security needs of modern internetworks, the POP3 standard also defines an alternative

authentication method, using the APOP command. This is a more sophisticated technique

based on the MD5 “message digest” encryption algorithm.

If the server supports this technique, in its opening greeting it provides a string indicating a

timestamp that is unique for each POP3 session. The client then performs an MD5 calcu-

lation using this timestamp value and a “shared secret” known by the server and client. The

result of this calculation is included in the client's APOP command. If it matches the server's

calculation, authentication is successful; otherwise the session remains in the Authorization

state.

The Post Office Protocol was also designed to allow it to be extended through the addition

of other authentication mechanisms. This process is based on the use of the optional AUTH

command, as described in RFC 1734.

Key Concept: A POP3 session begins in the Authorization state, where the client

device is expected to authenticate with the server. By default, POP3 uses only a

simple username/password authentication method. Optional authentication methods

are also defined for applications requiring more security.

POP3

Transaction State: Mail and Information Exchange Process and Commands

Once the POP3 client has successfully authenticated the user who is performing mailbox

access, the session transitions from the Authorization state to the Transaction state. There's

no real mystery what this phase of the connection is all about: it is where the POP3 client

issues the commands that perform mailbox access and message retrieval transactions.

POP3 Transaction Commands

Most of the commands defined in POP3 are valid only in the Transaction state. Table 258

lists each of them, in the order in which they appear in RFC 1939.

Table 258: POP3 Transaction Commands

Command

Code

Command Parameters Description

STAT Status None

Requests status information for the mailbox. The server

will normally respond telling the client the number of

messages in the mailbox, and the number of bytes of data

it contains. Optionally, more information may also be

returned.

LIST List Messages

Optional

message

number

Lists information for the messages in a mailbox; generally

this means showing the message number and its size. If a

message number is given, only that message's infor-

mation is provided; otherwise, the full contents of the

mailbox are described, one line at a time, with a line

containing just a single period at the end.

RETR Retrieve

Message

number

Retrieves a particular message from the mailbox. The

server responds with a standard “+OK” message and then

immediately sends the message in RFC 822 format, one

line at a time. A line with a period by itself is sent after the

last line.

DELE Delete

Message

number

Marks a message as deleted. Once deleted, any further

attempt to access a message (using LIST or RETR for

example) results in an error.

NOOP No Operation None Does nothing; the server just returns a +OK reply.

RSET Reset None

Resets the session to the state it was in upon entry to the

Transaction state. This includes “undeleting” any

messages already marked for deletion.

TOP

Retrieve

Message Top

Message

number and

number of

lines

Allows a client to retrieve only the beginning of a message.

The server returns the headers of the message and only

the first N lines where N is the number of lines specified.

This command is optional and may not be supported by all

servers.

UIDL

Unique ID

Listing

Optional

message

number

If a message number was specified, returns a unique

identification code for that message; otherwise, returns an

identification code for each message in the mailbox.

This command is optional and may not be supported by all

servers.

Typical POP3 Mail Exchange Sequence

The Transaction state is relatively “unstructured” in that commands do not need to be

issued in any particular order to meet the requirements of the standard. However, there is a

natural progression to how a mailbox is retrieved, and that means the commands are

usually used in the following way:

1. The client issues a STAT command to see the number of messages in the mailbox.

2. The client issues a LIST command and the server tells it the number of each message

to be retrieved.

3. The client issues a RETR command to get the first message and if successful, marks it

for deletion with DELE. The client uses RETR/DELE for each successive message.

Figure 308: Post Office Protocol (POP3) Mail Exchange Process

This diagram shows the typical exchange of commands and replies employed by a POP3 client to retrieve e-

mail from a POP3 server. The STAT command is used to get mailbox statistics, followed by the LIST

command to obtain a list of message numbers. Each message in turn is then retrieved using RETR and

marked for deletion by DELE. (Messages are not actually deleted until the Update state is entered.)

POP3 ServerPOP3 Client

STAT

1. Request Mailbox Status

2. Receive STAT; Send +OK

Reply, Mailbox Size and

Number of Messages

4. Receive LIST; Send +OK

Reply, List of Message

Numbers and Sizes

3. Receive Statistics; Request

List of Messages In Mailbox

+OK

(Mailbox Statistics)

LIST

5. Re ce i ve Me ssa ge L i st,

Retrieve Message Number 1

+OK

(Message List)

RETR 1

6. Receive RETR;

Send +OK Reply, Then

Me ssa g e Te x t

+OK

(Message 1)

7. Receive Successful Reply,

Delete Message 1

DELE 1

8. Receive DELE; Mark

Message For Deletion,

Send +OK Reply

+OK

9. Receive Successful Reply,

Retrieve Message Number 2

RETR 2

10. Receive RETR;

Send +OK Reply, Then

Me ssa g e Te x t

+OK

(Message 2)

11. Receive Successful Reply,

Delete Message 2

DELE 2

12. Receive DELE; Mark

Message For Deletion,

Send +OK Reply

+OK

13. Receive Successful Reply,

Perform Other Transactions...

Table 259 and Figure 308 show a sample access sequence for a mailbox containing two

messages that are a total of 574 bytes; the client's commands are highlighted and the

server's responses are in italics.

The exact message sent in reply to each command is server-dependent; some just say

“+OK” while others provide more descriptive text as I have done here for the responses to

the DELE command.

In some cases, a POP3 client may be configured to not delete messages after retrieving

them. This is useful, for example, when Web-based access is being combined with a

conventional e-mail client program.

Key Concept: After successful authorization, the POP3 session transitions to the

Transaction state, where the client actually accesses e-mail messages on the server.

The client normally begins by first retrieving statistics about the mailbox from the

server, and obtaining a list of the messages in the mailbox. The client then retrieving each

message one at a time, marking each retrieved message for deletion on the server.

Table 259: Example POP3 Mail Exchange Process

STAT

+OK 2 574

LIST

+OK

1 414

2 160

RETR 1

+OK

(Message 1 is sent)

DELE 1

+OK message 1 deleted

RETR 2

+OK

(Message 2 is sent)

DELE 2

+OK message 2 deleted

QUIT