idnits 2.17.1 draft-gellens-pop3ext-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (4 September 1998) is 9337 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IN-USE' is mentioned on line 698, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2197 (ref. 'PIPELINING') (Obsoleted by RFC 2920) ** Obsolete normative reference: RFC 1734 (ref. 'POP-AUTH') (Obsoleted by RFC 5034) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: POP3 Extension Mechanism R. Gellens 3 Document: draft-gellens-pop3ext-08.txt Qualcomm 4 Expires: 4 March 1999 C. Newman 5 Innosoft 6 L. Lundblade 7 Qualcomm 8 4 September 1998 10 POP3 Extension Mechanism 12 Status of this Memo: 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a 23 "working draft" or "work in progress." 25 To learn the current status of any Internet Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet Drafts shadow 27 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Comments: 33 A version of this draft document will be submitted to the RFC editor 34 as a Proposed Standard for the Internet Community. Discussion and 35 suggestions for improvement are requested. 37 Public comments should be sent to the IETF POP3 Extensions mailing 38 list, . To subscribe, send a message 39 containing SUBSCRIBE to . This list 40 will remain active after publication. Private comments may be sent 41 to the authors. 43 Copyright Notice 45 Copyright (C) The Internet Society 1998. All Rights Reserved. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions Used in this Document . . . . . . . . . . . . . 3 51 3. General Command and Response Grammar . . . . . . . . . . . . 3 52 4. Parameter and Response Lengths . . . . . . . . . . . . . . 4 53 5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4 54 6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5 55 6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 5 56 6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6 57 6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7 58 6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 7 59 6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8 60 6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9 61 6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10 62 6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 12 63 6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 12 64 7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 13 65 8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14 66 8.1. Initial POP3 response codes . . . . . . . . . . . . . . 14 67 8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 14 68 8.1.2. The IN-USE response code . . . . . . . . . . . . . 15 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 70 10. Security Considerations . . . . . . . . . . . . . . . . . . 16 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . 16 73 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 74 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 The Post Office Protocol version 3 [POP3] is very widely used. 79 However, while it includes some optional commands (and some useful 80 protocol extensions have been published), it lacks a mechanism for 81 advertising support for these extensions or for behavior variations. 83 Currently these optional features and extensions can only be 84 detected by probing, if at all. This is at best inefficient, and 85 possibly worse. As a result, some clients have manual configuration 86 options for POP3 server capabilities. 88 Because one of the most important characteristics of POP3 is its 89 simplicity, it is desirable that extensions be few in number (see 90 section 7). However, some extensions are necessary (such as ones 91 that provide improved security [POP-AUTH]), while others are very 92 desirable in certain situations. In addition, a means for 93 discovering server behavior is needed. 95 This memo defines a mechanism to announce support for optional 96 commands, extensions, and unconditional server behavior. Included 97 is an initial set of currently deployed capabilities which vary 98 between server implementations. This document also extends POP3 99 error messages so that machine parsable codes can be provided to the 100 client. An initial set of response codes is included. 102 2. Conventions Used in this Document 104 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 105 NOT", and "MAY" in this document are to be interpreted as described 106 in "Key words for use in RFCs to Indicate Requirement Levels" 107 [KEYWORDS]. 109 In examples, "C:" and "S:" indicate lines sent by the client and 110 server respectively. 112 3. General Command and Response Grammar 114 The general form of POP3 commands and responses is described using 115 [ABNF]: 117 POP3 commands: 119 command = keyword *(SP param) CRLF ;255 octets maximum 120 keyword = 3*4VCHAR 121 param = 1*VCHAR 123 POP3 responses: 125 response = greeting / single-line / capa-resp / multi-line 126 capa-resp = single-line *capability "." CRLF 127 capa-tag = 1*cchar 128 capability = capa-tag *(SP param) CRLF ;512 octets maximum 129 cchar = %x21-2D / %x2F-7F 130 ;printable ASCII, excluding "." 131 dot-stuffed = *CHAR CRLF ;must be dot-stuffed 132 gchar = %x21-3B / %x3D-7F 133 ;printable ASCII, excluding "<" 134 greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF 135 ;512 octets maximum 136 multi-line = single-line *dot-stuffed "." CRLF 137 rchar = %x21-2E / %x30-5C / %x5E-7F 138 ;printable ASCII, excluding "/" and "]" 139 resp-code = "[" resp-level *("/" resp-level) "]" 140 resp-level = 1*rchar 141 schar = %x21-5A / %x5C-7F 142 ;printable ASCII, excluding "[" 143 single-line = status [SP text] CRLF ;512 octets maximum 144 status = "+OK" / "-ERR" 145 text = *schar / resp-code *CHAR 146 timestamp = "<" *VCHAR ">" 147 ;MUST conform to RFC-822 msg-id 148 4. Parameter and Response Lengths 150 This specification increases the length restrictions on commands and 151 parameters imposed by RFC 1939. 153 The maximum length of a command is increased from 47 characters (4 154 character command, single space, 40 character argument, CRLF) to 255 155 octets, including the terminating CRLF. 157 Servers which support the CAPA command MUST support commands up to 158 255 octets. Servers MUST also support the largest maximum command 159 length specified by any supported capability. 161 The maximum length of the first line of a command response 162 (including the initial greeting) is unchanged at 512 octets 163 (including the terminating CRLF). 165 5. The CAPA Command 167 The POP3 CAPA command returns a list of capabilities supported by 168 the POP3 server. It is available in both the AUTHORIZATION and 169 TRANSACTION states. 171 A capability description MUST document in which states the 172 capability is announced, and in which states the commands are valid. 174 Capabilities available in the AUTHORIZATION state MUST be announced 175 in both states. 177 If a capability is announced in both states, but the argument might 178 differ after authentication, this possibility MUST be stated in the 179 capability description. 181 (These requirements allow a client to issue only one CAPA command if 182 it does not use any TRANSACTION-only capabilities, or any 183 capabilities whose values may differ after authentication.) 185 If the authentication step negotiates an integrity protection layer, 186 the client SHOULD reissue the CAPA command after authenticating, to 187 check for active down-negotiation attacks. 189 Each capability may enable additional protocol commands, additional 190 parameters and responses for existing commands, or describe an 191 aspect of server behavior. These details are specified in the 192 description of the capability. 194 Section 3 describes the CAPA response using [ABNF]. When a 195 capability response describes an optional command, the 196 SHOULD be identical to the command keyword. CAPA response tags are 197 case-insensitive. 199 CAPA 201 Arguments: 202 none 204 Restrictions: 205 none 207 Discussion: 208 An -ERR response indicates the capability command is not 209 implemented and the client will have to probe for 210 capabilities as before. 212 An +OK response is followed by a list of capabilities, one 213 per line. Each capability name MAY be followed by a single 214 space and a space-separated list of parameters. Each 215 capability line is limited to 512 octets (including the 216 CRLF). The capability list is terminated by a line 217 containing a termination octet (".") and a CRLF pair. 219 Possible Responses: 220 +OK -ERR 222 Examples: 223 C: CAPA 224 S: +OK Capability list follows 225 S: TOP 226 S: USER 227 S: SASL CRAM-MD5 KERBEROS_V4 228 S: RESP-CODES 229 S: LOGIN-DELAY 900 230 S: PIPELINING 231 S: EXPIRE 60 232 S: UIDL 233 S: IMPLEMENTATION Shlemazle-Plotz-v302 234 S: . 236 6. Initial Set of Capabilities 238 This section defines an initial set of POP3 capabilities. These 239 include the optional POP3 commands, already published POP3 240 extensions, and behavior variations between POP3 servers which can 241 impact clients. 243 Note that there is no APOP capability, even though APOP is an 244 optional command in [POP3]. Clients discover server support of APOP 245 by the presence in the greeting banner of an initial challenge 246 enclosed in angle brackets ("<>"). Therefore, an APOP capability 247 would introduce two ways for a server to announce the same thing. 249 6.1. TOP capability 251 CAPA tag: 252 TOP 254 Arguments: 255 none 257 Added commands: 258 TOP 260 Standard commands affected: 261 none 263 Announced states / possible differences: 264 both / no 266 Commands valid in states: 267 TRANSACTION 269 Specification reference: 270 [POP3] 272 Discussion: 273 The TOP capability indicates the optional TOP command is 274 available. 276 6.2. USER capability 278 CAPA tag: 279 USER 281 Arguments: 282 none 284 Added commands: 285 USER PASS 287 Standard commands affected: 288 none 290 Announced states / possible differences: 291 both / no 293 Commands valid in states: 294 AUTHENTICATION 296 Specification reference: 297 [POP3] 299 Discussion: 301 The USER capability indicates that the USER and PASS commands 302 are supported, although they may not be available to all users. 304 6.3. SASL capability 306 CAPA tag: 307 SASL 309 Arguments: 310 Supported SASL mechanisms 312 Added commands: 313 AUTH 315 Standard commands affected: 316 none 318 Announced states / possible differences: 319 both / no 321 Commands valid in states: 322 AUTHENTICATION 324 Specification reference: 325 [POP-AUTH, SASL] 327 Discussion: 328 The POP3 AUTH command [POP-AUTH] permits the use of [SASL] 329 authentication mechanisms with POP3. The SASL capability 330 indicates that the AUTH command is available and that it 331 supports an optional base64 encoded second argument for an 332 initial client response as described in the SASL specification. 333 The argument to the SASL capability is a space separated list of 334 SASL mechanisms which are supported. 336 6.4. RESP-CODES capability 338 CAPA tag: 339 RESP-CODES 341 Arguments: 342 none 344 Added commands: 345 none 347 Standard commands affected: 348 none 350 Announced states / possible differences: 352 both / no 354 Commands valid in states: 355 n/a 357 Specification reference: 358 this document 360 Discussion: 361 The RESP-CODES capability indicates that any response text 362 issued by this server which begins with an open square bracket 363 ("[") is an extended response code (see section 8). 365 6.5. LOGIN-DELAY capability 367 CAPA tag: 368 LOGIN-DELAY 370 Arguments: 371 minimum seconds between logins; optionally followed by USER in 372 AUTHENTICATION state. 374 Added commands: 375 none 377 Standard commands affected: 378 USER PASS APOP AUTH 380 Announced states / possible differences: 381 both / yes 383 Commands valid in states: 384 n/a 386 Specification reference: 387 this document 389 Discussion: 390 POP3 clients often login frequently to check for new mail. 391 Unfortunately, the process of creating a connection, 392 authenticating the user, and opening the user's maildrop can be 393 very resource intensive on the server. A number of deployed 394 POP3 servers try to reduce server load by requiring a delay 395 between logins. The LOGIN-DELAY capability includes an integer 396 argument which indicates the number of seconds after an "+OK" 397 response to a PASS, APOP, or AUTH command before another 398 authentication will be accepted. Clients which permit the user 399 to configure a mail check interval SHOULD use this capability to 400 determine the minimum permissible interval. Servers which 401 advertise LOGIN-DELAY SHOULD enforce it. 403 If the minimum login delay period could differ per user (that 404 is, the LOGIN-DELAY argument might change after authentication), 405 the server MUST announce in AUTHENTICATION state the largest 406 value which could be set for any user. This might be the 407 largest value currently in use for any user (so only one value 408 per server), or even the largest value which the server permits 409 to be set for any user. The server SHOULD append the token 410 "USER" to the LOGIN-DELAY parameter in AUTHENTICATION state, to 411 inform the client that a more accurate value is available after 412 authentication. The server SHOULD announce the more accurate 413 value in TRANSACTION state. (The "USER" token allows the client 414 to decide if a second CAPA command is needed or not.) 416 Servers enforce LOGIN-DELAY by rejecting an authentication 417 command with or without the LOGIN-DELAY error response. See 418 section 8.1.1 for more information. 420 6.6. PIPELINING capability 422 CAPA tag: 423 PIPELINING 425 Arguments: 426 none 428 Added commands: 429 none 431 Standard commands affected: 432 all 434 Announced states / possible differences: 435 both / no 437 Commands valid in states: 438 n/a 440 Specification reference: 441 this document 443 Discussion: 444 The PIPELINING capability indicates the server is capable of 445 accepting multiple commands at a time; the client does not have 446 to wait for the response to a command before issuing a 447 subsequent command. If a server supports PIPELINING, it MUST 448 process each command in turn. If a client uses PIPELINING, it 449 MUST keep track of which commands it has outstanding, and match 450 server responses to commands in order. If either the client or 451 server uses blocking writes, it MUST not exceed the window size 452 of the underlying transport layer. 454 Some POP3 clients have an option to indicate the server supports 455 "Overlapped POP3 commands." This capability removes the need to 456 configure this at the client. 458 This is roughly synonymous with the ESMTP PIPELINING extension 459 [PIPELINING], however, since SMTP [SMTP] tends to have short 460 commands and responses, the benefit is in grouping multiple 461 commands and sending them as a unit. While there are cases of 462 this in POP (for example, USER and PASS could be batched, 463 multiple RETR and/or DELE commands could be sent as a group), 464 because POP has short commands and sometimes lengthy responses, 465 there is also an advantage is sending new commands while still 466 receiving the response to an earlier command (for example, 467 sending RETR and/or DELE commands while processing a UIDL 468 reply). 470 6.7. EXPIRE capability 472 CAPA tag: 473 EXPIRE 475 Arguments: 476 server-guaranteed minimum retention days, or NEVER; optionally 477 followed by USER in AUTHENTICATION state 479 Added commands: 480 none 482 Standard commands affected: 483 none 485 Announced states / possible differences: 486 both / yes 488 Commands valid in states: 489 n/a 491 Specification reference: 492 this document 494 Discussion: 495 While POP3 allows clients to leave messages on the server, RFC 496 1939 [POP3] warns about the problems that may arise from this, 497 and allows servers to delete messages based on site policy. 499 The EXPIRE capability avoids the problems mentioned in RFC 1939, 500 by allowing the server to inform the client as to the policy in 501 effect. The argument to the EXPIRE capability indicates the 502 minimum server retention period, in days, for messages on the 503 server. 505 EXPIRE 0 indicates the client is not permitted to leave mail on 506 the server; when the session enters the UPDATE state the server 507 MAY assume an implicit DELE for each message which was 508 downloaded with RETR. 510 EXPIRE NEVER asserts that the server does not delete messages. 512 The concept of a "retention period" is intentionally vague. 513 Servers may start counting days to expiration when a message is 514 added to a maildrop, when a client becomes aware of the 515 existence of a message through the LIST or UIDL commands, when a 516 message has been acted upon in some way (for example, TOP or 517 RETR), or at some other event. The EXPIRE capability cannot 518 provide a precise indication as to exactly when any specific 519 message will expire. The capability is intended to make it 520 easier for clients to behave in ways which conform to site 521 policy and user wishes. For example, a client might display a 522 warning for attempts to configure a "leave mail on server" 523 period which is greater than or equal to some percentage of the 524 value announced by the server. 526 If a site uses any automatic deletion policy, it SHOULD use the 527 EXPIRE capability to announce this. 529 The EXPIRE capability, with a parameter other than 0 or NEVER, 530 is intended to let the client know that the server does permit 531 mail to be left on the server, and to present a value which is 532 the smallest which might be in force. 534 Sites which permit users to retain messages indefinitely SHOULD 535 announce this with the EXPIRE NEVER response. 537 If the expiration policy differs per user (that is, the EXPIRE 538 argument might change after authentication), the server MUST 539 announce in AUTHENTICATION state the smallest value which could 540 be set for any user. This might be the smallest value currently 541 in use for any user (so only one value per server), or even the 542 smallest value which the server permits to be set for any user. 543 The server SHOULD append the token "USER" to the EXPIRE 544 parameter in AUTHENTICATION state, to inform the client that a 545 more accurate value is available after authentication. The 546 server SHOULD announce the more accurate value in TRANSACTION 547 state. (The "USER" token allows the client to decide if a second 548 CAPA command is needed or not.) 550 A site may have a message expiration policy which treats 551 messages differently depending on which user actions have been 552 performed, or based on other factors. For example, a site might 553 delete unseen messages after 60 days, and completely- or 554 partially-seen messages after 15 days. 556 The announced EXPIRE value is the smallest retention period 557 which is or might be used by any category or condition of the 558 current site policy, for any user (in AUTHENTICATION state) or 559 the specific user (in TRANSACTION state). That is, EXPIRE 560 informs the client of the minimum number of days messages may 561 remain on the server under any circumstances. 563 Examples: 564 EXPIRE 5 USER 565 EXPIRE 30 566 EXPIRE NEVER 567 EXPIRE 0 569 The first example indicates the server might delete messages 570 after five days, but the period differs per user, and so a more 571 accurate value can be obtained by issuing a second CAPA command 572 in TRANSACTION state. The second example indicates the server 573 could delete messages after 30 days. In the third example, the 574 server announces it does not delete messages. The fourth 575 example specifies that the site does not permit messages to be 576 left on the server. 578 6.8. UIDL capability 580 CAPA tag: 581 UIDL 583 Arguments: 584 none 586 Added commands: 587 UIDL 589 Standard commands affected: 590 none 592 Announced states / possible differences: 593 both / no 595 Commands valid in states: 596 TRANSACTION 598 Specification reference: 599 [POP3] 601 Discussion: 602 The UIDL capability indicates that the optional UIDL command is 603 supported. 605 6.9. IMPLEMENTATION capability 606 CAPA tag: 607 IMPLEMENTATION 609 Arguments: 610 string giving server implementation information 612 Added commands: 613 none 615 Standard commands affected: 616 none 618 Announced states / possible differences: 619 both (optionally TRANSACTION only) / no 621 Commands valid in states: 622 n/a 624 Specification reference: 625 this document 627 Discussion: 628 It is often useful to identify an implementation of a particular 629 server (for example, when logging). This is commonly done in 630 the welcome banner, but one must guess if a string is an 631 implementation ID or not. 633 The argument to the IMPLEMENTATION capability consists of one or 634 more tokens which identify the server. (Note that since CAPA 635 response tag arguments are space-separated, it may be convenient 636 for the IMPLEMENTATION capability argument to not contain 637 spaces, so that it is a single token.) 639 Normally, servers announce IMPLEMENTATION in both states. 640 However, a server MAY chose to do so only in TRANSACTION state. 642 A server MAY include the implementation identification both in 643 the welcome banner and in the IMPLEMENTATION capability. 645 Clients MUST NOT modify their behavior based on the server 646 implementation. Instead the server and client should agree on a 647 private extension. 649 7. Future Extensions to POP3 651 Future extensions to POP3 are in general discouraged, as POP3's 652 usefulness lies in its simplicity. POP3 is intended as a 653 download-and-delete protocol; mail access capabilities are available 654 in IMAP [IMAP4]. Extensions which provide support for additional 655 mailboxes, allow uploading of messages to the server, or which 656 deviate from POP's download-and-delete model are strongly 657 discouraged and unlikely to be permitted on the IETF standards 658 track. 660 Clients MUST NOT require the presence of any extension for basic 661 functionality, with the exception of the authentication commands 662 (APOP, AUTH [section 6.3] and USER/PASS). 664 Section 9 specifies how additional capabilities are defined. 666 8. Extended POP3 Response Codes 668 Unextended POP3 is only capable of indicating success or failure to 669 most commands. Unfortunately, clients often need to know more 670 information about the cause of a failure in order to gracefully 671 recover. This is especially important in response to a failed login 672 (there are widely-deployed clients which attempt to decode the error 673 text of a PASS command result, to try and distinguish between 674 "unable to get maildrop lock" and "bad login"). 676 This specification amends the POP3 standard to permit an optional 677 response code, enclosed in square brackets, at the beginning of the 678 human readable text portion of an "+OK" or "-ERR" response. Clients 679 supporting this extension MAY remove any information enclosed in 680 square brackets prior to displaying human readable text to the user. 681 Immediately following the open square bracket "[" character is a 682 response code which is interpreted in a case-insensitive fashion by 683 the client. 685 The response code is hierarchical, with a "/" separating levels of 686 detail about the error. Clients MUST ignore unknown hierarchical 687 detail about the response code. This is important, as it could be 688 necessary to provide further detail for response codes in the 689 future. 691 Section 3 describes response codes using [ABNF]. 693 If a server supports extended response codes, it indicates this by 694 including the RESP-CODES capability in the CAPA response. 696 Examples: 697 C: APOP mrose c4c9334bac560ecc979e58001b3e22fb 698 S: -ERR [IN-USE] Do you have another POP session running? 700 8.1. Initial POP3 response codes 702 This specification defines two POP3 response codes which can be used 703 to determine the reason for a failed login. Section 9 specifies how 704 additional response codes are defined. 706 8.1.1. The LOGIN-DELAY response code 707 This occurs on an -ERR response to an AUTH, USER (see note), PASS or 708 APOP command and indicates that the user has logged in recently and 709 will not be allowed to login again until the login delay period has 710 expired. 712 NOTE: Returning the LOGIN-DELAY response code to the USER command 713 avoids the work of authenticating the user but reveals to the client 714 that the specified user exists. Unless the server is operating in 715 an environment where user names are not secret (for example, many 716 popular email clients advertise the POP server and user name in an 717 outgoing mail header), or where server access is restricted, or the 718 server can verify that the connection is to the same user, it is 719 strongly recommended that the server not issue this response code to 720 the USER command. The server still saves the cost of opening the 721 maildrop, which in some environments is the most expensive step. 723 8.1.2. The IN-USE response code 725 This occurs on an -ERR response to an AUTH, APOP, or PASS command. 726 It indicates the authentication was successful, but the user's 727 maildrop is currently in use (probably by another POP3 client). 729 9. IANA Considerations 731 This document requests that IANA maintain two new registries: POP3 732 capabilities and POP3 response codes. 734 New POP3 capabilities MUST be defined in a standards track or IESG 735 approved experimental RFC, and MUST NOT begin with the letter "X". 737 New POP3 capabilities MUST include the following information: 738 CAPA tag 739 Arguments 740 Added commands 741 Standard commands affected 742 Announced states / possible differences 743 Commands valid in states 744 Specification reference 745 Discussion 747 In addition, new limits for POP3 command and response lengths may 748 need to be included. 750 New POP3 response codes MUST be defined in an RFC or other permanent 751 and readily available reference, in sufficient detail so that 752 interoperability between independent implementations is possible. 753 (This is the "Specification Required" policy described in [IANA]). 755 New POP3 response code specifications MUST include the following 756 information: the complete response code, for which responses (+OK or 757 -ERR) and commands it is valid, and a definition of its meaning and 758 expected client behavior. 760 10. Security Considerations 762 A capability list can reveal information about the server's 763 authentication mechanisms which can be used to determine if certain 764 attacks will be successful. However, allowing clients to 765 automatically detect availability of stronger mechanisms and alter 766 their configurations to use them can improve overall security at a 767 site. 769 Section 8.1 discusses the security issues related to use of the 770 LOGIN-DELAY response code with the USER command. 772 11. Acknowledgments 774 This document has been revised in part based on comments and 775 discussions which took place on and off the IETF POP3 Extensions 776 mailing list. The help of those who took the time to review the 777 draft and make suggestions is appreciated, especially that of Alexey 778 Melnikov, Harald Alvestrand, and Mike Gahrns. 780 12. References 782 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 783 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., 784 November 1997. 786 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA 787 Considerations Section in RFCs", work in progress. 789 [IMAP4] Crispin, "Internet Message Access Protocol -- Version 790 4rev1", RFC 2060, University of Washington, December 1996. 791 793 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 794 Requirement Levels", RFC 2119, Harvard University, March 1997. 795 797 [PIPELINING] Freed, "SMTP Service Extension for Command Pipelining", 798 RFC 2197, Innosoft, September 1997. 799 801 [POP3] Myers, Rose, "Post Office Protocol -- Version 3", RFC 1939, 802 Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 803 805 [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie 806 Mellon, December 1994. 808 [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC 809 2222, Netscape Communications, October 1997. 810 812 [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, STD 10, 813 Information Sciences Institute, August 1982. 814 816 13. Full Copyright Statement 818 Copyright (C) The Internet Society 1998. All Rights Reserved. 820 This document and translations of it may be copied and furnished to 821 others, and derivative works that comment on or otherwise explain it 822 or assist in its implementation may be prepared, copied, published 823 and distributed, in whole or in part, without restriction of any 824 kind, provided that the above copyright notice and this paragraph 825 are included on all such copies and derivative works. However, this 826 document itself may not be modified in any way, such as by removing 827 the copyright notice or references to the Internet Society or other 828 Internet organizations, except as needed for the purpose of 829 developing Internet standards in which case the procedures for 830 copyrights defined in the Internet Standards process must be 831 followed, or as required to translate it into languages other than 832 English. 834 The limited permissions granted above are perpetual and will not be 835 revoked by the Internet Society or its successors or assigns. 837 This document and the information contained herein is provided on an 838 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 839 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 840 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 841 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 842 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 844 14. Authors' Addresses 846 Randall Gellens +1 619 651 5115 847 QUALCOMM Incorporated +1 619 845 7268 (fax) 848 6455 Lusk Blvd. randy@qualcomm.com 849 San Diego, CA 92121-2779 850 USA 852 Chris Newman chris.newman@innosoft.com 853 Innosoft International, Inc. 854 1050 Lakes Drive 855 West Covina, CA 91790 856 USA 858 Laurence Lundblade +1 619 658 3584 859 QUALCOMM Incorporated +1 619 845 7268 (fax) 860 6455 Lusk Blvd. lgl@qualcomm.com 861 San Diego, Ca, 92121-2779 862 USA 864 Gellens, Newman, Lundblade [Page 18] Expires March 1999