POP3 Extension Mechanism
This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]
This document is current and has been amended. 1 later RFC has changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 17 must, 9 should, 5 may.
4 Parameter and Response Lengths
- MUSTServers which support the CAPA command MUST support commands up to 255 octets.
- MUSTServers MUST also support the largest maximum command length specified by any supported capability.
5 The CAPA Command
- MUSTA capability description MUST document in which states the capability is announced, and in which states the commands are valid.
- MUSTCapabilities available in the AUTHORIZATION state MUST be announced in both states.
- MUSTIf a capability is announced in both states, but the argument might differ after authentication, this possibility MUST be stated in the capability description.
- SHOULDIf the authentication step negotiates an integrity protection layer, the client SHOULD reissue the CAPA command after authenticating, to check for active down-negotiation attacks.
- SHOULDWhen a capability response describes an optional command, the <capa-tag> SHOULD be identical to the command keyword.
- MAYEach capability name MAY be followed by a single space and a space-separated list of parameters.
6.5 LOGIN-DELAY capability
- SHOULDClients which permit the user to configure a mail check interval SHOULD use this capability to determine the minimum permissible interval.
- SHOULDServers which advertise LOGIN- DELAY SHOULD enforce it.
- MUSTIf the minimum login delay period could differ per user (that is, the LOGIN-DELAY argument might change after authentication), the server MUST announce in AUTHENTICATION state the largest value which could be set for any user.
- SHOULDThe server SHOULD append the token "USER" to the LOGIN- DELAY parameter in AUTHENTICATION state, to inform the client that a more accurate value is available after authentication.
- SHOULDThe server SHOULD announce the more accurate value in TRANSACTION state.
6.6 PIPELINING capability
- MUSTIf a server supports PIPELINING, it MUST process each command in turn.
- MUSTIf a client uses PIPELINING, it MUST keep track of which commands it has outstanding, and match server responses to commands in order.
- MUSTIf either the client or server uses blocking writes, it MUST not exceed the window size of the underlying transport layer.
6.7 EXPIRE capability
- MAYEXPIRE 0 indicates the client is not permitted to leave mail on the server; when the session enters the UPDATE state the server MAY assume an implicit DELE for each message which was downloaded with RETR.
- SHOULDIf a site uses any automatic deletion policy, it SHOULD use the EXPIRE capability to announce this.
- SHOULDSites which permit users to retain messages indefinitely SHOULD announce this with the EXPIRE NEVER response.
- MUSTIf the expiration policy differs per user (that is, the EXPIRE argument might change after authentication), the server MUST announce in AUTHENTICATION state the smallest value which could be set for any user.
- SHOULDThe server SHOULD append the token "USER" to the EXPIRE parameter in AUTHENTICATION state, to inform the client that a more accurate value is available after authentication.
6.9 IMPLEMENTATION capability
- MAYHowever, a server MAY chose to do so only in TRANSACTION state.
- MAYA server MAY include the implementation identification both in the welcome banner and in the IMPLEMENTATION capability.
- MUST NOTClients MUST NOT modify their behavior based on the server implementation.
7 Future Extensions to POP3
- MUST NOTClients MUST NOT require the presence of any extension for basic functionality, with the exception of the authentication commands (APOP, AUTH [section 6.3] and USER/PASS).
8 Extended POP3 Response Codes
- MAYClients supporting this extension MAY remove any information enclosed in square brackets prior to displaying human readable text to the user.
- MUSTClients MUST ignore unknown hierarchical detail about the response code.
9 IANA Considerations
- MUSTNew POP3 capabilities MUST be defined in a standards track or IESG approved experimental RFC, and MUST NOT begin with the letter "X".
- MUSTNew POP3 capabilities MUST include the following information: CAPA tag Arguments Added commands Standard commands affected Announced states / possible differences Commands valid in states Specification reference Discussion
- MUSTNew POP3 response codes MUST be defined in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible.
- MUSTNew POP3 response code specifications MUST include the following information: the complete response code, for which responses (+OK or -ERR) and commands it is valid, and a definition of its meaning and expected client behavior.