Network Working Group C. Newman Internet Draft: POP3 Extension Mechanism Innosoft Document: draft-newman-pop3ext-00.txt November 1997 POP3 Extension Mechanism and Error Codes 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society 1997. All Rights Reserved. Introduction The POP3 protocol [POP3] includes a number of optional commands and some useful protocol extensions have also been published. Currently these optional features and extensions can only be detected by probing. This has resulted in some clients including manual configuration options for POP3 server capabilities. Because one of the most important features of POP3 is its simplicity, it is not desirable to have a lot of extensions. However, some extensions are necessary such as ones that provide improved security [POP-AUTH]. This specification defines a mechanism to detect such extensions and the availability of optional commands. Included is an initial set of currently implemented capabilities which vary between server implementations. Newman [Page 1]
Internet Draft POP3 Extension Mechanism November 1997 This also extends POP3 error messages so that machine parsible codes can be provided to the client. This is an preliminary proposal. Please do not implement it. Comments can be sent directly to the author. 0. Feedback Requested This is a moderately dangerous proposal as it might encourage haphazard extension of the POP3 protocol. However, it is believed that the benefit of being able to discover capabilities outwieghs this. Do you agree? The error codes would be ugly to current clients, but shouldn't cause interoperability problems. It is speculated that the ability to communicate more precise error information to the client outwieghs the ugliness impact on existing POP3 client error messages. Do you agree? I know of at least two POP3 servers which offer the LOGIN-DELAY facility unannounced today. I am also told that at least one client fails to communicate with these servers when the facility is enabled. Formalizing it would encourage those clients to hold the connection open rather than re-connecting to download each message as the user reads them. This is probably a good thing, but that client vendor probably dislikes the idea. Should LOGIN-DELAY be left in this specification or should it remain an unannounced facility of deployed POP3 servers? Suggestions for more initial error codes or more capabilities which document variation in deployed POP3 servers is requested. 1. 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 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. Newman [Page 2]
Internet Draft POP3 Extension Mechanism November 1997 2. The POP3 CAPA command The POP3 CAPA command will return a list of capabilities supported by the POP3 server. It is available in both AUTHORIZATION state and TRANSACTION state. Additional capabilities MAY become available in TRANSACTION state, but all capabilities listed in AUTHORIZATION state MUST also be available. CAPA Arguments: none Restrictions: none Discussion: If the server responds to the CAPA command with -ERR, that indicates the capability command is not implemented and the client will have to probe for capabilities as before. If the server responds with +OK, that will be followed by a list of capabilities, one per line. Each capability name MAY be followed by an "=" sign and arguments. The capability list is terminated by a line containing a termination octet (".") and a CRLF pair. Possible Responses: +OK -ERR Examples: C: CAPA S: +OK Capability list follows S: TOP S: UIDL S: USER S: APOP S: SASL=CRAM-MD5 KERBEROS_V4 S: LOGIN-DELAY=240 S: OVERLAP S: . 3. 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. Newman [Page 3]
Internet Draft POP3 Extension Mechanism November 1997 3.1. POP3 Optional Command Capabilities The "TOP" capability indicates the "TOP" command is available. The "UIDL" capability indicates the "UIDL" command is available. The "APOP" capability indicates that APOP authentication is supported, although it may not be available to all users. The "USER" capability indicates that the USER and PASS commands are supported, although they may not be available to all users. 3.2. POP3 SASL capability The POP3 AUTHentication command [POP-AUTH] permits the use of SASL [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. 3.3. LOGIN-DELAY capability POP3 clients often login frequently to check for new mail. Unfortunately, the process of creating a connection, logging in 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 a decimal number argument which indicates the number of seconds required between logins for a given user. Clients which permit the user to configure a mail check interval can use this capability to determine the minimum permissible interval. Servers which advertise LOGIN-DELAY SHOULD enforce it. 3.4. OVERLAP capability The OVERLAP capability indicates the server is capable of accepting multiple commands at a time (up to 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 that at the client. This is roughly synonymous with the ESMTP PIPELINING extension [PIPELINING]. Newman [Page 4]
Internet Draft POP3 Extension Mechanism November 1997 4. Furture Extensions to POP3 Future extensions to POP3 are 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. 5. 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. 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 a "+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. For example, ENCRYPT-NEEDED/TLS and ENCRYPT-NEEDED/SSH might indicate a suggestion to use the TLS or SSH protocols respectively for encryption. Examples: C: USER mrose S: -ERR [ENCRYPT-NEEDED] You need to activate encryption before logging in. Newman [Page 5]
Internet Draft POP3 Extension Mechanism November 1997 5.1. 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 a -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. PASS-EXPIRED This occurs on a -ERR response to an AUTH, USER, PASS or APOP command and indicates the user will not be allowed to login until his password/passphrase is changed. ENCRYPT-NEEDED This occurs on an -ERR response to an AUTH, USER or APOP command and indicates that the requested authentication mechanism is only permitted underneath a security layer. The client MAY take action to activate a security layer and repeat the same AUTH, USER or APOP command or try an AUTH command with a stronger mechanism. The client SHOULD record the fact that encryption is needed for that user, server and mechanism combination. AUTH-TOO-WEAK This occurs on an -ERR response to an AUTH, USER or APOP command and indicates that the mechanism is too weak and is no longer permitted for that user by site policy. This allows a mechanism to be disabled on a per-user rather than a per-server level which is useful if different users have different security requirements or for transitioning from plaintext USER/PASS to a more secure mechanism. The client SHOULD record the fact that the user, server and mechanism combination is no longer permitted. TRANSITION-NEEDED This occurs on an -ERR response to an AUTH or APOP command. It indicates that the server has an entry for the specified user in a legacy authentication database but does not yet have credentials to offer the requested mechanism. A client which receives this error code MAY do a one-time login using the USER/PASS commands or another plaintext mechanism (preferably protected by a privacy layer) to initialize Newman [Page 6]
Internet Draft POP3 Extension Mechanism November 1997 credentials for the requested mechanism. 6. 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. The TRANSITION-NEEDED error code can be insertted by an active attacker in an attempt to get the client to send the user's password unencrypted. Clients SHOULD prompt the user to get permission prior to transition. The additional error codes will allow gradual upgrading of security services on a per-user basis so they can improve overall security at a site. 7. References [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. <ftp://ds.internic.net/rfc/rfc2060.txt> [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. <ftp://ds.internic.net/rfc/rfc2119.txt> [PIPELINING] Freed, "SMTP Service Extension for Command Pipelining", RFC 2197, Innosoft, September 1997. <ftp://ds.internic.net/rfc/rfc2197.txt> [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. <ftp://ds.internic.net/rfc/rfc1939.txt> [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994. <ftp://ds.internic.net/rfc/rfc1734.txt> Newman [Page 7]
Internet Draft POP3 Extension Mechanism November 1997 [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC 2222, Netscape Communications, October 1997. <ftp://ds.internic.net/rfc/rfc2222.txt> 8. Full Copyright Statement Copyright (C) The Internet Society 1997. 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 implmentation 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. 9. Author's Address Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Email: chris.newman@innosoft.com Newman [Page 8]