Post Office Protocol - Version 3
obsoleted by
- rfc-1725 — Post Office Protocol - Version 3
obsoletes
- rfc-1225 — Post Office Protocol: Version 3
Extracted elements (24)
Minimal POP3 server implementations need only parse the maildrop into its component messages; they are not required to parse individual message headers. This keeps the minimum implementation bar low while allowing more advanced servers to offer richer features.
POP3 is designed for a split-UA model: the client host acts as a user agent for mail retrieval (POP3) while using SMTP to post mail, with both UA functions split across two hosts. The client should NOT be regarded as a 'trusted' MTS entity.
The spec strongly encourages implementing the optional TOP and APOP commands rather than augmenting drop and scan listings with additional parsed information. The design philosophy is to place intelligence in the POP3 client, not the server, keeping the server 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 a single-character EOL must count each such character as two octets (CRLF) when computing the scan listing size.
After parsing the maildrop, the server assigns sequential message-ids starting at 1 (n'th message gets id n) and records the size of each message in octets. 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 APOP timestamp included in the server's banner greeting MUST be different each time the POP3 server issues a greeting, to provide replay protection. Its syntax corresponds to the 'msg-id' production in RFC 822.
The POP3 server listens on TCP port 110. When a client establishes a TCP connection, the server sends a one-line greeting terminated by CRLF.
Upon successful authentication the POP3 server must set the 'highest number accessed' to that of the last message previously referenced by the RETR command, tracking message access state across sessions.
The DELE command marks a specified message as deleted; the message is not actually removed until the UPDATE state. Any subsequent reference to the deleted message-id generates an error. DELE also updates 'highest number accessed' if the message number exceeds it.
The LAST command returns the highest message number accessed (via RETR or DELE) in the current or prior sessions. Returns 0 if no message has ever been accessed. Clients can infer that messages numbered higher than this response have not yet been retrieved.
The LIST command, valid in the TRANSACTION state, returns a scan listing. With a message-id argument it returns that message's id and size; without an argument it returns a multi-line scan listing for all non-deleted messages. The format requires message-id first, then size in octets.
The optional APOP command provides challenge-response authentication in the AUTHORIZATION state. The server includes a unique timestamp (RFC 822 msg-id format) in its greeting banner; the client sends APOP with a username and an MD5 digest of the concatenation of the timestamp (with angle-brackets) and the shared secret. The digest is 16 octets in lowercase hexadecimal.
The optional TOP command (TRANSACTION state) returns the message headers, the blank line separating headers from body, and the first n lines of the body for the specified message, using multi-line response format. If n exceeds the body length, the entire message is sent.
The PASS command, valid only after a successful USER command, supplies the password. On success, the server acquires an exclusive-access lock on the maildrop, parses it into individual messages, and the session enters the TRANSACTION state. If the lock cannot be acquired, the server responds -ERR and must release any partially acquired lock before rejecting the command.
The RETR command retrieves a specified non-deleted message as a multi-line response. If the retrieved message's number exceeds the current 'highest number accessed', the server updates that value accordingly.
The RSET command, valid in the TRANSACTION state, unmarks all messages previously marked as deleted and resets the 'highest number accessed' to zero, then replies with a positive response.
The STAT command, valid in the TRANSACTION state, returns a drop listing: the number of messages in the maildrop followed by the maildrop size in octets. Messages marked as deleted are not counted.
The UPDATE state is entered only when QUIT is issued from the TRANSACTION state. The server deletes all messages marked for deletion, releases the exclusive-access lock on the maildrop, replies with the outcome, and closes the TCP connection. Issuing QUIT from AUTHORIZATION terminates without entering UPDATE.
The USER command, valid in the AUTHORIZATION state, supplies a server-specific user-id. The server responds +OK or -ERR; after a successful USER, the client must issue PASS or QUIT.
A POP3 server that implements both PASS and APOP must not allow both methods for the same user account. For any given user, only one authentication method is permitted, preventing downgrade attacks where APOP's replay protection could be circumvented by falling back to PASS.
Use of APOP is conjectured to provide origin authentication and replay protection; the shared secret used in APOP must be carefully protected, as knowledge of it allows any entity to masquerade as the named user. The USER/PASS exchange sends the password in the clear on the network.
A POP3 session progresses through three states: AUTHORIZATION (client must identify itself), TRANSACTION (client requests actions on the maildrop), and UPDATE (server deletes marked messages and releases the lock). QUIT from AUTHORIZATION terminates the session without entering UPDATE; QUIT from TRANSACTION enters UPDATE.
All POP3 commands and responses are terminated by a CRLF pair. Responses begin with '+OK' or '-ERR'. Multi-line responses are terminated by a line containing only '.' followed by CRLF (five octets 'CRLF.CRLF'); any response line beginning with '.' is byte-stuffed by prepending an additional '.'.