by May 6, 2001 0 comments

Last month we disscussed how the SMTP protocol works. In this sequel we’ll discuss the most widely used protocol for fetching e-mail from the mail server, the Post Office Protocol version 3 (POP3). We’ll also design a simple POP3 C# client to understand how to talk POP3 with a mail server. 

How you check e-mail 

POP3 was published, and later revised, in many RFCs (for example, 918, 937, 1125) to form a means to check or fetch e-mail. When an e-mail comes in for you on your e-mail server, the server stores the mail. You can then login to the server and check, reply, and work with your mail. 

There are two ways of logging in and working with received e-mail. The first and most popular approach is to login to your mail server via a Web interface. All Web-based e-mail services like Hotmail or Yahoo! provide this interface, and some of them provide only this interface to work with e-mail received. This method hides the complexities, like the name or IP address of the e-mail server and its type. All you need to do is visit the e-mail service’s website and login. You don’t need to know any more details, which the second approach requires.

The other way of working with received e-mail is to use e-mail client software like Outlook Express, Eudora, or Pegasus Mail. When working with these e-mail clients, you need to know details like the outgoing server (SMTP server) and the incoming server (usually POP3, but can be the Interactive Mail Access Protocol (IMAP) server as well) to configure the e-mail client. You fill in particulars like the name or the IP address of your incoming server, what type it is (POP3 or IMAP), and the username and password required for authenticating with the mail server in your mail client; and give the command to check mail. The e-mail client software then talks POP3 (or IMAP) with the incoming mail server and lets you work with received mail.

The POP3 protocol

This receives mail for the user and stores them, until the user logs on and fetches them.

\Interacting with a POP3 server involves three stages:

  • Authorization state: In this state, the POP3 client sends the username and password to the POP3 server for authentication. If the user is successfully authenticated, the next state of Transaction is entered. Otherwise, the client is disconnected by the server.
  • Transaction state: The client issues POP3 commands to the server for working with mail, like getting the mail size, fetching mail, deleting mail, etc.
  • Update state: Once all required transactions have been made, the Update state lets the client disconnect from the server, and lets the server release any resources used during the client’s transaction.
    The POP3 protocol contains various commands, which have been logically distributed across the above three states, and can be used only in their respective states. Let’s take a look at these commands.

The mechanics

To start a conversation with a POP3 server, the client connects to port 110 on the server, which is the standard port at which the server listens for incoming POP3 client requests. Once the client is connected to the server, the server sends it a greeting, something like below. S represents the server, and C represents the client:

S: +OK gPOP3 service ready

The POP3 specification defines two status codes: ‘+OK’ indicates a positive reply from the server in response to an action requested by the client, while ‘—ERR’ indicates a negative reply from the server. This is in contrast to the SMTP protocol which, if you recall, uses three-digit number codes as status indicators for a client request. 
Once a positive greeting is received from the server, the client enters the authorization state with the server by issuing the ‘USER’ command, to send the username to server:

C: USER gaurav

Each command sent by the client must be suffixed by a CRLF (carriage return-linefeed), as instructed in the POP3 RFC.
If the user holds an account on the server, the server will send a positive reply, so that the password can be sent in. Otherwise, the server sends a negative reply. Assuming a positive reply to the USER command, the client sends in the password using the ‘PASS’ command:

C: PASS secret

The server then matches the password to the one stored in its database for the concerned username. If they match, a positive reply is sent. Otherwise, a negative reply is received by the client.

Once the username and password have been successfully accepted by the POP3 server, the authorization state is complete and the server/client enter the transaction state, wherein the client issues commands for working with mail.

The ‘STAT’ command is used to get a count of number of messages present in the inbox, along with their total size:


The server replies as follows:

S: +OK 2 560

The reply consists of two octets after the positive +OK. The first one, in this case 2, is the count of messages present in the inbox. The second octet gives you the total size of the two messages. However, the reply to the STAT command doesn’t contain messages marked for deletion on the server.

The ‘LIST’ command takes an optional parameter, which is a message ID. The command is used to return the scan-listing for the message ID requested, or all the messages if no message ID is given. The scan-listing contains the message ID as the first octet, and the message size as the second octet:


The server replies as:

S: +OK 2 messages (250 octets)
S: +OK 1 150
S: +OK 2 100
S: .

Since a message ID wasn’t provided to the LIST command, the server returns the scan listing for all messages. After the scan listings have been given for all messages, the server terminates the response by sending a period in the end. Note that all the replies are terminated by a CRLF. Had a message ID been provided:


the server would’ ve replied as:

S: +OK 2 100

In case a message ID was given which didn’t exist:


the server would have replied something like:

S: -ERR no such message exists

Next we come to one of the most important commands of the POP3 protocol: ‘RETR’. The command takes a message ID and fetches it from the mail server. In case the message specified by the message ID isn’t present or has been marked for deletion, the server returns a negative response. 


The server replies as:

S: +OK 100 octets
S: <the message is sent here as a chunk of bytes>
S: .

The server signals the end of a message by sending a single period. 

Finally, to delete a mail, we have the ‘DELE’ command, which takes the message ID of the message to be deleted:


As usual, the message ID cannot refer to a message already marked for deletion. If successful, a positive reply is sent by the server and the message is marked for deletion. It isn’t deleted until the POP3 session enters the update state.

The POP3 session enters the update state when the client issues the QUIT command


The server replies as positive and releases all resources used by the current POP3 session after terminating the connection with the client. Also, all mail that was marked for deletion is now permanently deleted from the server.
Our POP3 session ends now, and we’ll move on to coding a POP3 client in C# on page 133. 

Kumar Gaurav Khanna runs

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.