Skip to content

POP3

SMTP gets a message as far as the recipient's mail server. Getting it from that server onto the phone or laptop where someone actually reads it is a different job, handed to a different protocol entirely — and the oldest of the two still in wide use, POP3, makes one design assumption that shapes everything about how it behaves: it assumes you have exactly one device.

Download, then forget

POP3 — Post Office Protocol, version 3, specified in RFC 1939 — models email retrieval the way a physical post office box works. Mail accumulates at the server. A client connects, downloads everything waiting, and by default tells the server to delete what it just took. The server's job, once that happens, is done; it isn't expected to remember which messages you've read, which you've flagged, or which folder you filed something into, because none of that concept exists in the protocol at all. There are no folders on the server side in POP3 — only one flat pile of messages waiting to be collected.

That model matches its era well. In the 1990s, "checking your email" usually meant one computer, one modem connection, download everything, disconnect, and read at leisure — bandwidth and connection time were the scarce resources, not server storage. A design that clears the server as it goes made complete sense when a mailbox was a temporary holding area for one machine, not a shared source of truth for several.

Three states, one direction

A POP3 session moves through exactly three states, in strict order, and never goes backward:

  1. Authorization — the client identifies itself. The connection starts here and nothing else is possible until authentication succeeds.
  2. Transaction — the client can list, retrieve, and mark messages for deletion. This is where the actual work happens.
  3. Update — triggered the moment the client sends QUIT. The server permanently deletes anything marked for removal during the transaction state, then closes the connection.

That last state matters more than it looks: nothing marked for deletion is actually gone until QUIT completes the session cleanly. If the connection drops mid-session — a lost Wi-Fi signal, a crashed client — nothing gets deleted, and the next connection sees the mailbox exactly as it was before.

A real session, command by command

POP3 runs over TCP port 110, in plain ASCII, one command per line:

+OK POP3 server ready
USER alice
+OK
PASS hunter2
+OK Logged in
STAT
+OK 3 4096
LIST
+OK 3 messages
1 1024
2 1536
3 1536
.
RETR 1
+OK 1024 octets follow
From: [email protected]
Subject: Hi
...
.
DELE 1
+OK Message deleted
QUIT
+OK Bye

STAT reports the count and total size of waiting messages — 3 4096 means three messages, 4096 bytes total. LIST breaks that down message by message, each line giving a message number and its size, terminated by a line containing only a period — the same end-of-data marker seen in SMTP's DATA command. RETR downloads one message in full; DELE only marks it for deletion, which is why the delete doesn't actually take effect until QUIT moves the session into the Update state described above.

Notice PASS hunter2 traveling as plain text. Like the equivalent moment in FTP's USER/PASS exchange, an unencrypted POP3 session exposes the account password to anything positioned to observe the connection.

Use POP3S, not plain POP3, for anything beyond a local test

Plain POP3 on port 110 sends credentials in cleartext. Production mail clients should connect to POP3S on port 995, which wraps the entire session in TLS from the first byte, or use STLS to upgrade an existing port-110 connection — the POP3 equivalent of the STARTTLS command already seen in SMTP. Any client still defaulting to plain port 110 against a real mailbox is one packet capture away from a leaked password.

Why POP3 feels outdated

The download-and-delete model breaks down the instant a person has more than one device. Check mail on a laptop, and by default POP3 removes those messages from the server — meaning a phone checking the same account moments later never sees them at all. Most modern POP3 clients soften this with a "leave messages on server" option, but that's a workaround bolted onto a protocol whose default behavior actively fights multi-device use, not a real fix — the server still has no concept of "read on the laptop, so don't show as new on the phone," because POP3 has no notion of message state at all beyond "downloaded" or "not yet downloaded."

That gap is exactly what IMAP was designed to close.

Practical scenario: a message that vanished from one device

A user reads an important email on their laptop in the morning, then reports at lunch that the same message is nowhere to be found on their phone — not in the inbox, not in spam, gone entirely. Nothing in the mail server's logs shows any error; the message was delivered and retrieved successfully.

The mail server's own log for the account shows the answer directly:

09:14:02 pop3d: alice: LOGIN
09:14:03 pop3d: alice: RETR 42
09:14:03 pop3d: alice: DELE 42
09:14:03 pop3d: alice: QUIT (2 messages deleted)

The laptop's mail client is configured for plain POP3 with the default behavior: retrieve, then delete. At 09:14, it downloaded message 42 and told the server to remove it — and by the time QUIT completed the session, that message no longer existed on the server for anything else to find. The phone isn't broken and neither is the server; the laptop's client did exactly what POP3's default tells it to do. The fix is either enabling "leave a copy on the server" in the laptop's client settings, or moving the whole account to IMAP, which doesn't have this failure mode because it was never designed around deleting from the server as the normal case.

Practice exercises

  1. Using telnet <mail-server> 110 against a test account (never a production mailbox, since a mistyped DELE is permanent once QUIT runs), walk through USER, PASS, STAT, LIST, and RETR by hand.
  2. Explain, using the three-state model above, exactly when a message marked with DELE actually disappears from the server — and what happens to that mark if the connection drops before QUIT.
  3. A support ticket says "email works on my computer but my phone shows nothing new, even though I know new mail arrived." Using this article's scenario as a template, describe the one client setting you'd check first, and why.

Sources