POP sessions are very straightforward. They begin with a TCP socket connection from a POP client to TCP port 110 on a POP server. Once connected, the server issues a banner greeting, consisting of a positive status indicator (+OK) and a comment. When the client receives the banner greeting, the POP session has begun.

The first action that a client must take is to issue one of the Authorization State commands to log into a POP mailbox. The client chooses the authentication mechanism that it prefers, and the server must accept or reject it. If the server rejects the client’s advances, it issues a negative status indicator (-ERR), and the client may try again. There is no limit on the number of times that a client may try to find an authentication mechanism that the server will accept.

Once the server accepts the client’s authentication, it locks the chosen mailbox and responds with a positive status indicator. This tells the client that the server is now in the Transaction State. The client may now issue any commands valid in the Transaction State.

At this time, the client may issue any Transaction State commands that it sees fit, in any order. Typically, a client issues a STAT command in order to determine the number of messages in the mailbox followed by a series of RETR and DELE commands to retrieve and mark for deletion every message in the mailbox. When all messages have been processed, a QUIT command is issued to close the session.

This typical example session is illustrated in Figure 10-3. In the figure, actions taken by the client and server are shown in parentheses and multiline data abbreviated in angle brackets. Other text shows the literal POP commands and server responses. Note that at the beginning of the session, the client tries a more secure authentication mechanism but is rejected by the server. This shows a server response to an error condition.

When the client issues a QUIT command in the Transaction State, the server has to choose whether or not to enter the Update State in order to delete messages marked for deletion. The server also unlocks the mailbox and closes the TCP socket.

Figure 10-3. A sample POP3 session

Complex POP sessions may include a more interesting set of transaction commands. Clients that are sensitive to a user’s lack of bandwidth may use the TOP command to download the headers of messages upon login, then keep the POP session alive with NOOP commands while the user decides which to delete.

Email users concerned with the privacy of their email may elect to use only POP clients and servers with transmission security, implemented either in the manner discussed in this chapter or over a transparently secure socket (in the case of Netscape’s Secure Socket Layer technology) or on top of a secure shell (ssh) communication.

An automated process watching a POP mailbox for similar messages may use the UIDL command to differentiate the messages without parsing them. The possibilities are as varied as the uses of email.

POP is a simple and reliable protocol for remotely retrieving electronic mail. With the recent extensions to the protocol, enhanced security has become possible. Many users on the Internet today are waiting for programmers to create these secure POP servers and the clients that can access them.