rfc2449.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/3 页

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, <[e-mail]>.  To subscribe, send a message
   containing SUBSCRIBE to <[e-mail]>.




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