POP - Version 3

Introduction

The Post Office Protocol - version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. This means that the POP3 protocol is used to allow a workstation to retrieve (but not post) mail that the server is holding for it. As said before - this is the most common way today for retrieving electronic mail. The protocol is simple and functional. POP3 has replaced POP.

The server host starts the POP3 service by listening on TCP port 110. A client establishes a TCP connection with the server host. When the connection is established the server sends a greeting. Then the client and the server exchange commands and responses until the connection is closed or aborted. The server can respond with a positive status sending "+OK" to the client or with a negative status sending "-ERR" to the client (both in uppercase).

A POP3 session progresses through several stages during it lifetime: Authorization, Transaction and Update.

Now that you know a bit about POP3 you can either play a little game explaining the POP3 protocol or read the text below to know the exact protocol details.

The Authorization state

Once the TCP connection has been opened by the client, the server issues a greeting message starting with a positive response "+OK". Then the client has two possibilities: sending a user name and a password by USER and PASS commands or sending an encrypted password by the APOP command.

After verifying the identity of the client, the server acquires an exclusive access lock on the maildrop (in order to avoid message deletion before entering the Update state). If the lock isn't acquired the server responds with a negative status and may close the connection or stay in the Authorization state in order to allow issuing new authentication commands.

After the lock is acquired the server assigns each message a message number (starting with 1).

The commands allowed in the Authorization state are :

USER name

The client issue the USER command with the 'name' string which identifies the mailbox the client wishes to access. If the server "know" this client it responds with a positive status and then the client must issue the PASS command. If the server responds with a negative status, the client can either issue another USER command or issue a QUIT command.

 

PASS password

The client issues the PASS command immediately after the USER command. The 'password' is a string used to identify the client (both user name and password are required in order to acquire authorization). If the client should e given access to the mailbox, the server responds with a positive status and enter the Transaction state. Else it responds with a negative status and either terminates the connection or allow another authentication commands.

 

APOP name digest

The APOP command is based on the MD5 algorithm (dealt in RFC 1321). The client issues this command with its user name string and a 'digest' string. The digest string is derived from a time stamp the server sends with the greeting message (this form the encryption). The server (which hold the exclusive key to decrypt the 'digest' string sent by the client) verifies the digest string and issues a respond (positive or negative) as it did with the USER and PASS commands.

 

QUIT

The client can always issue the quit command. The server then responds with a positive status and closes the connection.

The Transaction state

After the client has successfully identified itself to the server, the server enters the Transaction state. Now the client may issue the above mentioned command and get responds from the server to each command. At last the client issue a QUIT command and the server enters the Update state.

The commands allowed in the Transaction state are :

STAT

The server responds with a positive status followed by a single space, the number of messages in the mailbox, another single space and the size of the mailbox in octets.

 

LIST [msg]

If an argument is given the server responds with a positive status followed by a single space, the message number, another single space and the size of the message in octets. In case there is no message numbered in msg, the server returns a negative status.
If no argument is provided than the server issues a positive status line and then the response given is multi line. For each message in the mailbox (not marked as deleted) the server responds with a line equal to the one issued in the above case. each line is terminated with a CR followed by a LF. The last line is a '.' character followed by a CRLF.

 

RETR msg

If a message numbered in msg exists than the server responds with a positive status and then sends the message and an ending line represented by '.' character and a CRLF. Else it returns a negative status.

 

DELE msg

The server marks the message (numbered in msg) as deleted (but doesn't delete it) and returns a positive status. If no message is numbered in msg then the server responds with a negative status.

 

NOOP

This command causes nothing but a positive response from the server.

 

RSET

If any message was marked as deleted by the server, they are unmarked. The server respond with a positive status.

 

QUIT

The server responds with a positive status and enters the Update state.

 

TOP msg n

If a message numbered in msg exists than the server responds with a positive status and then sends the headers of the message and the first n lines of the message, and finally terminate the multi line transaction as seem in LIST. Else the server returns a negative response.
Note that if the message has no more than n lines, the whole message is sent.

 

UIDL [msg]

If a parameter is provided than the server sends a positive status (if a message numbered in msg exists) followed by a single space and the unique-id listing of the message.
If a parameter is not provided than the server respond with a positive status and then with a multi line. For each message the server sends a line with the message number followed by a single space and the unique-id listing for the message. Finally it sends a multi line termination as in the LIST command.
Note that the server must provide this unique-id to each message in the mailbox.

The Update state

When the client issues the Quit command from the transaction state, the server enters the Update state.
The only command allowed in this state is QUIT. After getting the QUIT command the server deletes all the messages marked as deleted, releases the access lock and closes the TCP connection.

Supplements

• No automatic message deletion is provided by the POP protocol. Hence the server operators may include automatic message deletion after a desired period of time.
• The server can not know if a client was disconnected unless the client issued The QUIT command. Hence the server operators may include an inactivity autologout timer. Such timer must be of at least 10 minutes duration. When the timer expires the session doesn't enter the Update state. The server then should close the connection. A POP client program may issue a NOOP command every now and then to avoid timeout disconnection, but usually the client program simply reconnects when needed.

Now that you're done reading take a minute to play a little game explaining the POP3 protocol.

References:
RFC 918  - POP Version 1
RFC 937  - POP Version 2
RFC 1081 - POP Version 3
RFC 1225 - POP Version 3
RFC 1460 - POP Version 3
RFC 1725 - POP Version 3
RFC 1939 - POP Version 3
RFC 1957 - POP Version 3 (observations)