Post Office Protocol - Version 3
obsoletes
- rfc-1725 — Post Office Protocol - Version 3
updated by
- rfc-1957 — Some Observations on Implementations of the Post Office Protocol (POP3)
- rfc-2449 — POP3 Extension Mechanism
- rfc-6186 — Use of SRV Records for Locating Email Submission/Access Services
- rfc-8314 — Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
also
- std-53
Extracted elements (29)
POP3 is intentionally not designed for extensive server-side mail manipulation; the expected model is download-and-delete. IMAP4 is explicitly recommended for scenarios requiring persistent server-side folders or richer message management.
POP3's design philosophy places intelligence in the client, not the server. Optional commands (TOP, UIDL) are strongly encouraged over extending scan or drop listings with parsed message data, keeping server implementations simple.
The octet count for a message on the server may differ from what a client expects due to local line-ending conventions. Servers must normalize counts by treating each internal line-ending as two octets (CRLF), but must not double-count byte-stuffed termination octets since clients will strip them.
A POP3 server MAY implement an inactivity autologout timer, but such a timer MUST be at least 10 minutes in duration. Upon expiry the server closes the TCP connection without entering the UPDATE state and without removing any messages.
A server MUST respond with a negative status indicator to any unrecognized, unimplemented, or syntactically invalid command, and to any command issued when the session is in an incorrect state.
After successful authentication the server must acquire an exclusive-access lock on the maildrop before entering TRANSACTION state. If the lock cannot be acquired the server responds with a negative indicator and must release any partially acquired lock before rejecting the command.
If a POP3 session terminates for any reason other than a client-issued QUIT command, the session does NOT enter the UPDATE state and MUST NOT remove any messages from the maildrop.
Servers MUST send the '+OK' and '-ERR' status indicators in upper case.
The APOP timestamp included in the server banner greeting MUST be syntactically a valid RFC 822 msg-id and MUST be different each time the POP3 server issues a banner greeting, providing replay protection.
The POP3 server listens on TCP port 110. When a client connects, the server sends a positive one-line greeting and the session enters the AUTHORIZATION state.
UIDL unique-ids must persist across sessions, including sessions that ended without entering the UPDATE state. The server should never reuse a unique-id in a given maildrop for as long as the associated message entity exists.
The DELE msg command (TRANSACTION state) marks the specified message as deleted; actual deletion is deferred until the UPDATE state. Any subsequent reference to the message-number generates an error. RSET unmarks all deleted messages.
The LIST [msg] command (TRANSACTION state) returns scan listings in the format 'message-number<SP>exact-size-in-octets'. With no argument it returns a multi-line listing of all non-deleted messages; with a message-number it returns a single scan listing for that message.
The optional APOP name digest command provides challenge-response authentication. The server includes an RFC 822 msg-id timestamp in its banner greeting, which MUST differ every session. The client computes MD5(timestamp + shared_secret) and sends the 16-octet result as lowercase hexadecimal.
The optional TOP msg n command (TRANSACTION state) returns the message headers, the blank separator line, and the first n lines of the body as a multi-line response. If n exceeds the body length, the entire message is sent.
The optional UIDL [msg] command (TRANSACTION state) returns unique-id listings in the format 'message-number<SP>unique-id'. With no argument it lists all non-deleted messages; with a message-number it returns the single unique-id listing for that message.
The optional USER name and PASS string commands provide plaintext password authentication in the AUTHORIZATION state. USER must be issued first; if it returns +OK, PASS may be issued immediately after. PASS may treat spaces in its argument as part of the password rather than separators.
The QUIT command in the UPDATE state causes the server to delete all messages marked for deletion, release the exclusive-access lock, and close the TCP connection. In no case may the server delete messages not marked as deleted.
The RETR msg command (TRANSACTION state) retrieves the full RFC 822 message identified by message-number as a multi-line response with byte-stuffing applied to lines beginning with the termination octet.
The STAT command (TRANSACTION state) returns a drop listing: '+OK' followed by the count of non-deleted messages in the maildrop and the total maildrop size in octets. Deleted messages are excluded from both totals.
A server implementing both PASS and APOP should not permit both authentication methods for the same user; for a given mailbox, only USER/PASS or APOP should be accepted, not both, to prevent downgrade to the weaker method.
Servers that return -ERR to the USER command leak which mailbox names are valid to potential attackers, enabling user enumeration. Servers may instead return +OK regardless of mailbox existence and defer the negative response to PASS.
Use of the PASS command sends passwords in clear text over the network. RETR and TOP commands similarly send message content in clear text, exposing both credentials and mail to passive interception.
A POP3 session progresses through three states: AUTHORIZATION (client must authenticate), TRANSACTION (client requests actions on the maildrop), and UPDATE (server deletes marked messages and closes connection). The session enters TRANSACTION only after successful authentication; it enters UPDATE only upon a client-issued QUIT from TRANSACTION state.
A UIDL unique-id is a server-determined string of 1 to 70 characters in the range 0x21–0x7E (printable ASCII excluding space) that uniquely identifies a message within a maildrop.
Multi-line responses are terminated by the five-octet sequence CRLF.CRLF. Any response line beginning with the termination octet ('.', decimal 46) is byte-stuffed by prepending an extra '.'; clients must strip the leading '.' from such lines upon receipt.
POP3 commands consist of a case-insensitive keyword (3–4 characters) optionally followed by arguments, all terminated by CRLF. Keywords and arguments are separated by a single SPACE; each argument may be up to 40 characters long, consisting of printable ASCII.
POP3 responses begin with a status indicator (+OK or -ERR) possibly followed by additional text, terminated by CRLF. Responses may be up to 512 characters long including the terminating CRLF.
The APOP digest field is the MD5 hash of the concatenated server timestamp (including angle-brackets) and the shared secret, encoded as 32 lowercase hexadecimal ASCII characters representing 16 octets.