POP3 Extension Mechanism
updated by
- rfc-5034 — The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism
updates
- rfc-1939 — Post Office Protocol - Version 3
Extracted elements (30)
Future POP3 extensions are generally discouraged because POP3's usefulness lies in its simplicity as a download-and-delete protocol. Extensions supporting additional mailboxes, message uploads, or deviations from the download-and-delete model are strongly discouraged and unlikely to be permitted on the standards track.
There is no APOP capability because clients already discover APOP support via the presence of an initial challenge in angle brackets in the greeting banner. Adding an APOP capability would introduce two redundant ways for a server to announce the same thing.
A capability description MUST document in which states the capability is announced and in which states its commands are valid. Capabilities available in the AUTHORIZATION state MUST be announced in both states.
Clients MUST NOT modify their behavior based on the IMPLEMENTATION capability value; instead the server and client should agree on a private extension.
Clients MUST NOT require the presence of any extension for basic POP3 functionality, with the exception of authentication commands (APOP, AUTH, and USER/PASS).
Clients which permit the user to configure a mail check interval SHOULD use the LOGIN-DELAY capability to determine the minimum permissible interval. Servers which advertise LOGIN-DELAY SHOULD enforce it.
If a capability's argument might differ after authentication, this possibility MUST be stated in the capability description. This allows clients to decide whether a second CAPA command is necessary.
If a server supports PIPELINING, it MUST process each command in turn. If a client uses PIPELINING, it MUST keep track of outstanding commands and match server responses to commands in order. If either side uses blocking writes, it MUST NOT exceed the window size of the underlying transport layer.
If the authentication step negotiates an integrity protection layer, the client SHOULD reissue the CAPA command after authenticating to check for active down-negotiation attacks.
If the expiration policy differs per user, the server MUST announce in AUTHENTICATION state the smallest value which could be set for any user. If a site uses any automatic deletion policy, it SHOULD use the EXPIRE capability to announce this.
If the minimum login delay period could differ per user, the server MUST announce in AUTHENTICATION state the largest value which could be set for any user.
Servers which support the CAPA command MUST support commands up to 255 octets. Servers MUST also support the largest maximum command length specified by any supported capability.
Extended POP3 response codes are optional machine-parseable codes enclosed in square brackets at the beginning of the human-readable text of +OK or -ERR responses. Response codes are hierarchical with '/' separating levels; clients MUST ignore unknown hierarchical detail.
The CAPA command returns a list of capabilities supported by the POP3 server. It is available in both the AUTHORIZATION and TRANSACTION states. An -ERR response indicates the command is not implemented; an +OK response is followed by one capability per line, terminated by a line containing '.' and CRLF.
The EXPIRE capability argument indicates the server's minimum guaranteed message retention period in days, or NEVER (no deletion) or 0 (messages must be deleted each session). An optional 'USER' token signals that per-user values are available after authentication.
The IMPLEMENTATION capability carries a string identifying the server implementation. Servers MAY restrict it to TRANSACTION state only and MAY also include the identification in the welcome banner.
The IN-USE response code is returned on -ERR responses to AUTH, APOP, or PASS commands and indicates authentication succeeded but the user's maildrop is currently in use, probably by another POP3 client.
The LOGIN-DELAY capability includes an integer argument specifying the minimum seconds required between successive logins. Optionally followed by the token 'USER' in AUTHENTICATION state to indicate the value may be more accurate after authentication.
The LOGIN-DELAY response code is returned on -ERR responses to AUTH, USER, PASS, or APOP commands and indicates the user logged in recently and cannot authenticate again until the login delay period expires.
The PIPELINING capability indicates the server can accept multiple commands without the client waiting for each response. It affects all commands and is announced in both states with no per-user differences.
The RESP-CODES capability indicates that any response text from the server beginning with '[' is an extended response code as defined in section 8. It takes no arguments and is announced in both states.
The SASL capability indicates the AUTH command is available and supports an optional base64-encoded initial client response. Its argument is a space-separated list of supported SASL mechanisms (e.g., 'SASL CRAM-MD5 KERBEROS_V4').
The TOP capability indicates the optional TOP command from RFC 1939 is available. It is valid in TRANSACTION state and announced in both AUTHORIZATION and TRANSACTION states with no per-user differences.
The UIDL capability indicates the optional UIDL command from RFC 1939 is supported. It is valid in TRANSACTION state, announced in both states, and takes no arguments.
The USER capability indicates that the USER and PASS commands are supported, though they may not be available to all users. It is valid in AUTHENTICATION state and announced in both states.
IANA is requested to maintain a POP3 capabilities registry. New capabilities MUST be defined in a standards track or IESG-approved experimental RFC, MUST NOT begin with 'X', and MUST include: CAPA tag, arguments, added commands, affected standard commands, announced states/differences, valid command states, specification reference, and discussion.
IANA is requested to maintain a POP3 response codes registry. New codes require an RFC or other permanent reference (Specification Required policy) and MUST include: the complete response code, which responses and commands it is valid for, and a definition of its meaning and expected client behavior.
A capability list can reveal information about the server's authentication mechanisms, which can help an attacker determine if certain attacks will be successful. However, this disclosure also allows clients to automatically detect stronger mechanisms and improve overall security.
Returning the LOGIN-DELAY response code to the USER command reveals that the specified username exists. Servers are strongly recommended not to issue this response code to USER unless user names are not secret, server access is restricted, or the server can verify the connection is from the same user.
POP3 commands are defined as 'keyword *(SP param) CRLF' with a 255-octet maximum. Single-line responses are 'status [SP text] CRLF' with a 512-octet maximum. Response codes use the form '[' resp-level *('/' resp-level) ']' embedded at the start of response text. The CAPA response is 'single-line *capability "." CRLF' with each capability line limited to 512 octets.