diff options
Diffstat (limited to 'doc/rfc/rfc2449.txt')
| -rw-r--r-- | doc/rfc/rfc2449.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc2449.txt b/doc/rfc/rfc2449.txt new file mode 100644 index 0000000..1282a34 --- /dev/null +++ b/doc/rfc/rfc2449.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group R. Gellens +Request for Comments: 2449 Qualcomm +Updates: 1939 C. Newman +Category: Standards Track Innosoft + L. Lundblade + Qualcomm + November 1998 + + + POP3 Extension Mechanism + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +IESG Note + + This extension to the POP3 protocol is to be used by a server to + express policy descisions taken by the server administrator. It is + not an endorsement of implementations of further POP3 extensions + generally. It is the general view that the POP3 protocol should stay + simple, and for the simple purpose of downloading email from a mail + server. If more complicated operations are needed, the IMAP protocol + [RFC 2060] should be used. The first paragraph of section 7 should + be read very carefully. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in this Document . . . . . . . . . . . . . 3 + 3. General Command and Response Grammar . . . . . . . . . . . . 3 + 4. Parameter and Response Lengths . . . . . . . . . . . . . . 4 + 5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5 + 6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6 + 6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6 + 6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7 + 6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8 + 6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8 + 6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9 + + + +Gellens, et. al. Standards Track [Page 1] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + 6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10 + 6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13 + 6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13 + 7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14 + 8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14 + 8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15 + 8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15 + 8.1.2. The IN-USE response code . . . . . . . . . . . . . 16 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 17 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . 17 + 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 + 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 + +1. Introduction + + The 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 (see + section 7). 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 updates RFC 1939 [POP3] to define 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, and several + new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE + and IMPLEMENTATION). 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. In addition, an [ABNF] + specification of POP3 commands and responses is defined. + + 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>. + + + + +Gellens, et. al. Standards Track [Page 2] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +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 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: + + response = greeting / single-line / capa-resp / multi-line + capa-resp = single-line *capability "." CRLF + capa-tag = 1*cchar + capability = capa-tag *(SP param) CRLF ;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 CRLF + ;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 + schar = %x21-5A / %x5C-7F + ;printable ASCII, excluding "[" + single-line = status [SP text] CRLF ;512 octets maximum + status = "+OK" / "-ERR" + text = *schar / resp-code *CHAR + timestamp = "<" *VCHAR ">" + ;MUST conform to RFC-822 msg-id + + + + + + +Gellens, et. al. Standards Track [Page 3] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +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 47 characters (4 + character command, single space, 40 character argument, CRLF) to 255 + octets, including the terminating CRLF. + + 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. + + A capability description MUST document in which states the capability + is announced, and in which states the commands are valid. + + Capabilities available in the AUTHORIZATION state MUST be announced + in both states. + + If a capability is announced in both states, but the argument might + differ after authentication, this possibility MUST be stated in the + capability description. + + (These requirements allow a client to issue only one CAPA command if + it does not use any TRANSACTION-only capabilities, or any + capabilities whose values may differ after authentication.) + + 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. + + 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. + + + + + + +Gellens, et. al. Standards Track [Page 4] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + 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: + +OK -ERR + + Examples: + C: CAPA + S: +OK Capability list follows + S: TOP + S: USER + S: SASL CRAM-MD5 KERBEROS_V4 + S: RESP-CODES + S: LOGIN-DELAY 900 + S: PIPELINING + S: EXPIRE 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. + + + +Gellens, et. al. Standards Track [Page 5] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + 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 + + Announced states / possible differences: + both / no + + Commands valid in states: + TRANSACTION + + Specification reference: + [POP3] + + Discussion: + The TOP capability indicates the optional TOP command is + available. + +6.2. USER capability + + CAPA tag: + USER + + Arguments: + none + + Added commands: + USER PASS + + Standard commands affected: + none + + + + + +Gellens, et. al. Standards Track [Page 6] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Announced states / possible differences: + both / no + + Commands valid in states: + AUTHENTICATION + + Specification reference: + [POP3] + + 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 + + Announced states / possible differences: + both / no + + Commands valid in states: + AUTHENTICATION + + Specification reference: + [POP-AUTH, SASL] + + Discussion: + The POP3 AUTH 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. + + + + + + + +Gellens, et. al. Standards Track [Page 7] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +6.4. RESP-CODES capability + + CAPA tag: + RESP-CODES + + Arguments: + none + + Added commands: + none + + Standard commands affected: + none + + Announced states / possible differences: + both / no + + Commands valid in states: + n/a + + Specification reference: + this document + + Discussion: + The RESP-CODES capability indicates that any response text issued + by this server which begins with an open square bracket ("[") is + an extended response code (see section 8). + +6.5. LOGIN-DELAY capability + + CAPA tag: + LOGIN-DELAY + + Arguments: + minimum seconds between logins; optionally followed by USER in + AUTHENTICATION state. + + Added commands: + none + + Standard commands affected: + USER PASS APOP AUTH + + Announced states / possible differences: + both / yes + + Commands valid in states: + n/a + + + +Gellens, et. al. Standards Track [Page 8] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Specification reference: + this document + + 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. + + If 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. This might be the largest value + currently in use for any user (so only one value per server), or + even the largest value which the server permits to be set for any + user. The 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. + The server SHOULD announce the more accurate value in TRANSACTION + state. (The "USER" token allows the client to decide if a second + CAPA command is needed or not.) + + Servers enforce LOGIN-DELAY by rejecting an authentication + command with or without the LOGIN-DELAY error response. See + section 8.1.1 for more information. + +6.6. PIPELINING capability + + CAPA tag: + PIPELINING + + Arguments: + none + + Added commands: + none + + Standard commands affected: + all + + + + +Gellens, et. al. Standards Track [Page 9] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Announced states / possible differences: + both / no + + Commands valid in states: + n/a + + Specification reference: + this document + + 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], however, since SMTP [SMTP] tends to have short + commands and responses, the benefit is in grouping multiple + commands and sending them as a unit. While there are cases of + this in POP (for example, USER and PASS could be batched, + multiple RETR and/or DELE commands could be sent as a group), + because POP has short commands and sometimes lengthy responses, + there is also an advantage is sending new commands while still + receiving the response to an earlier command (for example, + sending RETR and/or DELE commands while processing a UIDL reply). + +6.7. EXPIRE capability + + CAPA tag: + EXPIRE + + Arguments: + server-guaranteed minimum retention days, or NEVER; optionally + followed by USER in AUTHENTICATION state + + Added commands: + none + + + + + +Gellens, et. al. Standards Track [Page 10] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Standard commands affected: + none + + Announced states / possible differences: + both / yes + + Commands valid in states: + n/a + + Specification reference: + this document + + Discussion: + While POP3 allows clients to leave messages on the server, RFC + 1939 [POP3] warns about the problems that may arise from this, + and allows servers to delete messages based on site policy. + + The EXPIRE capability avoids the problems mentioned in RFC 1939, + by allowing the server to inform the client as to the policy in + effect. The argument to the EXPIRE capability indicates the + minimum server retention period, in days, for messages on the + server. + + EXPIRE 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. + + EXPIRE NEVER asserts that the server does not delete messages. + + The concept of a "retention period" is intentionally vague. + Servers may start counting days to expiration when a message is + added to a maildrop, when a client becomes aware of the existence + of a message through the LIST or UIDL commands, when a message + has been acted upon in some way (for example, TOP or RETR), or at + some other event. The EXPIRE capability cannot provide a precise + indication as to exactly when any specific message will expire. + The capability is intended to make it easier for clients to + behave in ways which conform to site policy and user wishes. For + example, a client might display a warning for attempts to + configure a "leave mail on server" period which is greater than + or equal to some percentage of the value announced by the server. + + If a site uses any automatic deletion policy, it SHOULD use the + EXPIRE capability to announce this. + + + + + + +Gellens, et. al. Standards Track [Page 11] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + The EXPIRE capability, with a parameter other than 0 or NEVER, is + intended to let the client know that the server does permit mail + to be left on the server, and to present a value which is the + smallest which might be in force. + + Sites which permit users to retain messages indefinitely SHOULD + announce this with the EXPIRE NEVER response. + + If 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. This might be the smallest value currently + in use for any user (so only one value per server), or even the + smallest value which the server permits to be set for any user. + The 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. The server + SHOULD announce the more accurate value in TRANSACTION state. + (The "USER" token allows the client to decide if a second CAPA + command is needed or not.) + + A site may have a message expiration policy which treats messages + differently depending on which user actions have been performed, + or based on other factors. For example, a site might delete + unseen messages after 60 days, and completely- or partially-seen + messages after 15 days. + + The announced EXPIRE value is the smallest retention period which + is or might be used by any category or condition of the current + site policy, for any user (in AUTHENTICATION state) or the + specific user (in TRANSACTION state). That is, EXPIRE informs + the client of the minimum number of days messages may remain on + the server under any circumstances. + + Examples: + EXPIRE 5 USER + EXPIRE 30 + EXPIRE NEVER + EXPIRE 0 + + The first example indicates the server might delete messages + after five days, but the period differs per user, and so a more + accurate value can be obtained by issuing a second CAPA command + in TRANSACTION state. The second example indicates the server + could delete messages after 30 days. In the third example, the + server announces it does not delete messages. The fourth example + specifies that the site does not permit messages to be left on + the server. + + + +Gellens, et. al. Standards Track [Page 12] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +6.8. UIDL capability + + CAPA tag: + UIDL + + Arguments: + none + + Added commands: + UIDL + + Standard commands affected: + none + + Announced states / possible differences: + both / no + + Commands valid in states: + TRANSACTION + + Specification reference: + [POP3] + + Discussion: + The UIDL capability indicates that the optional UIDL command is + supported. + +6.9. IMPLEMENTATION capability + + CAPA tag: + IMPLEMENTATION + + Arguments: + string giving server implementation information + + Added commands: + none + + Standard commands affected: + none + + Announced states / possible differences: + both (optionally TRANSACTION only) / no + + Commands valid in states: + n/a + + + + + +Gellens, et. al. Standards Track [Page 13] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + Specification reference: + this document + + 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 consists of one or + more tokens which identify the server. (Note that since CAPA + response tag arguments are space-separated, it may be convenient + for the IMPLEMENTATION capability argument to not contain spaces, + so that it is a single token.) + + Normally, servers announce IMPLEMENTATION in both states. + However, a server MAY chose to do so only in TRANSACTION state. + + 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. POP3 is intended as a download- + and-delete protocol; mail access capabilities are available in IMAP + [IMAP4]. Extensions which provide support for additional mailboxes, + allow uploading of messages to the server, or which deviate from + POP's download-and-delete model 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, with the exception of the authentication commands + (APOP, AUTH [section 6.3] and USER/PASS). + + Section 9 specifies how additional capabilities are defined. + +8. Extended POP3 Response Codes + + Unextended POP3 is 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 + + + + +Gellens, et. al. Standards Track [Page 14] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + (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]. + + If a server supports extended response codes, it indicates this by + including the RESP-CODES capability in the CAPA response. + + Examples: + C: APOP mrose c4c9334bac560ecc979e58001b3e22fb + S: -ERR [IN-USE] Do you have another POP session running? + +8.1. Initial POP3 response codes + + This specification defines two POP3 response codes which can be used + to determine the reason for a failed login. Section 9 specifies how + additional response codes are defined. + +8.1.1. The LOGIN-DELAY response code + + This occurs on an -ERR response to an AUTH, USER (see note), 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. + + NOTE: Returning the LOGIN-DELAY response code to the USER command + avoids the work of authenticating the user but reveals to the client + that the specified user exists. Unless the server is operating in an + environment where user names are not secret (for example, many + popular email clients advertise the POP server and user name in an + outgoing mail header), or where server access is restricted, or the + server can verify that the connection is to the same user, it is + + + + +Gellens, et. al. Standards Track [Page 15] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + strongly recommended that the server not issue this response code to + the USER command. The server still saves the cost of opening the + maildrop, which in some environments is the most expensive step. + +8.1.2. The IN-USE response code + + 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). + +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 + Announced states / possible differences + Commands valid in states + Specification reference + Discussion + + 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. + + + + + + + + + + + +Gellens, et. al. Standards Track [Page 16] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +10. Security Considerations + + A capability list can reveal information about the server's + authentication mechanisms 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. + + Section 8.1 discusses the security issues related to use of the + LOGIN-DELAY response code with the USER command. + +11. Acknowledgments + + This document has been revised in part based on comments and + discussions which took place on and off the IETF POP3 Extensions + mailing list. The help of those who took the time to review this + memo and make suggestions is appreciated, especially that of Alexey + Melnikov, Harald Alvestrand, and Mike Gahrns. + +12. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [IMAP4] Crispin, M., "Internet Message Access Protocol -- + Version 4rev1", RFC 2060, December 1996. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [PIPELINING] Freed, N., "SMTP Service Extension for Command + Pipelining", RFC 2197, September 1997. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version + 3", STD 53, RFC 1939, May 1996. + + [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, + December 1994. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + + + + +Gellens, et. al. Standards Track [Page 17] + +RFC 2449 POP3 Extension Mechanism November 1998 + + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. + +13. Authors' Addresses + + Randall Gellens + QUALCOMM Incorporated + 6455 Lusk Blvd. + San Diego, CA 92121-2779 + USA + + Phone: +1 619 651 5115 + Fax: +1 619 845 7268 + EMail: randy@qualcomm.com + + + Chris Newman + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 + USA + + EMail: chris.newman@innosoft.com + + + Laurence Lundblade + QUALCOMM Incorporated + 6455 Lusk Blvd. + San Diego, Ca, 92121-2779 + USA + + Phone: +1 619 658 3584 + Fax: +1 619 845 7268 + EMail: lgl@qualcomm.com + + + + + + + + + + + + + + + + + +Gellens, et. al. Standards Track [Page 18] + +RFC 2449 POP3 Extension Mechanism November 1998 + + +14. 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. + + + + + + + + + + + + + + + + + + + + + + + + +Gellens, et. al. Standards Track [Page 19] + |