From fdec8d6cf10bfd061d98d8b790bb71985ed36e3a Mon Sep 17 00:00:00 2001 From: Graham Wilson Date: Mon, 29 Nov 2004 16:40:04 +0000 Subject: Remove RFCs from the trunk, since we don't distribute them anyways. All of the removed RFCs are listed in the design-notes.html file, with the exception of NNTP (RFC977). Also add a link to the "LAN Mail Protocols" document to the design-notes.html file. svn path=/trunk/; revision=4013 --- RFC/rfc2449.txt | 1067 ------------------------------------------------------- 1 file changed, 1067 deletions(-) delete mode 100644 RFC/rfc2449.txt (limited to 'RFC/rfc2449.txt') diff --git a/RFC/rfc2449.txt b/RFC/rfc2449.txt deleted file mode 100644 index dbea10b2..00000000 --- a/RFC/rfc2449.txt +++ /dev/null @@ -1,1067 +0,0 @@ - - - - - - -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, . To subscribe, send a message - containing SUBSCRIBE to . - - - - -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 - 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] - -- cgit v1.2.3