POP3: what RFC 1939 actually defines
A standards-first look at POP3: the download-and-delete protocol a client uses to fetch mail waiting on a server, and why it lost ground to IMAP.
Why early email needed a download protocol
A mailbox lives on a server the recipient doesn't run and, for most of email's history, wasn't continuously connected to. Dial-up links and early always-off connections meant a client couldn't stay logged in and watch a mailbox in real time. What that client needed was a minimal way to connect periodically, ask what's waiting, pull it down to local disk, and disconnect again. It didn't need a full server-side mailbox management interface with folders, flags, or server-side search. RFC 1939 scopes POP3 to exactly that narrow job.
What RFC 1939 defines
RFC 1939 defines the POP3 command and response cycle across three states, Authorization, Transaction, and Update, for retrieving, and by default deleting, messages from a server-side mailbox. Every session moves through those states in order: a client authenticates, does its retrieval work, then commits whatever it marked for deletion on the way out.
How POP3 works
The client opens a connection and authenticates, either with plain USER/PASS credentials or with the more secure APOP, which avoids sending a password in the clear. Once authenticated, it issues STAT or LIST to see how many messages are waiting and how large each one is.
RETR downloads a specific message by number. DELE marks that message for deletion, but doesn't remove it yet. Only QUIT commits the pending deletions and closes the session, the moment the protocol calls the Update state.
Anatomy
Command set:
| Command | Purpose |
|---|---|
USER | Sends the username, first step of authentication |
PASS | Sends the password |
STAT | Returns message count and total mailbox size |
LIST | Returns message numbers and sizes |
RETR | Downloads a specific message by number |
DELE | Marks a message for deletion |
RSET | Unmarks any messages flagged for deletion this session |
QUIT | Closes the session and commits pending deletions |
UIDL (optional) | Returns a unique ID per message, stable across sessions |
TOP (optional) | Downloads message headers plus a given number of body lines |
Three-state model:
| State | What's allowed |
|---|---|
| Authorization | USER/PASS or APOP only, nothing else until the client is authenticated |
| Transaction | STAT, LIST, RETR, DELE, RSET, TOP, UIDL, the working state for the session |
| Update | Entered on QUIT, the server deletes messages marked in the Transaction state and closes the connection |
A full session, traced
A client checks a mailbox with two messages, downloads one, and deletes it:
+OK POP3 server readyUSER alice+OKPASS ********+OK Logged inSTAT+OK 2 1024RETR 1+OK 512 octets followFrom: sender@example.comTo: alice@example.comSubject: Weekly reportReport contents here..DELE 1+OK Message 1 deletedQUIT+OK Bye, 1 message deleted
STAT reports two messages and a total mailbox size of 1024 octets before anything happens. RETR 1 streams the first message, ended by a line containing only ., the same body-termination convention SMTP uses. DELE 1 only marks the message. It's the final QUIT that commits the deletion and reports it back to the client.
Where POP3 falls short
POP3 has no native multi-device sync. Once one client deletes a message after RETR, a second client checking the same mailbox sees nothing, because the message is gone. Working around this means configuring "leave messages on server" in the client itself, a setting outside POP3's own model.
The protocol also has no concept of folders. A mailbox is a flat list of messages, with none of the server-side organization IMAP later added.
RFC 1939 defines no encryption of its own. A POP3 session runs in plaintext unless something else wraps it: STARTTLS upgrading the connection mid-session, or connecting directly over implicit TLS on port 995. Either way, that protection comes from outside the base RFC.
Check it yourself
Connect to a POP3 server over implicit TLS and issue commands by hand:
openssl s_client -connect yourdomain.com:995 -crlf
Type USER, then PASS, then LIST, one at a time, and read the raw +OK or -ERR response the server sends back after each one.
Where it fits
POP3 solves retrieval only, and it's one of two competing answers to the same question. IMAP is the folder-based, sync-capable alternative that keeps mail state on the server instead of deleting it on download. JMAP is the more recent JSON-based alternative built for HTTP-native clients.
POP3 and SMTP sit on opposite sides of the same mail flow: SMTP and message submission move a message toward a mailbox, POP3 moves it back out to a client. For the rest of the email standards this page sits inside, see the reference hub.
Nuntly's receiving pipeline works differently, delivering messages by webhook instead of any of these three protocols; see the receiving overview.
FAQ
Does POP3 delete messages from the server by default?
Yes. The default behavior downloads the message and removes it once the client commits with QUIT. Most modern clients add a "leave a copy on server" option, but that setting sits outside the base protocol's own model rather than inside it.
Is POP3 encrypted?
Not by RFC 1939 itself. Encryption gets layered on separately, either through STARTTLS or by connecting directly over implicit TLS on port 995.
Why did POP3 lose ground to IMAP?
Multi-device use. Once a POP3 client deletes a message after download, a second device checking the same mailbox sees nothing there. IMAP keeps mail state on the server instead and syncs every connected client against it.
Is APOP still recommended?
No. APOP's authentication scheme is now considered weak, and it's largely deprecated in favor of authenticating inside a TLS session instead.
RFC reference
RFCs covered: RFC 1939.
Superseded / updated by: None. RFC 1939 remains the current POP3 specification, though the APOP mechanism it defines is now largely deprecated for security reasons.