GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2449

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2449.txt · Last modified: 1998/11/17 22:52 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki