rfc2449.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Chris Newman
   Innosoft International, Inc.
   1050 Lakes Drive
   West Covina, CA 91790
   USA

   EMail: [e-mail]


   Laurence Lundblade
   QUALCOMM Incorporated
   6455 Lusk Blvd.
   San Diego, Ca, 92121-2779
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

















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]