rfc2449.txt

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

   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