Post Office Protocol Version 3 (POP3)

If one characteristic defines POP3 and distinguishes it from all other email protocols, it is the download-and-delete model. This operational philosophy—that messages should be retrieved from the server, transferred to the client, and then removed from the server—shapes everything about how POP3 works and when it's appropriate to use.

This model wasn't arbitrary. It was a deliberate engineering decision reflecting the technological constraints and usage patterns of the 1980s. Understanding it deeply reveals both the power and the limitations of POP3.

The download-and-delete model reflects a clear philosophy: the client, not the server, is the permanent home for email.

In this model:

1. Mail arrives at the server and waits in the mailbox
2. User connects via POP3 and authenticates
3. Messages are downloaded completely to the local client
4. Messages are marked for deletion on the server
5. Session ends (QUIT command) and deletions are committed
6. Server mailbox is empty; all mail now resides only on the client

This creates a one-way flow: server → client. Once mail is downloaded, the server is done with it.

Why This Design?

The download-and-delete model addressed real constraints of its era:

The Implicit Contract:

Using POP3 with download-and-delete implied:

• You take responsibility for your mail once downloaded
• The server is a temporary holding area, not an archive
• You back up your own machine to prevent mail loss
• Your local computer is the source of truth for your email history

POP3's deletion mechanism is deliberately two-phase, providing safety against accidental data loss.

Phase 1: Marking for Deletion (DELE command)

During the TRANSACTION state, the DELE command marks a message for deletion but doesn't actually remove it:

Important Details:

• The +OK Message n deleted response is misleading—the message is marked, not deleted
• Marked messages are excluded from subsequent LIST and RETR commands in the same session
• Attempting to DELE the same message twice returns an error
• The message number n is session-specific, assigned when the session begins

Phase 2: Committing Deletions (UPDATE state)

Deletions only become permanent when the session enters UPDATE state via the QUIT command:

Why Two Phases?

The two-phase approach provides transaction safety:

1. Network reliability: If the connection drops before QUIT, no mail is lost
2. Client crashes: A crashed client loses connection without issuing QUIT—mail preserved
3. User error recovery: RSET command can unmark all deletions during the session
4. Download verification: Client can verify all messages downloaded before committing deletions

The RSET Safety Net:

The RSET (Reset) command unmarkes all messages marked for deletion:

Understanding how POP3 identifies messages is crucial for implementing the download-and-delete model correctly.

Session-Local Message Numbers:

POP3 assigns each message a temporary ordinal number (1, 2, 3...) when a session begins. These numbers:

• Are valid only for the current session
• Are assigned sequentially starting from 1
• Change after messages are deleted and a new session begins
• Are NOT persistent identifiers

The Problem with Temporary Numbers:

Temporary message numbers create challenges:

1. State tracking: Clients can't remember "download message 5 next time" because 5 might not exist or might be a different message
2. Partial downloads: If interrupted mid-session, how do you resume without re-downloading everything?
3. Leave-on-server: If keeping messages on server, how do you know which you've already downloaded?

The UIDL Solution:

RFC 1939 introduced the UIDL (Unique ID Listing) command to solve this problem:

How Clients Use UIDL:

1. First session: Download all messages, record their UIDs locally
2. Subsequent sessions: Get UIDL list, compare with recorded UIDs
3. New messages: Any UID not in local records is new—download it
4. Already downloaded: Skip messages with known UIDs

This enables reliable "Leave on Server" functionality without re-downloading messages.

As computing evolved, the pure download-and-delete model became problematic. Users wanted:

• Access from multiple computers (home, work, laptop)
• Ability to check email via webmail
• Protection against local machine failure

Email clients responded with "Leave messages on server" options—a modification of POP3 behavior that keeps messages on the server after download.

How Leave-on-Server Works:

1. Client downloads messages normally (RETR command)
2. Client does NOT issue DELE command
3. Client tracks downloaded UIDs locally
4. On next connection, client checks UIDL against local records
5. Only new messages (unknown UIDs) are downloaded

Implementation Challenges:

Common Client Options:

Modern email clients typically offer these leave-on-server variations:

Best Practice Configuration:

The download-and-delete model has profound implications for storage architecture—both on servers and clients.

Server-Side Storage:

Mailbox Size Impact on Performance:

POP3 performance degrades as mailbox size increases:

1. Session initialization must scan and index all messages
2. STAT command must calculate total message count and size
3. LIST command returns potentially huge lists
4. UIDL command similarly affected
5. Exclusive locking duration increases with mailbox size

Traditional POP3 mailbox formats (mbox, Maildir) weren't designed for thousands of messages. Leave-on-server pushes them beyond their design limits.

Client-Side Storage:

With pure download-and-delete, the client becomes the primary storage:

The download-and-delete model introduces specific data loss risks that users and administrators must understand.

Scenario Analysis:

Protection Strategies:

Mitigating download-and-delete risks requires deliberate action:

Different users have different needs. Here are common workflow patterns built around the download-and-delete model.

Pattern 1: Single-Device Primary

Pattern 2: Desktop + Webmail

Pattern 3: Archival Collector

Pattern 4: Privacy-Focused

While POP3's core model assumes complete message downloads, the TOP command provides an optimization for previewing messages without full retrieval.

The TOP Command:

Use Cases for TOP:

Important Limitations:

1. TOP is optional: Not all servers implement it (though most do)
2. No partial body retrieval: You can't get "bytes 1000-2000"—only from start
3. No multipart intelligence: TOP doesn't understand MIME structure
4. Attachments: Large attachments still require full RETR to access

The download-and-delete model is POP3's defining characteristic—and understanding it is essential for correct, safe email management. Let's consolidate:

What's Next:

With the download-and-delete model understood, we'll examine the POP3 command set in detail. The next page covers all standard POP3 commands, their syntax, responses, and practical usage patterns.