doc: Add RFC documents

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]
+