What this RFC defines
RFC 1939 defines POP3 (Post Office Protocol version 3), the protocol used by email clients to download messages from a mail server to a local device. POP3 connects to the server, authenticates, retrieves messages (typically deleting them from the server), and disconnects.
Where you see it in practice
When you configure a mail client with POP3 settings (server: mail.yourprovider.com, port 995, SSL), those settings follow RFC 1939’s command set. The USER and PASS commands for authentication, the LIST command to see available messages, and the RETR command to download them are all defined here. POP3 is still widely deployed for simple download-and-delete use cases where multiple-device sync is not required.
How it connects to other RFCs
RFC 1939 is the current POP3 standard. RFC 2449 (CAPA command) extends POP3 to let clients discover server capabilities. RFC 8314 mandates TLS for POP3 connections, making port 995 with implicit TLS the correct modern configuration. For multi-device sync scenarios, IMAP (RFC 9051) is the modern alternative.
Current status
RFC 1939 is the current POP3 standard, published May 1996. Despite its age, it is actively used and has not been superseded. Modern POP3 deployments combine RFC 1939 with RFC 2449 (capabilities) and RFC 8314 (TLS requirements).
POP3 command set
RFC 1939 defined POP3 with a minimal command set: USER, PASS, STAT (mailbox stats), LIST (message sizes), RETR (retrieve message), DELE (mark for deletion), NOOP, RSET (undo pending deletions), TOP (retrieve headers only), UIDL (unique message ID), and QUIT. The protocol is stateful in a limited way: pending deletions are only committed when the client sends QUIT, allowing the client to abort a session cleanly if a network error occurs mid-download. This design makes POP3 simple to implement compared to IMAP, at the cost of expressiveness.
Download-and-delete versus leave-on-server
POP3 was originally designed for download-and-delete workflows: fetch messages to a local mailbox, then remove them from the server to save space. Modern POP3 clients typically default to leave-on-server behavior, downloading a copy while keeping the original for other devices. This is a client-side policy; the protocol itself always requires an explicit DELE command to remove messages. The UIDL command allows a client to identify messages it has already downloaded and skip them on subsequent sessions.
POP3 versus IMAP in 2026
POP3 remains supported as an option on every major mail service but is the retrieval protocol only for a shrinking minority of users. IMAP dominates because it supports multiple concurrent clients, server-side folders, search, flags (read, replied, flagged), and partial fetches. POP3 has none of these. However, POP3 has one persistent advantage: it downloads the full message and stores it locally, so the client works offline without any special configuration. If your local internet is unreliable, POP3 is still a reasonable choice; if you use multiple devices, IMAP is essential.
RFC 1939 (May 1996) defines POP3 (Post Office Protocol version 3): a simple mail retrieval protocol that downloads messages from server to client, typically deleting them from the server after retrieval. Simpler than IMAP: stateless single-mailbox model with a small command set. Ports 110 (STLS via RFC 2595) or 995 (implicit TLS per RFC 8314). Still deployed but eclipsed by IMAP for multi-device users. Suits single-device users with limited connectivity or specific offline workflows.
RFC 1939 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Simple mail retrieval: download messages from server to client |
| Model | Single mailbox (typically INBOX); download then optionally delete |
| Ports | 110 (cleartext + STLS), 995 (implicit TLS) |
| vs IMAP | POP3 is stateless download-then-delete; IMAP is stateful server-side folder structure with partial fetches |
| Published | May 1996 (obsoletes RFC 1725) |
| Status | Stable and widely deployed; niche vs IMAP for modern use |
Core POP3 commands
| Command | Purpose | State required |
|---|---|---|
CAPA | List server capabilities (RFC 2449 extension) | Any |
STLS | Upgrade to TLS (RFC 2595) | Not authenticated |
USER | Provide username | Not authenticated |
PASS | Provide password | Post-USER |
APOP | Challenge-response authentication (legacy MD5) | Not authenticated |
STAT | Number of messages and total mailbox size | Authenticated |
LIST | List message numbers and sizes | Authenticated |
UIDL | List unique IDs for messages (per RFC 1939) | Authenticated |
RETR | Retrieve a message | Authenticated |
DELE | Mark message for deletion (on QUIT commit) | Authenticated |
RSET | Undo pending deletions in session | Authenticated |
TOP | Retrieve message headers plus N body lines | Authenticated |
NOOP | Keep-alive; no operation | Any |
QUIT | End session; commit deletions | Any |
POP3 session example
POP3 vs IMAP comparison
| Aspect | POP3 (RFC 1939) | IMAP (RFC 3501) |
|---|---|---|
| Message storage | Client (after download) | Server (client syncs view) |
| Folders | Single (INBOX) | Full folder tree |
| Multi-device sync | Poor (each device has its own copy) | Excellent (shared state) |
| Partial fetch | Full messages only (TOP is header + N lines) | Any part of any message |
| Server-side search | Not supported | Yes (SEARCH command) |
| Message flags | Not supported | Yes (\Seen, \Flagged, etc.) |
| Real-time notifications | Poll only | IDLE per RFC 2177 |
| Best for | Single-device users, offline workflows, limited connectivity | Multi-device users, typical modern use |
Common POP3 mistakes
Related standards and further reading
- Email Protocols and Ports Guide: POP3 alongside IMAP and SMTP
- SSL/TLS Email Setup Guide: securing POP3 access
Frequently asked questions
Should I use POP3 or IMAP?
IMAP for most modern use. Multi-device access (phone + desktop + web), server-side folders, and message flag sync are IMAP-only. POP3 suits: single-device users, offline-heavy workflows, or archival download of a large mailbox to local storage. In 2026, IMAP is the default recommendation; POP3 remains available for specific use cases.
Can POP3 leave messages on the server?
Not per RFC 1939 protocol semantics (messages are typically deleted after download). But most client implementations offer “leave messages on server” as a configuration option. When enabled, the client uses UIDL to track which messages it has downloaded and avoids re-fetching. This mimics some IMAP behavior but without the folder tree, server-side search, or multi-device state sync IMAP provides.
What is the difference between STLS and STARTTLS?
Same concept, different command name. STLS is POP3’s version of the TLS upgrade command; STARTTLS is used by IMAP and SMTP. Both upgrade a cleartext connection to TLS per RFC 2595. The naming difference is historical: POP3 commands are traditionally four uppercase characters (USER, PASS, RETR), so STLS fits the pattern.
Is POP3 still supported by major providers?
Yes, though incrementally deprecated. Gmail, Outlook.com, and Yahoo all offer POP3 access. Some providers require explicit opt-in or app-specific passwords for POP3. As mail volume moves to native mobile clients and web interfaces (both of which use IMAP or proprietary APIs), POP3 usage declines but remains available.
Why does POP3 delete messages after download by default?
Historical design: POP3 was created for dial-up era users with limited server storage and expensive per-minute connections. Downloading to local storage and freeing server space made sense. In the modern era of always-connected, generous server storage, this model is obsolete for most users; hence the shift to IMAP or POP3 with “leave on server” enabled.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
