Post Office Protocol: Version 3
obsoleted by
- rfc-1460 — Post Office Protocol - Version 3
obsoletes
- rfc-1081 — Post Office Protocol: Version 3
Extracted elements (25)
Minimal POP3 server implementations need only parse the maildrop into component messages and are NOT required to parse individual messages internally. This keeps server complexity low while allowing more capable clients to exploit optional features like TOP.
POP3 is designed for a 'split-UA' model where mail posting (SMTP) and retrieval (POP3) are separated, allowing resource-limited workstations to participate in the mail system without running a full MTS. The client host acts as a user agent, not a trusted MTS entity.
The spec strongly encourages implementing the optional TOP and RPOP commands instead of augmenting drop or scan listings with additional parsed data. The stated philosophy is to place intelligence in the POP3 client rather than the server, keeping server implementations minimal.
The octet count assigned to a message by the POP3 server may differ from the byte count on the server host due to local end-of-line conventions. For example, a server using single-character line endings must count each as two octets when reporting message sizes.
After parsing the maildrop, the server assigns sequential integer message-ids starting at 1 (the n-th message gets id n), notes each message's size in octets, and sets 'highest number accessed' to the id of the last message previously referenced by RETR. All message-ids and sizes are expressed in decimal.
All messages transmitted during a POP3 session are assumed to conform to RFC 822 (Standard for the Format of ARPA-Internet Text Messages).
The POP3 server listens on TCP port 110. When a client establishes a TCP connection, the server sends a greeting response, and the session enters the AUTHORIZATION state.
The reply text following +OK or -ERR is significant only in its indicator token; any trailing text on the response line MAY be ignored by the client. The sole exception is STAT, whose drop listing format carries structured data the client must parse.
Upon successful authentication, the POP3 server MUST acquire an exclusive-access lock on the maildrop before entering the TRANSACTION state. If the lock cannot be acquired, the server MUST respond with -ERR and, if a lock was transiently acquired, MUST release it before rejecting the command.
The DELE command marks a specified message as deleted; actual deletion is deferred until the UPDATE state. Any subsequent reference to the deleted message-id returns an error. DELE also updates 'highest number accessed' if appropriate.
The LAST command returns the highest message-id that has been accessed (via RETR or DELE) during the session or any previous session, allowing clients to identify unread messages. RSET resets this value to the state at session start.
The LIST command, valid in TRANSACTION state, returns a 'scan listing' for one or all non-deleted messages. Each scan listing MUST begin with the message-id followed by the message size in octets. With no argument, the response is multi-line, one scan listing per message.
The optional RPOP command substitutes for PASS in AUTHORIZATION, authenticating via a trusted-host mechanism (e.g., .rhosts on Berkeley UNIX) rather than a password. It requires the client to connect from a privileged TCP port (port < 1024).
The optional TOP command (valid in TRANSACTION) returns the message headers, the blank separator line, and the first n body lines of a specified message as a multi-line response. If n exceeds the body length, the entire message is returned.
The PASS command, valid only after a successful USER command in AUTHORIZATION, provides a password. On success the server acquires an exclusive-access lock on the maildrop, parses it into individual messages, and the session enters TRANSACTION state.
The RETR command retrieves a specified non-deleted message as a multi-line response. If the message's number exceeds 'highest number accessed', the server updates that value. The termination character in message content is byte-stuffed as with all multi-line responses.
The RSET command unmarks all messages previously marked as deleted and resets 'highest number accessed' to its value at session start, effectively undoing all DELE operations in the current session.
The STAT command, valid in TRANSACTION state, returns a 'drop listing' whose format MUST begin with the count of non-deleted messages followed by the total maildrop size in octets. The spec strongly discourages adding further information to the drop listing.
The UPDATE state is entered when QUIT is issued from TRANSACTION. The server deletes all messages marked for deletion, releases the exclusive-access lock on the maildrop, sends a final +OK or -ERR response, and closes the TCP connection.
The USER command, valid only in the AUTHORIZATION state, takes a server-specific user-id as a required argument. A +OK response permits the client to issue PASS or QUIT; a -ERR response permits re-issuing USER or QUIT.
The RPOP command relies on trusted-host authentication (privileged source port + .rhosts-style checks), which the document notes has 'allowed much wider penetration into numerous hosts on local networks (and sometimes remote networks) by those who gain illegal access to computers by guessing passwords or otherwise breaking into the system.'
The Security Considerations section of RFC 1225 explicitly states: 'Security issues are not discussed in this memo.' The protocol transmits credentials (USER/PASS) and mail content in cleartext over TCP with no provision for encryption or integrity protection.
A POP3 session progresses through three sequential states: AUTHORIZATION (client must authenticate), TRANSACTION (client issues mail commands), and UPDATE (server deletes marked messages and releases the maildrop lock before closing the TCP connection). QUIT from AUTHORIZATION skips the UPDATE state entirely.
Multi-line responses are terminated by a line containing only a termination octet (decimal 46, '.') followed by CRLF, making the full terminator 'CRLF.CRLF'. Any line in the response beginning with '.' is byte-stuffed by prepending an additional '.', which the client must strip upon receipt.
POP3 commands consist of a keyword optionally followed by an argument, terminated by a CRLF pair. Responses consist of a success indicator (+OK or -ERR) optionally followed by additional text, also terminated by CRLF.