Internet Draft: POP3 Extension Mechanism R. Gellens Document: draft-gellens-pop3ext-03.txt QUALCOMM, Incorporated Expires: 13 September 1998 C. Newman Innosoft L. Lundblade QUALCOMM, Incorporated 13 March 1998 POP3 Extension Mechanism Status of this Memo: This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts shadow directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). A version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Public comments should be sent to the IETF POP3 Extensions mailing list, <ietf-pop3ext@imc.org>. To subscribe, send a message containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>. Private comments may be sent to the authors. Copyright Notice Copyright (C) The Internet Society 1998. All Rights Reserved. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in this Document . . . . . . . . . . . . . . . . 2 3. General Command and Response Grammar . . . . . . . . . . . . . . . 3 4. Parameter and Response Lengths. . . . . . . . . . . . . . . . . . 3 Gellens, Newman, Lundblade [Page 1] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Initial Set of Capabilities . . . . . . . . . . . . . . . . . . . 5 6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. USER capability . . . . . . . . . . . . . . . . . . . . . . . . 6 6.3. SASL capability . . . . . . . . . . . . . . . . . . . . . . . . 6 6.4. LOGIN-DELAY capability. . . . . . . . . . . . . . . . . . . . . 6 6.5. PIPELINING capability . . . . . . . . . . . . . . . . . . . . . 7 6.6. LMOS capabilities . . . . . . . . . . . . . . . . . . . . . . . 8 6.7. UIDL capability . . . . . . . . . . . . . . . . . . . . . . . . 9 6.8. IMPLEMENTATION capability. . . . . . . . . . . . . . . . . . . 10 7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . . . . 10 8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . . . 11 8.1. Initial POP3 response codes . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 11. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 13 13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Post Office Protocol version 3 [POP3] is very widely used. However, while it includes some optional commands (and some useful protocol extensions have been published), it lacks a mechanism for advertising support for these extensions or for behavior variations. Currently these optional features and extensions can only be detected by probing, if at all. This is at best inefficient, and possibly worse. As a result, some clients have manual configuration options for POP3 server capabilities. Because one of the most important characteristics of POP3 is its simplicity, it is desirable that extensions be few in number. However, some extensions are necessary (such as ones that provide improved security [POP-AUTH]), while others are very desirable in certain situations. In addition, a means for discovering server behavior is needed. This memo defines a mechanism to announce support for optional commands, extensions, and unconditional server behavior. Included is an initial set of currently deployed capabilities which vary between server implementations. This document also extends POP3 error messages so that machine parsable codes can be provided to the client. An initial set of response codes is included. 2. Conventions Used in this Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described Gellens, Newman, Lundblade [Page 2] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 3. General Command and Response Grammar The general form of POP3 commands and responses is described using [ABNF]: POP3 commands: command = keyword *(SP param) CRLF ;255 octets maximum keyword = 3*4VCHAR param = 1*VCHAR POP3 responses: capa-resp = single-line *capability "." CRLF capa-tag = 1*cchar capability = capa-tag *(SP param) ;512 octets maximum cchar = %x21-2D / %x2F-7F ;printable ASCII, excluding "." dot-stuffed = *CHAR CRLF ;must be dot-stuffed gchar = %x21-3B / %x3D-7F ;printable ASCII, excluding "<" greeting = "+OK" [resp-code] *gchar [timestamp] *gchar ;512 octets maximum multi-line = single-line *dot-stuffed "." CRLF rchar = %x21-2E / %x30-5C / %x5E-7F ;printable ASCII, excluding "/" and "]" resp-code = "[" resp-level *("/" resp-level) "]" resp-level = 1*rchar response = greeting / single-line / capa-resp / multi-line single-line = status SP [text] CRLF ;512 octets maximum status = "+OK" / "-ERR" text = [resp-code] *CHAR timestamp = "<" *VCHAR ">" ;MUST conform to RFC-822 msg-id 4. Parameter and Response Lengths This specification increases the length restrictions on commands and parameters imposed by RFC 1939. The maximum length of a command is increased from 45 characters (4 character command, single space, 40 character argument) to 255 octets. Gellens, Newman, Lundblade [Page 3] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 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. The maximum length of the first line of a command response (including the initial greeting) is unchanged at 512 octets (including the terminating CRLF). 5. The CAPA Command The POP3 CAPA command returns a list of capabilities supported by the POP3 server. It is available in both the AUTHORIZATION and TRANSACTION states. Additional capabilities MAY become available in the TRANSACTION state, but all capabilities listed in the AUTHORIZATION state MUST also be available. If a capability available in the TRANSACTION state is not available in the AUTHORIZATION state, this MUST be stated in the capabilities description. (This allows clients to issue only one CAPA command, if they do not use any TRANSACTION-only capabilities.) Each capability may enable additional protocol commands, additional parameters and responses for existing commands, or describe an aspect of server behavior. These details are specified in the description of the capability. Section 3 describes the CAPA response using [ABNF]. When a capability response describes an optional command, the <capa-tag> SHOULD be identical to the command keyword. CAPA response tags are case-insensitive. CAPA Arguments: none Restrictions: none Discussion: An -ERR response indicates the capability command is not implemented and the client will have to probe for capabilities as before. An +OK response is followed by a list of capabilities, one per line. Each capability name MAY be followed by a single space and a space-separated list of parameters. Each capability line is limited to 512 octets (including the CRLF). The capability list is terminated by a line containing a termination octet (".") and a CRLF pair. Possible Responses: Gellens, Newman, Lundblade [Page 4] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 +OK -ERR Examples: C: CAPA S: +OK Capability list follows S: TOP S: USER S: APOP S: SASL CRAM-MD5 KERBEROS_V4 S: LOGIN-DELAY 900 S: PIPELINING S: LMOS-NEW 60 S: LMOS-RETR 7 S: LMOS-TOP 60 S: UIDL S: IMPLEMENTATION Shlemazle-Plotz-v302 S: . 6. Initial Set of Capabilities This section defines an initial set of POP3 capabilities. These include the optional POP3 commands, already published POP3 extensions, and behavior variations between POP3 servers which can impact clients. Note that there is no APOP capability, even though APOP is an optional command in [POP3]. Clients discover server support of APOP by the presence in the greeting banner of an initial challenge enclosed in angle brackets ("<>"). Therefore, an APOP capability would introduce two ways for a server to announce the same thing. 6.1. TOP capability CAPA tag: TOP Arguments: none Added commands: TOP Standard commands affected: none Discussion: The TOP capability indicates the optional TOP command is available. Gellens, Newman, Lundblade [Page 5] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 6.2. USER capability CAPA tag: USER Arguments: none Added commands: USER PASS Standard commands affected: none Discussion: The USER capability indicates that the USER and PASS commands are supported, although they may not be available to all users. 6.3. SASL capability CAPA tag: SASL Arguments: Supported SASL mechanisms Added commands: AUTH Standard commands affected: none Discussion: The POP3 AUTHentication command [POP-AUTH] permits the use of [SASL] authentication mechanisms with POP3. The SASL capability indicates that the AUTH command is available and that it supports an optional base64 encoded second argument for an initial client response as described in the SASL specification. The argument to the SASL capability is a space separated list of SASL mechanisms which are supported. 6.4. LOGIN-DELAY capability CAPA tag: LOGIN-DELAY Arguments: minimum seconds between logins Added commands: Gellens, Newman, Lundblade [Page 6] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 none Standard commands affected: none Discussion: POP3 clients often login frequently to check for new mail. Unfortunately, the process of creating a connection, authenticating the user, and opening the user's maildrop can be very resource intensive on the server. A number of deployed POP3 servers try to reduce server load by requiring a delay between logins. The LOGIN-DELAY capability includes an integer argument which indicates the number of seconds after an "+OK" response to a PASS, APOP, or AUTH command before another authentication will be accepted. Clients which permit the user to configure a mail check interval SHOULD use this capability to determine the minimum permissible interval. Servers which advertise LOGIN-DELAY SHOULD enforce it. 6.5. PIPELINING capability CAPA tag: PIPELINING Arguments: none Added commands: none Standard commands affected: none Discussion: The PIPELINING capability indicates the server is capable of accepting multiple commands at a time; the client does not have to wait for the response to a command before issuing a subsequent command. If a server supports PIPELINING, it MUST process each command in turn. If a client uses PIPELINING, it MUST keep track of which commands it has outstanding, and match server responses to commands in order. If either the client or server uses blocking writes, it MUST not exceed the window size of the underlying transport layer. Some POP3 clients have an option to indicate the server supports "Overlapped POP3 commands." This capability removes the need to configure this at the client. This is roughly synonymous with the ESMTP PIPELINING extension [PIPELINING]. Gellens, Newman, Lundblade [Page 7] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 6.6. LMOS capabilities CAPA tags: LMOS-RETR LMOS-TOP LMOS-NEW Arguments: Retention period, in days, for a message category Added commands: none Standard commands affected: none Discussion: While POP3 allows clients to leave messages on the server, RFC 1939 warns about the problems that may arise from this, and allows servers to delete messages based on site policy. To quote from RFC 1939: Sites are free to establish local policy regarding the storage and retention of messages on the server, both read and unread. For example, a site might delete unread messages from the server after 60 days and delete read messages after 7 days. Such message deletions are outside the scope of the POP3 protocol and are not considered a protocol violation. ... It should be noted that enforcing site message deletion policies may be confusing to the user community, since their POP3 client may contain configuration options to leave mail on the server which will not in fact be supported by the server. One special case of a site policy is that messages may only be downloaded once from the server, and are deleted after this has been accomplished. This could be implemented in POP3 server software by the following mechanism: "following a POP3 login by a client which was ended by a QUIT, delete all messages downloaded during the session with the RETR command". ... Servers implementing a download-and-delete policy may also wish to disable or limit the optional TOP command, since it could be used as an alternate mechanism to download entire messages. The LMOS capabilities avoid the problems mentioned in RFC 1939, by allowing the server to inform the client as to the policy in effect. The argument to the LMOS capabilities indicate the server retention period, in days, for messages in a specific category. Zero indicates messages in that category are Gellens, Newman, Lundblade [Page 8] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 immediately deleted. Each LMOS capability tag corresponds to a message category, that is, messages which have been the targets of a RETR or TOP command, or are new. The absence of a particular LMOS capability tag (in the presence of other LMOS capability tags) indicates no automatic deletion for messages in that category. Note: to ease client interpretation and UI, messages which have been TOPped SHOULD be in the same category as either new or RETRd messages; that is, servers SHOULD have only two distinct categories of messages (new and seen); TOPped messages MAY be considered in either. Examples: LMOS-NEW 30 LMOS-RETR 5 LMOS-TOP 5 LMOS-NEW 60 LMOS-RETR 60 LMOS-TOP 60 LMOS-RETR 45 The first example set indicates the server deletes new (unseen) messages after 30 days, messages which have been downloaded using RETR after 5 days, and messages which have been examined using TOP also after 5 days. The second example set specifies that the server deletes all messages after 60 days. The third example set indicates that messages downloaded using RETR are automatically deleted after 45 days, but messages in other categories are not automatically deleted. 6.7. UIDL capability CAPA tag: UIDL Arguments: none Added commands: UIDL Standard commands affected: none Discussion: The UIDL capability indicates that the UIDL command is Gellens, Newman, Lundblade [Page 9] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 supported. 6.8. IMPLEMENTATION capability CAPA tag: IMPLEMENTATION Arguments: string giving server implementation information Added commands: none Standard commands affected: none Discussion: It is often useful to identify an implementation of a particular server (for example, when logging). This is commonly done in the welcome banner, but one must guess if a string is an implementation ID or not. The argument to the IMPLEMENTATION capability is a string, enclosed in double-quote marks, identifying the server. A server MAY include the implementation identification both in the welcome banner and in the IMPLEMENTATION capability. Clients MUST NOT modify their behavior based on the server implementation. Instead the server and client should agree on a private extension. 7. Future Extensions to POP3 Future extensions to POP3 are in general discouraged, as POP3's usefulness lies in its simplicity. Extensions which offer capabilities supplied by IMAP [IMAP4] or SMTP [SMTP] are strongly discouraged and unlikely to be permitted on the IETF standards track. Clients MUST NOT require the presence of any extension for basic functionality. Capabilities beginning with the letter "X" are reserved for experimental non-standard extensions and their use is discouraged. All other capabilities MUST be defined in a standards track or IESG approved experimental RFC. Gellens, Newman, Lundblade [Page 10] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 8. Extended POP3 Response Codes POP3 is currently only capable of indicating success or failure to most commands. Unfortunately, clients often need to know more information about the cause of a failure in order to gracefully recover. This is especially important in response to a failed login (there are widely-deployed clients which attempt to decode the error text of a PASS command result, to try and distinguish between "unable to get maildrop lock" and "bad login"). This specification amends the POP3 standard to permit an optional response code, enclosed in square brackets, at the beginning of the human readable text portion of an "+OK" or "-ERR" response. Clients supporting this extension MAY remove any information enclosed in square brackets prior to displaying human readable text to the user. Immediately following the open square bracket "[" character is a response code which is interpreted in a case-insensitive fashion by the client. The response code is hierarchical, with a "/" separating levels of detail about the error. Clients MUST ignore unknown hierarchical detail about the response code. This is important, as it could be necessary to provide further detail for response codes in the future. Section 3 describes response codes using [ABNF]. Examples: C: USER mrose S: -ERR [IN-USE] Do you have another POP session running? 8.1. Initial POP3 response codes This specification defines some POP3 response codes which can be used to determine the reason for a failed login. Additional response codes MAY be defined by publication in an RFC (standards track or IESG approved experimental RFCs are preferred). LOGIN-DELAY This occurs on an -ERR response to an AUTH, USER, PASS or APOP command and indicates that the user has logged in recently and will not be allowed to login again until the login delay period has expired. IN-USE This occurs on an -ERR response to an AUTH, APOP, or PASS command. It indicates the authentication was successful, but the user's maildrop is currently in use (probably by another POP3 client). Gellens, Newman, Lundblade [Page 11] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 9. IANA Considerations This document requests that IANA maintain two new registries: POP3 capabilities and POP3 response codes. New POP3 capabilities MUST be defined in a standards track or IESG approved experimental RFC, and MUST NOT begin with the letter "X". New POP3 capabilities MUST include the following information: CAPA tag, arguments, added commands, standard commands affected, and discussion. If the capability is available in the TRANSACTION state, and not in the AUTHORIZATION state, this MUST be stated in the description. In addition, new limits for POP3 command and response lengths may need to be included. New 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. (This is the "Specification Required" policy described in [IANA]). New 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. 10. Security Considerations A capability list can reveal information about the server's authentication capabilities which can be used to determine if certain attacks will be successful. However, allowing clients to automatically detect availability of stronger mechanisms and alter their configurations to use them can improve overall security at a site. 11. References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., November 1997. <ftp://ftp.isi.edu/in-notes/rfc2234.txt> [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", work in progress. [IMAP4] Crispin, "Internet Message Access Protocol -- Version 4rev1", RFC 2060, University of Washington, December 1996. <ftp://ftp.isi.edu/in-notes/rfc2060.txt> [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. Gellens, Newman, Lundblade [Page 12] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 <ftp://ftp.isi.edu/in-notes/rfc2119.txt> [PIPELINING] Freed, "SMTP Service Extension for Command Pipelining", RFC 2197, Innosoft, September 1997. <ftp://ftp.isi.edu/in-notes/rfc2197.txt> [POP3] Myers, Rose, "Post Office Protocol -- Version 3", RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. <ftp://ftp.isi.edu/in-notes/rfc1939.txt> [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994. <ftp://ftp.isi.edu/in-notes/rfc1734.txt> [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC 2222, Netscape Communications, October 1997. <ftp://ftp.isi.edu/in-notes/rfc2222.txt> [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, STD 10, Information Sciences Institute, August 1982. <ftp://ftp.isi.edu/in-notes/rfc821.txt> 12. Full Copyright Statement Copyright (C) The Internet Society 1998. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Authors' Addresses Gellens, Newman, Lundblade [Page 13] Expires September 1998 Internet Draft POP3 Extension Mechanism March 1998 Randall Gellens +1 619 651 5115 QUALCOMM, Incorporated +1 619 651 5334 (fax) 6455 Lusk Blvd. randy@qualcomm.com San Diego, CA 92121-2779 USA Chris Newman chris.newman@innosoft.com Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Laurence Lundblade +1 619 658 3584 QUALCOMM, Incorporated lgl@qualcomm.com 6455 Lusk Blvd. San Diego, Ca, 92121-2779 USA Gellens, Newman, Lundblade [Page 14] Expires September 1998