13.4. POP3

Overview

Post Office Protocol version 3, or POP3, is one of the classic protocols used for receiving email from a mail server to an email client. It focuses on downloading messages from a server mailbox to a local device, usually with the goal of storing them locally and keeping the server mailbox relatively empty. POP3 is older than many modern approaches, yet it is still found in many email clients and services, particularly in simple, single-device setups.

POP3 sits at the application layer and works over a reliable transport connection, which is typically TCP, but details of TCP itself are covered elsewhere. Here the focus is on how POP3 behaves from a user and protocol point of view, not on how the underlying transport works.

Typical POP3 Usage Pattern

In a common POP3 setup, a user configures an email client, such as a desktop application, with the POP3 server address, a username, and a password. Once connected, the client logs in, lists available messages, downloads new ones, optionally marks them for deletion on the server, and then logs out. After this, the server mailbox might be left empty or contain only messages that were not deleted.

Unlike protocols that maintain a long-term synchronized view of server folders and states, POP3 focuses on short, self-contained sessions. Each time the client connects, it repeats the basic steps of logging in, checking for messages, dealing with them, and disconnecting.

POP3 Connection and Ports

POP3 uses TCP as its transport and has two well-known port numbers in practice. The original, unencrypted form of POP3 commonly uses TCP port 110. When encryption is added from the start of the connection, a variant often called POP3S typically uses TCP port 995.

Modern deployments strongly prefer encrypted access, so POP3S on port 995 or the use of encryption negotiated after connection setup is common. The exact method of enabling encryption depends on the server and client configuration, but the key point is that unencrypted POP3 should be avoided on untrusted networks.

POP3 Session States

POP3 defines a clear sequence of states for a connection, which helps both server and client keep behavior predictable. The three main states are:

1. Authorization state.
2. Transaction state.
3. Update state.

When a client first connects, it is in the authorization state. In this phase, the client must prove its identity, typically with a username and password, before it is allowed to interact with messages. Once authentication is successful, the session moves into the transaction state. Here, the client can list messages, retrieve them, mark them for deletion, and perform related operations. When the client sends the command to end the session, the server moves into the update state, where it applies any pending deletions and finalizes the mailbox, then closes the connection.

The separation of states means that no message manipulation happens before successful authentication, and that actual deletions only take effect once the session is properly closed. This reduces the risk of leaving the mailbox in an inconsistent state if the connection drops unexpectedly.

Command and Response Style

POP3 uses a simple, text based command and response format. The client sends short commands, written as text lines, and the server replies with simple status indicators followed by additional data when needed.

A typical success response line from the server starts with the characters +OK. An error or failure usually starts with -ERR. More data, such as lists of messages, may follow on additional lines and often uses a terminating line that contains only a single period character.

This style of interaction makes POP3 easy to read and test manually with basic tools, since the client and server communicate with clear, human readable text commands and replies.

Core POP3 Commands

POP3 defines a small set of commands that control the entire interaction with the mailbox. Only a few of these are strictly required for basic operation, while others add convenience or optional capabilities. The most important commands include:

1. USER and PASS.
2. STAT.
3. LIST.
4. RETR.
5. DELE.
6. NOOP.
7. RSET.
8. QUIT.

In the authorization state, the client usually begins by sending USER followed by the account name, and then PASS followed by the password. Once the server responds with a success message, the client can proceed.

In the transaction state, STAT provides a quick summary of how many messages are in the mailbox and the total size of all of them in bytes. LIST gives message by message information, either for all messages or for a specific one, such as size and message number. RETR retrieves the full content of a message identified by its number, allowing the client to download and store it locally.

DELE marks a message for deletion so that it will be removed from the mailbox when the session ends successfully. NOOP performs no action other than keeping the connection active and confirming that the server is still responsive. RSET clears any deletion marks that were set during the current session, so that messages remain in the mailbox when the session closes. Finally, QUIT signals that the client wants to end the transaction. At that point, the server moves to the update state, applies deletions, and terminates the connection.

The simplicity of these commands reflects POP3’s focus on a single main task, which is to download and optionally delete messages.

Message Handling Model

POP3 treats the mailbox as a single list of messages, each identified by a message number for the duration of a given session. These numbers are not stable across sessions. When the client connects again, the numbering can change based on what was deleted earlier and what new messages have arrived.

During a session, the client decides how to handle each message. A common pattern is to retrieve each new message with RETR, then mark it with DELE. After QUIT, these messages are removed from the server mailbox. This model naturally leads to a style where the server is used primarily as a temporary holding area, and the long term storage of messages is on the client’s local device.

Some servers and clients support leaving a copy of messages on the server, sometimes only for a limited time, such as a few days. This is implemented by simply not using DELE on those messages, or by using client side rules that control when to delete. Even in these cases, POP3 itself still adheres to the basic model of listing, retrieving, and optionally deleting messages per session.

Simple POP3 Session Example

To see how POP3 works in practice, imagine a minimal session between a client and server. After the client connects to the server’s POP3 port, the server sends a greeting line starting with +OK to show that it is ready. The client then sends USER with the mailbox name, and the server responds with +OK if this name is acceptable. Next, the client sends PASS with the password, and again expects a +OK response. At this point, the session is in the transaction state.

The client might then send STAT to learn how many messages are present and the total size. If there are messages, it can use LIST to see message numbers and sizes individually. For example, the server might respond that there are three messages with specific sizes. The client chooses one, sends RETR 1, and the server responds with +OK followed by the message content over multiple lines, ending with a line containing only a period. After saving or processing the message, the client may send DELE 1 to mark it for deletion.

When the client is finished with all required actions, it sends QUIT. The server then moves to the update state, deletes any messages that were marked by DELE during the session, and replies with a final +OK before closing the connection.

Even with this simplified example, the full life cycle of authentication, message handling, and closing is visible, and it illustrates how straightforward the core of POP3 is.

POP3 and Multi-device Access

Although POP3 can be used from multiple devices, it is not primarily designed to maintain consistent state across them. Since the main model is download and delete, one device that connects first can remove messages from the server, leaving nothing for others to fetch later. Some users configure their clients to leave copies on the server specifically to reduce this problem, but POP3 itself does not track read or unread status separately for each device, and it does not provide rich folder structures.

This approach contrasts with protocols that are more focused on server based storage and synchronization, which are addressed in other parts of this course. POP3 remains useful where a single client is responsible for collecting messages, or where local storage and minimal server usage are desired.

Security Considerations

POP3 in its original form transmits credentials and message content in clear text over the network, which is unsafe on any untrusted path. Modern deployments address this by using encryption for the entire session. This can happen by connecting directly to a port dedicated to encrypted POP3, such as 995, or by negotiating encryption after the initial connection before sending any sensitive information.

There are also extensions that allow more secure authentication methods, which avoid sending plain passwords. The main lesson for practical use is that POP3 should be combined with proper encryption and secure authentication on any public or shared network. Keeping the protocol simple does not remove the need for careful protection of user data during transit.

Views: 54