Pileus Git - ~andy/fetchmail/blob - RFC/rfc2449.txt

   1 \r
   2 \r
   3 \r
   4 \r
   5 \r
   6 \r
   7 Network Working Group                                         R. Gellens\r
   8 Request for Comments: 2449                                      Qualcomm\r
   9 Updates: 1939                                                  C. Newman\r
  10 Category: Standards Track                                       Innosoft\r
  11                                                             L. Lundblade\r
  12                                                                 Qualcomm\r
  13                                                            November 1998\r
  14 \r
  15 \r
  16                         POP3 Extension Mechanism\r
  17 \r
  18 Status of this Memo\r
  19 \r
  20    This document specifies an Internet standards track protocol for the\r
  21    Internet community, and requests discussion and suggestions for\r
  22    improvements.  Please refer to the current edition of the "Internet\r
  23    Official Protocol Standards" (STD 1) for the standardization state\r
  24    and status of this protocol.  Distribution of this memo is unlimited.\r
  25 \r
  26 Copyright Notice\r
  27 \r
  28    Copyright (C) The Internet Society (1998).  All Rights Reserved.\r
  29 \r
  30 IESG Note\r
  31 \r
  32    This extension to the POP3 protocol is to be used by a server to\r
  33    express policy descisions taken by the server administrator.  It is\r
  34    not an endorsement of implementations of further POP3 extensions\r
  35    generally.  It is the general view that the POP3 protocol should stay\r
  36    simple, and for the simple purpose of downloading email from a mail\r
  37    server.  If more complicated operations are needed, the IMAP protocol\r
  38    [RFC 2060] should be used.  The first paragraph of section 7 should\r
  39    be read very carefully.\r
  40 \r
  41 Table of Contents\r
  42 \r
  43     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2\r
  44     2.  Conventions Used in this Document . . . . . . . . . . . . .   3\r
  45     3.  General Command and Response Grammar . . . . . . . . . . . .  3\r
  46     4.  Parameter and Response Lengths  . . . . . . . . . . . . . .   4\r
  47     5.  The CAPA Command . . . . . . . . . . . . . . . . . . . . . .  4\r
  48     6.  Initial Set of Capabilities . . . . . . . . . . . . . . . .   5\r
  49       6.1.  TOP capability . . . . . . . . . . . . . . . . . . . . .  6\r
  50       6.2.  USER capability . . . . . . . . . . . . . . . . . . . .   6\r
  51       6.3.  SASL capability  . . . . . . . . . . . . . . . . . . . .  7\r
  52       6.4.  RESP-CODES capability . . . . . . . . . . . . . . . . .   8\r
  53       6.5.  LOGIN-DELAY capability . . . . . . . . . . . . . . . . .  8\r
  54       6.6.  PIPELINING capability . . . . . . . . . . . . . . . . .   9\r
  55 \r
  56 \r
  57 \r
  58 Gellens, et. al.            Standards Track                     [Page 1]\r
  59 \f\r
  60 RFC 2449                POP3 Extension Mechanism           November 1998\r
  61 \r
  62 \r
  63       6.7.  EXPIRE capability  . . . . . . . . . . . . . . . . . . . 10\r
  64       6.8.  UIDL capability . . . . . . . . . . . . . . . . . . . .  13\r
  65       6.9.  IMPLEMENTATION capability  . . . . . . . . . . . . . . . 13\r
  66     7.  Future Extensions to POP3 . . . . . . . . . . . . . . . . .  14\r
  67     8.  Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14\r
  68       8.1.  Initial POP3 response codes . . . . . . . . . . . . . .  15\r
  69         8.1.1.  The LOGIN-DELAY response code  . . . . . . . . . . . 15\r
  70         8.1.2.  The IN-USE response code  . . . . . . . . . . . . .  16\r
  71     9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16\r
  72    10.  Security Considerations . . . . . . . . . . . . . . . . . .  17\r
  73    11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 17\r
  74    12.  References  . . . . . . . . . . . . . . . . . . . . . . . .  17\r
  75    13.  Authors' Addresses  . . . . . . . . . . . . . . . . . . . .  18\r
  76    14.  Full Copyright Statement . . . . . . . . . . . . . . . . . . 19\r
  77 \r
  78 1.  Introduction\r
  79 \r
  80    The Post Office Protocol version 3 [POP3] is very widely used.\r
  81    However, while it includes some optional commands (and some useful\r
  82    protocol extensions have been published), it lacks a mechanism for\r
  83    advertising support for these extensions or for behavior variations.\r
  84 \r
  85    Currently these optional features and extensions can only be detected\r
  86    by probing, if at all.  This is at best inefficient, and possibly\r
  87    worse.  As a result, some clients have manual configuration options\r
  88    for POP3 server capabilities.\r
  89 \r
  90    Because one of the most important characteristics of POP3 is its\r
  91    simplicity, it is desirable that extensions be few in number (see\r
  92    section 7).  However, some extensions are necessary (such as ones\r
  93    that provide improved security [POP-AUTH]), while others are very\r
  94    desirable in certain situations.  In addition, a means for\r
  95    discovering server behavior is needed.\r
  96 \r
  97    This memo updates RFC 1939 [POP3] to define a mechanism to announce\r
  98    support for optional commands, extensions, and unconditional server\r
  99    behavior.  Included is an initial set of currently deployed\r
 100    capabilities which vary between server implementations, and several\r
 101    new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE\r
 102    and IMPLEMENTATION).  This document also extends POP3 error messages\r
 103    so that machine parsable codes can be provided to the client.  An\r
 104    initial set of response codes is included.  In addition, an [ABNF]\r
 105    specification of POP3 commands and responses is defined.\r
 106 \r
 107    Public comments should be sent to the IETF POP3 Extensions mailing\r
 108    list, <ietf-pop3ext@imc.org>.  To subscribe, send a message\r
 109    containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>.\r
 110 \r
 111 \r
 112 \r
 113 \r
 114 Gellens, et. al.            Standards Track                     [Page 2]\r
 115 \f\r
 116 RFC 2449                POP3 Extension Mechanism           November 1998\r
 117 \r
 118 \r
 119 2.  Conventions Used in this Document\r
 120 \r
 121    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",\r
 122    and "MAY" in this document are to be interpreted as described in "Key\r
 123    words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].\r
 124 \r
 125    In examples, "C:" and "S:" indicate lines sent by the client and\r
 126    server respectively.\r
 127 \r
 128 3.  General Command and Response Grammar\r
 129 \r
 130    The general form of POP3 commands and responses is described using\r
 131    [ABNF]:\r
 132 \r
 133    POP3 commands:\r
 134 \r
 135       command      =  keyword *(SP param) CRLF    ;255 octets maximum\r
 136       keyword      =  3*4VCHAR\r
 137       param        =  1*VCHAR\r
 138 \r
 139    POP3 responses:\r
 140 \r
 141       response     =  greeting / single-line / capa-resp / multi-line\r
 142       capa-resp    =  single-line *capability "." CRLF\r
 143       capa-tag     =  1*cchar\r
 144       capability   =  capa-tag *(SP param) CRLF   ;512 octets maximum\r
 145       cchar        =  %x21-2D / %x2F-7F\r
 146                           ;printable ASCII, excluding "."\r
 147       dot-stuffed  =  *CHAR CRLF                  ;must be dot-stuffed\r
 148       gchar        =  %x21-3B / %x3D-7F\r
 149                           ;printable ASCII, excluding "<"\r
 150       greeting     =  "+OK" [resp-code] *gchar [timestamp] *gchar CRLF\r
 151                           ;512 octets maximum\r
 152       multi-line   =  single-line *dot-stuffed "." CRLF\r
 153       rchar        =  %x21-2E / %x30-5C / %x5E-7F\r
 154                           ;printable ASCII, excluding "/" and "]"\r
 155       resp-code    =  "[" resp-level *("/" resp-level) "]"\r
 156       resp-level   =  1*rchar\r
 157       schar        =  %x21-5A / %x5C-7F\r
 158                           ;printable ASCII, excluding "["\r
 159       single-line  =  status [SP text] CRLF       ;512 octets maximum\r
 160       status       =  "+OK" / "-ERR"\r
 161       text         =  *schar / resp-code *CHAR\r
 162       timestamp    =  "<" *VCHAR ">"\r
 163                           ;MUST conform to RFC-822 msg-id\r
 164 \r
 165 \r
 166 \r
 167 \r
 168 \r
 169 \r
 170 Gellens, et. al.            Standards Track                     [Page 3]\r
 171 \f\r
 172 RFC 2449                POP3 Extension Mechanism           November 1998\r
 173 \r
 174 \r
 175 4.  Parameter and Response Lengths\r
 176 \r
 177    This specification increases the length restrictions on commands and\r
 178    parameters imposed by RFC 1939.\r
 179 \r
 180    The maximum length of a command is increased from 47 characters (4\r
 181    character command, single space, 40 character argument, CRLF) to 255\r
 182    octets, including the terminating CRLF.\r
 183 \r
 184    Servers which support the CAPA command MUST support commands up to\r
 185    255 octets.  Servers MUST also support the largest maximum command\r
 186    length specified by any supported capability.\r
 187 \r
 188    The maximum length of the first line of a command response (including\r
 189    the initial greeting) is unchanged at 512 octets (including the\r
 190    terminating CRLF).\r
 191 \r
 192 5.  The CAPA Command\r
 193 \r
 194    The POP3 CAPA command returns a list of capabilities supported by the\r
 195    POP3 server.  It is available in both the AUTHORIZATION and\r
 196    TRANSACTION states.\r
 197 \r
 198    A capability description MUST document in which states the capability\r
 199    is announced, and in which states the commands are valid.\r
 200 \r
 201    Capabilities available in the AUTHORIZATION state MUST be announced\r
 202    in both states.\r
 203 \r
 204    If a capability is announced in both states, but the argument might\r
 205    differ after authentication, this possibility MUST be stated in the\r
 206    capability description.\r
 207 \r
 208    (These requirements allow a client to issue only one CAPA command if\r
 209    it does not use any TRANSACTION-only capabilities, or any\r
 210    capabilities whose values may differ after authentication.)\r
 211 \r
 212    If the authentication step negotiates an integrity protection layer,\r
 213    the client SHOULD reissue the CAPA command after authenticating, to\r
 214    check for active down-negotiation attacks.\r
 215 \r
 216    Each capability may enable additional protocol commands, additional\r
 217    parameters and responses for existing commands, or describe an aspect\r
 218    of server behavior.  These details are specified in the description\r
 219    of the capability.\r
 220 \r
 221 \r
 222 \r
 223 \r
 224 \r
 225 \r
 226 Gellens, et. al.            Standards Track                     [Page 4]\r
 227 \f\r
 228 RFC 2449                POP3 Extension Mechanism           November 1998\r
 229 \r
 230 \r
 231    Section 3 describes the CAPA response using [ABNF].  When a\r
 232    capability response describes an optional command, the <capa-tag>\r
 233    SHOULD be identical to the command keyword.  CAPA response tags are\r
 234    case-insensitive.\r
 235 \r
 236         CAPA\r
 237 \r
 238         Arguments:\r
 239             none\r
 240 \r
 241         Restrictions:\r
 242             none\r
 243 \r
 244         Discussion:\r
 245             An -ERR response indicates the capability command is not\r
 246             implemented and the client will have to probe for\r
 247             capabilities as before.\r
 248 \r
 249             An +OK response is followed by a list of capabilities, one\r
 250             per line.  Each capability name MAY be followed by a single\r
 251             space and a space-separated list of parameters.  Each\r
 252             capability line is limited to 512 octets (including the\r
 253             CRLF).  The capability list is terminated by a line\r
 254             containing a termination octet (".") and a CRLF pair.\r
 255 \r
 256          Possible Responses:\r
 257              +OK -ERR\r
 258 \r
 259          Examples:\r
 260              C: CAPA\r
 261              S: +OK Capability list follows\r
 262              S: TOP\r
 263              S: USER\r
 264              S: SASL CRAM-MD5 KERBEROS_V4\r
 265              S: RESP-CODES\r
 266              S: LOGIN-DELAY 900\r
 267              S: PIPELINING\r
 268              S: EXPIRE 60\r
 269              S: UIDL\r
 270              S: IMPLEMENTATION Shlemazle-Plotz-v302\r
 271              S: .\r
 272 \r
 273 6.  Initial Set of Capabilities\r
 274 \r
 275    This section defines an initial set of POP3 capabilities.  These\r
 276    include the optional POP3 commands, already published POP3\r
 277    extensions, and behavior variations between POP3 servers which can\r
 278    impact clients.\r
 279 \r
 280 \r
 281 \r
 282 Gellens, et. al.            Standards Track                     [Page 5]\r
 283 \f\r
 284 RFC 2449                POP3 Extension Mechanism           November 1998\r
 285 \r
 286 \r
 287    Note that there is no APOP capability, even though APOP is an\r
 288    optional command in [POP3].  Clients discover server support of APOP\r
 289    by the presence in the greeting banner of an initial challenge\r
 290    enclosed in angle brackets ("<>").  Therefore, an APOP capability\r
 291    would introduce two ways for a server to announce the same thing.\r
 292 \r
 293 6.1.  TOP capability\r
 294 \r
 295    CAPA tag:\r
 296        TOP\r
 297 \r
 298    Arguments:\r
 299        none\r
 300 \r
 301    Added commands:\r
 302        TOP\r
 303 \r
 304    Standard commands affected:\r
 305        none\r
 306 \r
 307    Announced states / possible differences:\r
 308        both / no\r
 309 \r
 310    Commands valid in states:\r
 311        TRANSACTION\r
 312 \r
 313    Specification reference:\r
 314        [POP3]\r
 315 \r
 316    Discussion:\r
 317        The TOP capability indicates the optional TOP command is\r
 318        available.\r
 319 \r
 320 6.2.  USER capability\r
 321 \r
 322    CAPA tag:\r
 323        USER\r
 324 \r
 325    Arguments:\r
 326        none\r
 327 \r
 328    Added commands:\r
 329        USER PASS\r
 330 \r
 331    Standard commands affected:\r
 332        none\r
 333 \r
 334 \r
 335 \r
 336 \r
 337 \r
 338 Gellens, et. al.            Standards Track                     [Page 6]\r
 339 \f\r
 340 RFC 2449                POP3 Extension Mechanism           November 1998\r
 341 \r
 342 \r
 343    Announced states / possible differences:\r
 344        both / no\r
 345 \r
 346    Commands valid in states:\r
 347        AUTHENTICATION\r
 348 \r
 349    Specification reference:\r
 350        [POP3]\r
 351 \r
 352    Discussion:\r
 353        The USER capability indicates that the USER and PASS commands\r
 354        are supported, although they may not be available to all users.\r
 355 \r
 356 6.3.  SASL capability\r
 357 \r
 358    CAPA tag:\r
 359        SASL\r
 360 \r
 361    Arguments:\r
 362        Supported SASL mechanisms\r
 363 \r
 364    Added commands:\r
 365        AUTH\r
 366 \r
 367    Standard commands affected:\r
 368        none\r
 369 \r
 370    Announced states / possible differences:\r
 371        both / no\r
 372 \r
 373    Commands valid in states:\r
 374        AUTHENTICATION\r
 375 \r
 376    Specification reference:\r
 377        [POP-AUTH, SASL]\r
 378 \r
 379    Discussion:\r
 380        The POP3 AUTH command [POP-AUTH] permits the use of [SASL]\r
 381        authentication mechanisms with POP3.  The SASL capability\r
 382        indicates that the AUTH command is available and that it supports\r
 383        an optional base64 encoded second argument for an initial client\r
 384        response as described in the SASL specification.  The argument to\r
 385        the SASL capability is a space separated list of SASL mechanisms\r
 386        which are supported.\r
 387 \r
 388 \r
 389 \r
 390 \r
 391 \r
 392 \r
 393 \r
 394 Gellens, et. al.            Standards Track                     [Page 7]\r
 395 \f\r
 396 RFC 2449                POP3 Extension Mechanism           November 1998\r
 397 \r
 398 \r
 399 6.4.  RESP-CODES capability\r
 400 \r
 401    CAPA tag:\r
 402        RESP-CODES\r
 403 \r
 404    Arguments:\r
 405        none\r
 406 \r
 407    Added commands:\r
 408        none\r
 409 \r
 410    Standard commands affected:\r
 411        none\r
 412 \r
 413    Announced states / possible differences:\r
 414        both / no\r
 415 \r
 416    Commands valid in states:\r
 417        n/a\r
 418 \r
 419    Specification reference:\r
 420        this document\r
 421 \r
 422    Discussion:\r
 423        The RESP-CODES capability indicates that any response text issued\r
 424        by this server which begins with an open square bracket ("[") is\r
 425        an extended response code (see section 8).\r
 426 \r
 427 6.5.  LOGIN-DELAY capability\r
 428 \r
 429    CAPA tag:\r
 430        LOGIN-DELAY\r
 431 \r
 432    Arguments:\r
 433        minimum seconds between logins; optionally followed by USER in\r
 434        AUTHENTICATION state.\r
 435 \r
 436    Added commands:\r
 437        none\r
 438 \r
 439    Standard commands affected:\r
 440        USER PASS APOP AUTH\r
 441 \r
 442    Announced states / possible differences:\r
 443        both / yes\r
 444 \r
 445    Commands valid in states:\r
 446        n/a\r
 447 \r
 448 \r
 449 \r
 450 Gellens, et. al.            Standards Track                     [Page 8]\r
 451 \f\r
 452 RFC 2449                POP3 Extension Mechanism           November 1998\r
 453 \r
 454 \r
 455    Specification reference:\r
 456        this document\r
 457 \r
 458    Discussion:\r
 459        POP3 clients often login frequently to check for new mail.\r
 460        Unfortunately, the process of creating a connection,\r
 461        authenticating the user, and opening the user's maildrop can be\r
 462        very resource intensive on the server.  A number of deployed POP3\r
 463        servers try to reduce server load by requiring a delay between\r
 464        logins.  The LOGIN-DELAY capability includes an integer argument\r
 465        which indicates the number of seconds after an "+OK" response to\r
 466        a PASS, APOP, or AUTH command before another authentication will\r
 467        be accepted.  Clients which permit the user to configure a mail\r
 468        check interval SHOULD use this capability to determine the\r
 469        minimum permissible interval.  Servers which advertise LOGIN-\r
 470        DELAY SHOULD enforce it.\r
 471 \r
 472        If the minimum login delay period could differ per user (that is,\r
 473        the LOGIN-DELAY argument might change after authentication), the\r
 474        server MUST announce in AUTHENTICATION state the largest value\r
 475        which could be set for any user.  This might be the largest value\r
 476        currently in use for any user (so only one value per server), or\r
 477        even the largest value which the server permits to be set for any\r
 478        user.  The server SHOULD append the token "USER" to the LOGIN-\r
 479        DELAY parameter in AUTHENTICATION state, to inform the client\r
 480        that a more accurate value is available after authentication.\r
 481        The server SHOULD announce the more accurate value in TRANSACTION\r
 482        state. (The "USER" token allows the client to decide if a second\r
 483        CAPA command is needed or not.)\r
 484 \r
 485        Servers enforce LOGIN-DELAY by rejecting an authentication\r
 486        command with or without the LOGIN-DELAY error response.  See\r
 487        section 8.1.1 for more information.\r
 488 \r
 489 6.6.  PIPELINING capability\r
 490 \r
 491    CAPA tag:\r
 492        PIPELINING\r
 493 \r
 494    Arguments:\r
 495        none\r
 496 \r
 497    Added commands:\r
 498        none\r
 499 \r
 500    Standard commands affected:\r
 501        all\r
 502 \r
 503 \r
 504 \r
 505 \r
 506 Gellens, et. al.            Standards Track                     [Page 9]\r
 507 \f\r
 508 RFC 2449                POP3 Extension Mechanism           November 1998\r
 509 \r
 510 \r
 511    Announced states / possible differences:\r
 512        both / no\r
 513 \r
 514    Commands valid in states:\r
 515        n/a\r
 516 \r
 517    Specification reference:\r
 518        this document\r
 519 \r
 520    Discussion:\r
 521        The PIPELINING capability indicates the server is capable of\r
 522        accepting multiple commands at a time; the client does not have\r
 523        to wait for the response to a command before issuing a subsequent\r
 524        command.  If a server supports PIPELINING, it MUST process each\r
 525        command in turn.  If a client uses PIPELINING, it MUST keep track\r
 526        of which commands it has outstanding, and match server responses\r
 527        to commands in order.  If either the client or server uses\r
 528        blocking writes, it MUST not exceed the window size of the\r
 529        underlying transport layer.\r
 530 \r
 531        Some POP3 clients have an option to indicate the server supports\r
 532        "Overlapped POP3 commands." This capability removes the need to\r
 533        configure this at the client.\r
 534 \r
 535        This is roughly synonymous with the ESMTP PIPELINING extension\r
 536        [PIPELINING], however, since SMTP [SMTP] tends to have short\r
 537        commands and responses, the benefit is in grouping multiple\r
 538        commands and sending them as a unit.  While there are cases of\r
 539        this in POP (for example, USER and PASS could be batched,\r
 540        multiple RETR and/or DELE commands could be sent as a group),\r
 541        because POP has short commands and sometimes lengthy responses,\r
 542        there is also an advantage is sending new commands while still\r
 543        receiving the response to an earlier command (for example,\r
 544        sending RETR and/or DELE commands while processing a UIDL reply).\r
 545 \r
 546 6.7.  EXPIRE capability\r
 547 \r
 548    CAPA tag:\r
 549        EXPIRE\r
 550 \r
 551    Arguments:\r
 552        server-guaranteed minimum retention days, or NEVER; optionally\r
 553        followed by USER in AUTHENTICATION state\r
 554 \r
 555    Added commands:\r
 556        none\r
 557 \r
 558 \r
 559 \r
 560 \r
 561 \r
 562 Gellens, et. al.            Standards Track                    [Page 10]\r
 563 \f\r
 564 RFC 2449                POP3 Extension Mechanism           November 1998\r
 565 \r
 566 \r
 567    Standard commands affected:\r
 568        none\r
 569 \r
 570    Announced states / possible differences:\r
 571        both / yes\r
 572 \r
 573    Commands valid in states:\r
 574        n/a\r
 575 \r
 576    Specification reference:\r
 577        this document\r
 578 \r
 579    Discussion:\r
 580        While POP3 allows clients to leave messages on the server, RFC\r
 581        1939 [POP3] warns about the problems that may arise from this,\r
 582        and allows servers to delete messages based on site policy.\r
 583 \r
 584        The EXPIRE capability avoids the problems mentioned in RFC 1939,\r
 585        by allowing the server to inform the client as to the policy in\r
 586        effect.  The argument to the EXPIRE capability indicates the\r
 587        minimum server retention period, in days, for messages on the\r
 588        server.\r
 589 \r
 590        EXPIRE 0 indicates the client is not permitted to leave mail on\r
 591        the server; when the session enters the UPDATE state the server\r
 592        MAY assume an implicit DELE for each message which was downloaded\r
 593        with RETR.\r
 594 \r
 595        EXPIRE NEVER asserts that the server does not delete messages.\r
 596 \r
 597        The concept of a "retention period" is intentionally vague.\r
 598        Servers may start counting days to expiration when a message is\r
 599        added to a maildrop, when a client becomes aware of the existence\r
 600        of a message through the LIST or UIDL commands, when a message\r
 601        has been acted upon in some way (for example, TOP or RETR), or at\r
 602        some other event.  The EXPIRE capability cannot provide a precise\r
 603        indication as to exactly when any specific message will expire.\r
 604        The capability is intended to make it easier for clients to\r
 605        behave in ways which conform to site policy and user wishes.  For\r
 606        example, a client might display a warning for attempts to\r
 607        configure a "leave mail on server" period which is greater than\r
 608        or equal to some percentage of the value announced by the server.\r
 609 \r
 610        If a site uses any automatic deletion policy, it SHOULD use the\r
 611        EXPIRE capability to announce this.\r
 612 \r
 613 \r
 614 \r
 615 \r
 616 \r
 617 \r
 618 Gellens, et. al.            Standards Track                    [Page 11]\r
 619 \f\r
 620 RFC 2449                POP3 Extension Mechanism           November 1998\r
 621 \r
 622 \r
 623        The EXPIRE capability, with a parameter other than 0 or NEVER, is\r
 624        intended to let the client know that the server does permit mail\r
 625        to be left on the server, and to present a value which is the\r
 626        smallest which might be in force.\r
 627 \r
 628        Sites which permit users to retain messages indefinitely SHOULD\r
 629        announce this with the EXPIRE NEVER response.\r
 630 \r
 631        If the expiration policy differs per user (that is, the EXPIRE\r
 632        argument might change after authentication), the server MUST\r
 633        announce in AUTHENTICATION state the smallest value which could\r
 634        be set for any user.  This might be the smallest value currently\r
 635        in use for any user (so only one value per server), or even the\r
 636        smallest value which the server permits to be set for any user.\r
 637        The server SHOULD append the token "USER" to the EXPIRE parameter\r
 638        in AUTHENTICATION state, to inform the client that a more\r
 639        accurate value is available after authentication.  The server\r
 640        SHOULD announce the more accurate value in TRANSACTION state.\r
 641        (The "USER" token allows the client to decide if a second CAPA\r
 642        command is needed or not.)\r
 643 \r
 644        A site may have a message expiration policy which treats messages\r
 645        differently depending on which user actions have been performed,\r
 646        or based on other factors.  For example, a site might delete\r
 647        unseen messages after 60 days, and completely- or partially-seen\r
 648        messages after 15 days.\r
 649 \r
 650        The announced EXPIRE value is the smallest retention period which\r
 651        is or might be used by any category or condition of the current\r
 652        site policy, for any user (in AUTHENTICATION state) or the\r
 653        specific user (in TRANSACTION state).  That is, EXPIRE informs\r
 654        the client of the minimum number of days messages may remain on\r
 655        the server under any circumstances.\r
 656 \r
 657        Examples:\r
 658            EXPIRE 5 USER\r
 659            EXPIRE 30\r
 660            EXPIRE NEVER\r
 661            EXPIRE 0\r
 662 \r
 663        The first example indicates the server might delete messages\r
 664        after five days, but the period differs per user, and so a more\r
 665        accurate value can be obtained by issuing a second CAPA command\r
 666        in TRANSACTION state.  The second example indicates the server\r
 667        could delete messages after 30 days.  In the third example, the\r
 668        server announces it does not delete messages.  The fourth example\r
 669        specifies that the site does not permit messages to be left on\r
 670        the server.\r
 671 \r
 672 \r
 673 \r
 674 Gellens, et. al.            Standards Track                    [Page 12]\r
 675 \f\r
 676 RFC 2449                POP3 Extension Mechanism           November 1998\r
 677 \r
 678 \r
 679 6.8.  UIDL capability\r
 680 \r
 681    CAPA tag:\r
 682        UIDL\r
 683 \r
 684    Arguments:\r
 685        none\r
 686 \r
 687    Added commands:\r
 688        UIDL\r
 689 \r
 690    Standard commands affected:\r
 691        none\r
 692 \r
 693    Announced states / possible differences:\r
 694        both / no\r
 695 \r
 696    Commands valid in states:\r
 697        TRANSACTION\r
 698 \r
 699    Specification reference:\r
 700        [POP3]\r
 701 \r
 702    Discussion:\r
 703        The UIDL capability indicates that the optional UIDL command is\r
 704        supported.\r
 705 \r
 706 6.9.  IMPLEMENTATION capability\r
 707 \r
 708    CAPA tag:\r
 709        IMPLEMENTATION\r
 710 \r
 711    Arguments:\r
 712        string giving server implementation information\r
 713 \r
 714    Added commands:\r
 715        none\r
 716 \r
 717    Standard commands affected:\r
 718        none\r
 719 \r
 720    Announced states / possible differences:\r
 721        both (optionally TRANSACTION only) / no\r
 722 \r
 723    Commands valid in states:\r
 724        n/a\r
 725 \r
 726 \r
 727 \r
 728 \r
 729 \r
 730 Gellens, et. al.            Standards Track                    [Page 13]\r
 731 \f\r
 732 RFC 2449                POP3 Extension Mechanism           November 1998\r
 733 \r
 734 \r
 735    Specification reference:\r
 736        this document\r
 737 \r
 738    Discussion:\r
 739        It is often useful to identify an implementation of a particular\r
 740        server (for example, when logging).  This is commonly done in the\r
 741        welcome banner, but one must guess if a string is an\r
 742        implementation ID or not.\r
 743 \r
 744        The argument to the IMPLEMENTATION capability consists of one or\r
 745        more tokens which identify the server. (Note that since CAPA\r
 746        response tag arguments are space-separated, it may be convenient\r
 747        for the IMPLEMENTATION capability argument to not contain spaces,\r
 748        so that it is a single token.)\r
 749 \r
 750        Normally, servers announce IMPLEMENTATION in both states.\r
 751        However, a server MAY chose to do so only in TRANSACTION state.\r
 752 \r
 753        A server MAY include the implementation identification both in\r
 754        the welcome banner and in the IMPLEMENTATION capability.\r
 755 \r
 756        Clients MUST NOT modify their behavior based on the server\r
 757        implementation.  Instead the server and client should agree on a\r
 758        private extension.\r
 759 \r
 760 7.  Future Extensions to POP3\r
 761 \r
 762    Future extensions to POP3 are in general discouraged, as POP3's\r
 763    usefulness lies in its simplicity.  POP3 is intended as a download-\r
 764    and-delete protocol; mail access capabilities are available in IMAP\r
 765    [IMAP4].  Extensions which provide support for additional mailboxes,\r
 766    allow uploading of messages to the server, or which deviate from\r
 767    POP's download-and-delete model are strongly discouraged and unlikely\r
 768    to be permitted on the IETF standards track.\r
 769 \r
 770    Clients MUST NOT require the presence of any extension for basic\r
 771    functionality, with the exception of the authentication commands\r
 772    (APOP, AUTH [section 6.3] and USER/PASS).\r
 773 \r
 774    Section 9 specifies how additional capabilities are defined.\r
 775 \r
 776 8.  Extended POP3 Response Codes\r
 777 \r
 778    Unextended POP3 is only capable of indicating success or failure to\r
 779    most commands.  Unfortunately, clients often need to know more\r
 780    information about the cause of a failure in order to gracefully\r
 781    recover.  This is especially important in response to a failed login\r
 782 \r
 783 \r
 784 \r
 785 \r
 786 Gellens, et. al.            Standards Track                    [Page 14]\r
 787 \f\r
 788 RFC 2449                POP3 Extension Mechanism           November 1998\r
 789 \r
 790 \r
 791    (there are widely-deployed clients which attempt to decode the error\r
 792    text of a PASS command result, to try and distinguish between "unable\r
 793    to get maildrop lock" and "bad login").\r
 794 \r
 795    This specification amends the POP3 standard to permit an optional\r
 796    response code, enclosed in square brackets, at the beginning of the\r
 797    human readable text portion of an "+OK" or "-ERR" response.  Clients\r
 798    supporting this extension MAY remove any information enclosed in\r
 799    square brackets prior to displaying human readable text to the user.\r
 800    Immediately following the open square bracket "[" character is a\r
 801    response code which is interpreted in a case-insensitive fashion by\r
 802    the client.\r
 803 \r
 804    The response code is hierarchical, with a "/" separating levels of\r
 805    detail about the error.  Clients MUST ignore unknown hierarchical\r
 806    detail about the response code.  This is important, as it could be\r
 807    necessary to provide further detail for response codes in the future.\r
 808 \r
 809    Section 3 describes response codes using [ABNF].\r
 810 \r
 811    If a server supports extended response codes, it indicates this by\r
 812    including the RESP-CODES capability in the CAPA response.\r
 813 \r
 814    Examples:\r
 815            C: APOP mrose c4c9334bac560ecc979e58001b3e22fb\r
 816            S: -ERR [IN-USE] Do you have another POP session running?\r
 817 \r
 818 8.1.  Initial POP3 response codes\r
 819 \r
 820    This specification defines two POP3 response codes which can be used\r
 821    to determine the reason for a failed login.  Section 9 specifies how\r
 822    additional response codes are defined.\r
 823 \r
 824 8.1.1.  The LOGIN-DELAY response code\r
 825 \r
 826    This occurs on an -ERR response to an AUTH, USER (see note), PASS or\r
 827    APOP command and indicates that the user has logged in recently and\r
 828    will not be allowed to login again until the login delay period has\r
 829    expired.\r
 830 \r
 831    NOTE:  Returning the LOGIN-DELAY response code to the USER command\r
 832    avoids the work of authenticating the user but reveals to the client\r
 833    that the specified user exists.  Unless the server is operating in an\r
 834    environment where user names are not secret (for example, many\r
 835    popular email clients advertise the POP server and user name in an\r
 836    outgoing mail header), or where server access is restricted, or the\r
 837    server can verify that the connection is to the same user, it is\r
 838 \r
 839 \r
 840 \r
 841 \r
 842 Gellens, et. al.            Standards Track                    [Page 15]\r
 843 \f\r
 844 RFC 2449                POP3 Extension Mechanism           November 1998\r
 845 \r
 846 \r
 847    strongly recommended that the server not issue this response code to\r
 848    the USER command.  The server still saves the cost of opening the\r
 849    maildrop, which in some environments is the most expensive step.\r
 850 \r
 851 8.1.2.  The IN-USE response code\r
 852 \r
 853    This occurs on an -ERR response to an AUTH, APOP, or PASS command.\r
 854    It indicates the authentication was successful, but the user's\r
 855    maildrop is currently in use (probably by another POP3 client).\r
 856 \r
 857 9.  IANA Considerations\r
 858 \r
 859    This document requests that IANA maintain two new registries:  POP3\r
 860    capabilities and POP3 response codes.\r
 861 \r
 862    New POP3 capabilities MUST be defined in a standards track or IESG\r
 863    approved experimental RFC, and MUST NOT begin with the letter "X".\r
 864 \r
 865    New POP3 capabilities MUST include the following information:\r
 866         CAPA tag\r
 867         Arguments\r
 868         Added commands\r
 869         Standard commands affected\r
 870         Announced states / possible differences\r
 871         Commands valid in states\r
 872         Specification reference\r
 873         Discussion\r
 874 \r
 875    In addition, new limits for POP3 command and response lengths may\r
 876    need to be included.\r
 877 \r
 878    New POP3 response codes MUST be defined in an RFC or other permanent\r
 879    and readily available reference, in sufficient detail so that\r
 880    interoperability between independent implementations is possible.\r
 881    (This is the "Specification Required" policy described in [IANA]).\r
 882 \r
 883    New POP3 response code specifications MUST include the following\r
 884    information: the complete response code, for which responses (+OK\r
 885    or -ERR) and commands it is valid, and a definition of its meaning and\r
 886    expected client behavior.\r
 887 \r
 888 \r
 889 \r
 890 \r
 891 \r
 892 \r
 893 \r
 894 \r
 895 \r
 896 \r
 897 \r
 898 Gellens, et. al.            Standards Track                    [Page 16]\r
 899 \f\r
 900 RFC 2449                POP3 Extension Mechanism           November 1998\r
 901 \r
 902 \r
 903 10.  Security Considerations\r
 904 \r
 905    A capability list can reveal information about the server's\r
 906    authentication mechanisms which can be used to determine if certain\r
 907    attacks will be successful.  However, allowing clients to\r
 908    automatically detect availability of stronger mechanisms and alter\r
 909    their configurations to use them can improve overall security at a\r
 910    site.\r
 911 \r
 912    Section 8.1 discusses the security issues related to use of the\r
 913    LOGIN-DELAY response code with the USER command.\r
 914 \r
 915 11.  Acknowledgments\r
 916 \r
 917    This document has been revised in part based on comments and\r
 918    discussions which took place on and off the IETF POP3 Extensions\r
 919    mailing list.  The help of those who took the time to review this\r
 920    memo and make suggestions is appreciated, especially that of Alexey\r
 921    Melnikov, Harald Alvestrand, and Mike Gahrns.\r
 922 \r
 923 12.  References\r
 924 \r
 925    [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax\r
 926                 Specifications:  ABNF", RFC 2234, November 1997.\r
 927 \r
 928    [IANA]       Narten, T. and H. Alvestrand, "Guidelines for Writing an\r
 929                 IANA Considerations Section in RFCs", BCP 26, RFC 2434,\r
 930                 October 1998.\r
 931 \r
 932    [IMAP4]      Crispin, M., "Internet Message Access Protocol --\r
 933                 Version 4rev1", RFC 2060, December 1996.\r
 934 \r
 935    [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate\r
 936                 Requirement Levels", BCP 14, RFC 2119, March 1997.\r
 937 \r
 938    [PIPELINING] Freed, N., "SMTP Service Extension for Command\r
 939                 Pipelining", RFC 2197, September 1997.\r
 940 \r
 941    [POP3]       Myers, J. and M. Rose, "Post Office Protocol -- Version\r
 942                 3", STD 53, RFC 1939, May 1996.\r
 943 \r
 944    [POP-AUTH]   Myers, J., "POP3 AUTHentication command", RFC 1734,\r
 945                 December 1994.\r
 946 \r
 947    [SASL]       Myers, J., "Simple Authentication and Security Layer\r
 948                 (SASL)", RFC 2222, October 1997.\r
 949 \r
 950 \r
 951 \r
 952 \r
 953 \r
 954 Gellens, et. al.            Standards Track                    [Page 17]\r
 955 \f\r
 956 RFC 2449                POP3 Extension Mechanism           November 1998\r
 957 \r
 958 \r
 959    [SMTP]       Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC\r
 960                 821, August 1982.\r
 961 \r
 962 13.  Authors' Addresses\r
 963 \r
 964    Randall Gellens\r
 965    QUALCOMM Incorporated\r
 966    6455 Lusk Blvd.\r
 967    San Diego, CA  92121-2779\r
 968    USA\r
 969 \r
 970    Phone: +1 619 651 5115\r
 971    Fax:   +1 619 845 7268\r
 972    EMail: randy@qualcomm.com\r
 973 \r
 974 \r
 975    Chris Newman\r
 976    Innosoft International, Inc.\r
 977    1050 Lakes Drive\r
 978    West Covina, CA 91790\r
 979    USA\r
 980 \r
 981    EMail: chris.newman@innosoft.com\r
 982 \r
 983 \r
 984    Laurence Lundblade\r
 985    QUALCOMM Incorporated\r
 986    6455 Lusk Blvd.\r
 987    San Diego, Ca, 92121-2779\r
 988    USA\r
 989 \r
 990    Phone: +1 619 658 3584\r
 991    Fax:   +1 619 845 7268\r
 992    EMail: lgl@qualcomm.com\r
 993 \r
 994 \r
 995 \r
 996 \r
 997 \r
 998 \r
 999 \r
1000 \r
1001 \r
1002 \r
1003 \r
1004 \r
1005 \r
1006 \r
1007 \r
1008 \r
1009 \r
1010 Gellens, et. al.            Standards Track                    [Page 18]\r
1011 \f\r
1012 RFC 2449                POP3 Extension Mechanism           November 1998\r
1013 \r
1014 \r
1015 14.  Full Copyright Statement\r
1016 \r
1017    Copyright (C) The Internet Society (1998).  All Rights Reserved.\r
1018 \r
1019    This document and translations of it may be copied and furnished to\r
1020    others, and derivative works that comment on or otherwise explain it\r
1021    or assist in its implementation may be prepared, copied, published\r
1022    and distributed, in whole or in part, without restriction of any\r
1023    kind, provided that the above copyright notice and this paragraph are\r
1024    included on all such copies and derivative works.  However, this\r
1025    document itself may not be modified in any way, such as by removing\r
1026    the copyright notice or references to the Internet Society or other\r
1027    Internet organizations, except as needed for the purpose of\r
1028    developing Internet standards in which case the procedures for\r
1029    copyrights defined in the Internet Standards process must be\r
1030    followed, or as required to translate it into languages other than\r
1031    English.\r
1032 \r
1033    The limited permissions granted above are perpetual and will not be\r
1034    revoked by the Internet Society or its successors or assigns.\r
1035 \r
1036    This document and the information contained herein is provided on an\r
1037    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
1038    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
1039    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
1040    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
1041    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
1042 \r
1043 \r
1044 \r
1045 \r
1046 \r
1047 \r
1048 \r
1049 \r
1050 \r
1051 \r
1052 \r
1053 \r
1054 \r
1055 \r
1056 \r
1057 \r
1058 \r
1059 \r
1060 \r
1061 \r
1062 \r
1063 \r
1064 \r
1065 \r
1066 Gellens, et. al.            Standards Track                    [Page 19]\r
1067 \f\r