How Fetching Email Through the Post Office Protocol Works

A Behind the Scenes Look at POP3

Email inbox

Epoxydude / Getty Images

The Post Office Protocol (POP) used to retrieve mail from a remote server is a very simple protocol. It defines the basic functionality in a straightforward manner and is easy to implement. Of course, it is also easy to understand.

Let's find out what happens behind the scenes when your email app fetches mail in a POP account. First, it needs to connect to the server. Most of this is hidden behind the scenes in a matter of seconds and you never see it. You just log in to the app and see your email.

Hi, It's Me

Usually, the POP server listens to port 110 for incoming connections. Upon connection from a POP client (your email program), it will hopefully respond with +OK ready or something similar. The +OK indicates that everything is OK. Its negative equivalent is -ERR, which means something has gone wrong. Maybe your email client has already shown you one of these negative server replies.

Logging On

Now that the server has greeted us, we need to log on using our username (let's suppose the username is "platoon"; what the server says is printed in italics):

+OK ready
USER platoon

Since a user with this name does exist, the POP server responds with +OK and maybe some gibberish we don't really care about. Were there no such user at the server, it would, of course, make us panic with -ERR user unknown.

To make the authentication complete we also need to give our password. This is done with the "pass" command:

+OK send your password
pass noplato

If we type the password correctly, the server responds with +OK great password or whatever the programmer of the POP server had in mind. The important part again is the +OK. Unfortunately, passwords can also be wrong. The server notes this with a dry -ERR username and password don't match (as if you'd use your username as your password).

If everything went okay, though, we are connected to the server and it knows who we are, thus we're ready to peek at the newly arrived mail.

You've Got Mail!

After we have successfully logged in to our POP account at the server, we may first want to know if there is new mail at all and then possibly how much.

The command used to retrieve these basic mailbox statistics is STAT.

A possible server response would be +OK 18 67042. In this case, it does matter what follows the +OK sign. Immediately following is the number of messages in the mailbox, then, separated by a whitespace, comes the size of the mailbox in octets (an octet are 8 bits).

+OK 18 67042

If there is no mail, the server responds with +OK 0 0. Since there are 18 new messages on the server, however, we can list these using the LIST command. In response, the server lists the messages in the following format:

+OK 18 messages (67042 octets)
1 2552
2 3297
18 3270

The messages are listed one at a time, each followed by its size in octets. The list ends with a period on a line by itself.

The LIST command can take the number of a message as an optional argument, LIST 2 for example. The server's response to this request would be +OK 2 3297, the message number followed by the size of the message. If you try to list a message that does not exist, like LIST 23, the server shows no imagination and says: -ERR no such message.

The Big Retrieve (And Delete)

Now that we know how many messages are in our account and how big they are, it's finally time to retrieve them so we can read them too.

Now, after finding out whether we have new mail, comes the real thing. The messages are retrieved one by one with their message number as an argument to the RETR command.

The server responds with a +OK and the message as it is, in multiple lines. The message is terminated by a period on a line by itself. For example:

+OK 2552 octets
Blah! <POP server sends message here>

If we try to get a message that does not exist, we get -ERR no such message.

Now we can delete the message using the DELE command. (We can, of course, also delete the message without having retrieved it if it is one of those days).

It is good to know that the server will not purge the message immediately. It is merely marked for deletion. Actual deletion only happens if we regularly end the connection to the server. So no mail will ever be lost if the connection suddenly dies, for example.

The server's response to the DELE command is +OK message deleted:

+OK message 1 deleted

If it is indeed one of those days and we have marked a message for deletion that we do not want to be deleted, it is possible to undelete all messages by resetting the deletion marks. The RSET command returns the mailbox to the state it was in before we logged in.

The server responds with an +OK and possibly the number of messages:

+OK 18 messages

After we have retrieved and deleted all the messages it is time to say goodbye using the QUIT command. This will purge the messages marked for deletion and close the connection. The server responds with +OK and a farewell message:

+OK bye, bye

It is possible that the server was unable to delete a message. Then it will respond with an error like -ERR message 2 not deleted.