doc/rfc2449.txt

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