idnits 2.17.1 draft-myers-pop-pop3-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 102: '...) and negative ("-ERR"). Servers MUST...' RFC 2119 keyword, line 138: '... A server MUST respond to an unrecog...' RFC 2119 keyword, line 140: '...cator. A server MUST respond to a com...' RFC 2119 keyword, line 146: '... A POP3 server MAY have an inactivit...' RFC 2119 keyword, line 147: '... MUST be of at least 10 minutes' dur...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 752 has weird spacing: '... shared secre...' == 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: If a session terminates for some reason other than a client-issued QUIT command, the POP3 session does NOT enter the UPDATE state and MUST not remove any messages from the maildrop. -- 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 (August 1995) is 10482 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) ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1730 (Obsoleted by RFC 2060, RFC 2061) ** Obsolete normative reference: RFC 1734 (Obsoleted by RFC 5034) Summary: 17 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Myers 2 Internet Draft: POP3 Carnegie Mellon 3 Document: draft-myers-pop-pop3-06.txt M. Rose 4 Dover Beach Consulting, Inc. 5 August 1995 7 Post Office Protocol - Version 3 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress``. 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 25 munnari.oz.au. 27 A revised version of this draft document will be submitted to the RFC 28 editor as an Internet Standard for the Internet Community. 29 Discussion and suggestions for improvement are requested. This 30 document will expire before 15 Nov 1995. Distribution of this draft 31 is unlimited. 33 Internet DRAFT POP3 October 4, 1995 35 1. Introduction 37 On certain types of smaller nodes in the Internet it is often 38 impractical to maintain a message transport system (MTS). For 39 example, a workstation may not have sufficient resources (cycles, 40 disk space) in order to permit a SMTP server [RFC821] and associated 41 local mail delivery system to be kept resident and continuously 42 running. Similarly, it may be expensive (or impossible) to keep a 43 personal computer interconnected to an IP-style network for long 44 amounts of time (the node is lacking the resource known as 45 "connectivity"). 47 Despite this, it is often very useful to be able to manage mail on 48 these smaller nodes, and they often support a user agent (UA) to aid 49 the tasks of mail handling. To solve this problem, a node which can 50 support an MTS entity offers a maildrop service to these less endowed 51 nodes. The Post Office Protocol - Version 3 (POP3) is intended to 52 permit a workstation to dynamically access a maildrop on a server 53 host in a useful fashion. Usually, this means that the POP3 protocol 54 is used to allow a workstation to retrieve mail that the server is 55 holding for it. 57 POP3 is not intended to provide extensive manipulation operations of 58 mail on the server; normally, mail is downloaded and then deleted. A 59 more advanced (and complex) protocol, IMAP4, is discussed in 60 [RFC1730]. 62 For the remainder of this memo, the term "client host" refers to a 63 host making use of the POP3 service, while the term "server host" 64 refers to a host which offers the POP3 service. 66 2. A Short Digression 68 This memo does not specify how a client host enters mail into the 69 transport system, although a method consistent with the philosophy of 70 this memo is presented here: 72 When the user agent on a client host wishes to enter a message 73 into the transport system, it establishes an SMTP connection to 74 its relay host and sends all mail to it. This relay host could 75 be, but need not be, the POP3 server host for the client host. Of 76 course, the relay host must accept mail for delivery to arbitrary 77 recipient addresses, that functionality is not required of all 78 SMTP servers. 80 Internet DRAFT POP3 October 4, 1995 82 3. Basic Operation 84 Initially, the server host starts the POP3 service by listening on 85 TCP port 110. When a client host wishes to make use of the service, 86 it establishes a TCP connection with the server host. When the 87 connection is established, the POP3 server sends a greeting. The 88 client and POP3 server then exchange commands and responses 89 (respectively) until the connection is closed or aborted. 91 Commands in the POP3 consist of a case-insensitive keyword, possibly 92 followed by one or more arguments. All commands are terminated by a 93 CRLF pair. Keywords and arguments consist of printable ASCII 94 characters. Keywords and arguments are each separated by a single 95 SPACE character. Keywords are three or four characters long. Each 96 argument may be up to 40 characters long. 98 Responses in the POP3 consist of a status indicator and a keyword 99 possibly followed by additional information. All responses are 100 terminated by a CRLF pair. Responses may be up to 512 characters 101 long, including the terminating CRLF. There are currently two status 102 indicators: positive ("+OK") and negative ("-ERR"). Servers MUST 103 send the "+OK" and "-ERR" in upper case. 105 Responses to certain commands are multi-line. In these cases, which 106 are clearly indicated below, after sending the first line of the 107 response and a CRLF, any additional lines are sent, each terminated 108 by a CRLF pair. When all lines of the response have been sent, a 109 final line is sent, consisting of a termination octet (decimal code 110 046, ".") and a CRLF pair. If any line of the multi-line response 111 begins with the termination octet, the line is "byte-stuffed" by 112 pre-pending the termination octet to that line of the response. 113 Hence a multi-line response is terminated with the five octets 114 "CRLF.CRLF". When examining a multi-line response, the client checks 115 to see if the line begins with the termination octet. If so and if 116 octets other than CRLF follow, the the first octet of the line (the 117 termination octet) is stripped away. If so and if CRLF immediately 118 follows the termination character, then the response from the POP 119 server is ended and the line containing ".CRLF" is not considered 120 part of the multi-line response. 122 A POP3 session progresses through a number of states during its 123 lifetime. Once the TCP connection has been opened and the POP3 124 server has sent the greeting, the session enters the AUTHORIZATION 125 state. In this state, the client must identify itself to the POP3 126 server. Once the client has successfully done this, the server 127 acquires resources associated with the client's maildrop, and the 128 session enters the TRANSACTION state. In this state, the client 129 requests actions on the part of the POP3 server. When the client has 131 Internet DRAFT POP3 October 4, 1995 133 issued the QUIT command, the session enters the UPDATE state. In 134 this state, the POP3 server releases any resources acquired during 135 the TRANSACTION state and says goodbye. The TCP connection is then 136 closed. 138 A server MUST respond to an unrecognized, unimplemented, or 139 syntactically invalid command by responding with a negative status 140 indicator. A server MUST respond to a command issued when the 141 session is in an incorrect state by responding with a negative status 142 indicator. There is no general method for a client to distinguish 143 between a server which does not implement an optional command and a 144 server which is unwilling or unable to process the command. 146 A POP3 server MAY have an inactivity autologout timer. Such a timer 147 MUST be of at least 10 minutes' duration. The receipt of any command 148 from the client during that interval should suffice to reset the 149 autologout timer. When the timer expires, the session does NOT enter 150 the UPDATE state--the server should close the TCP connection without 151 removing any messages or sending any response to the client. 153 4. The AUTHORIZATION State 155 Once the TCP connection has been opened by a POP3 client, the POP3 156 server issues a one line greeting. This can be any positive 157 response. An example might be: 159 S: +OK POP3 server ready 161 The POP3 session is now in the AUTHORIZATION state. The client must 162 now identify and authenticate itself to the POP3 server. Two 163 possible mechanisms for doing this are described in this document, 164 the USER and PASS command combination and the APOP command. Both 165 mechanisms are described later in this document. Additional 166 authentication mechanisms are described in [RFC1734]. While there is 167 no single authentication mechanism that is required of all POP3 168 servers, a POP3 server must of course support at least one 169 authentication mechanism. 171 Once the POP3 server has determined through the use of any 172 authentication command that the client should be given access to the 173 appropriate maildrop, the POP3 server then acquires an exclusive- 174 access lock on the maildrop, as necessary to prevent messages from 175 being modified or removed before the session enters the UPDATE state. 176 If the lock is successfully acquired, the POP3 server responds with a 177 positive status indicator. The POP3 session now enters the 178 TRANSACTION state, with no messages marked as deleted. If the the 179 maildrop cannot be opened for some reason (for example, a lock can 180 not be acquired, the client is denied access to the appropriate 182 Internet DRAFT POP3 October 4, 1995 184 maildrop, or the maildrop cannot be parsed), the POP3 server responds 185 with a negative status indicator. (If a lock was acquired but the 186 POP3 server intends to respond with a negative status indicator, the 187 POP3 server must release the lock prior to rejecting the command.) 188 After returning a negative status indicator, the server may close the 189 connection. If the server does not close the connection, the client 190 may either issue a new authentication command and start again, or the 191 client may issue the QUIT command. 193 After the POP3 server has opened the maildrop, it assigns a message- 194 number to each message, and notes the size of each message in octets. 195 The first message in the maildrop is assigned a message-number of 196 "1", the second is assigned "2", and so on, so that the nth message 197 in a maildrop is assigned a message-number of "n". In POP3 commands 198 and responses, all message-numbers and message sizes are expressed in 199 base-10 (i.e., decimal). 201 Here is the summary for the QUIT command when used in the 202 AUTHORIZATION state: 204 QUIT 206 Arguments: none 208 Restrictions: none 210 Possible Responses: 211 +OK 213 Examples: 214 C: QUIT 215 S: +OK dewey POP3 server signing off 217 5. The TRANSACTION State 219 Once the client has successfully identified itself to the POP3 server 220 and the POP3 server has locked and opened the appropriate maildrop, 221 the POP3 session is now in the TRANSACTION state. The client may now 222 issue any of the following POP3 commands repeatedly. After each 223 command, the POP3 server issues a response. Eventually, the client 224 issues the QUIT command and the POP3 session enters the UPDATE state. 226 Here are the POP3 commands valid in the TRANSACTION state: 228 Internet DRAFT POP3 October 4, 1995 230 STAT 232 Arguments: none 234 Restrictions: 235 may only be given in the TRANSACTION state 237 Discussion: 238 The POP3 server issues a positive response with a line 239 containing information for the maildrop. This line is 240 called a "drop listing" for that maildrop. 242 In order to simplify parsing, all POP3 servers required to 243 use a certain format for drop listings. The positive 244 response consists of "+OK" followed by a single space, the 245 number of messages in the maildrop, a single space, and the 246 size of the maildrop in octets. This memo makes no 247 requirement on what follows the maildrop size. Minimal 248 implementations should just end that line of the response 249 with a CRLF pair. More advanced implementations may 250 include other information. 252 NOTE: This memo STRONGLY discourages implementations 253 from supplying additional information in the drop 254 listing. Other, optional, facilities are discussed 255 later on which permit the client to parse the messages 256 in the maildrop. 258 Note that messages marked as deleted are not counted in 259 either total. 261 Possible Responses: 262 +OK nn mm 264 Examples: 265 C: STAT 266 S: +OK 2 320 268 LIST [msg] 270 Arguments: 271 a message-number (optional), which, if present, may NOT 272 refer to a message marked as deleted 274 Restrictions: 275 may only be given in the TRANSACTION state 277 Internet DRAFT POP3 October 4, 1995 279 Discussion: 280 If an argument was given and the POP3 server issues a 281 positive response with a line containing information for 282 that message. This line is called a "scan listing" for 283 that message. 285 If no argument was given and the POP3 server issues a 286 positive response, then the response given is multi-line. 287 After the initial +OK, for each message in the maildrop, 288 the POP3 server responds with a line containing 289 information for that message. This line is also called a 290 "scan listing" for that message. If there are no 291 messages in the maildrop, then the POP3 server responds 292 with no scan listings--it issues a positive response 293 followed by a line containing a termination octet and a 294 CRLF pair. 296 In order to simplify parsing, all POP3 servers are 297 required to use a certain format for scan listings. A 298 scan listing consists of the message-number of the 299 message, followed by a single space and the exact size of 300 the message in octets. Methods for calculating the exact 301 size of the message are described in the "Message Format" 302 section below. This memo makes no requirement on what 303 follows the message size in the scan listing. Minimal 304 implementations should just end that line of the response 305 with a CRLF pair. More advanced implementations may 306 include other information, as parsed from the message. 308 NOTE: This memo STRONGLY discourages implementations 309 from supplying additional information in the scan 310 listing. Other, optional, facilities are discussed 311 later on which permit the client to parse the messages 312 in the maildrop. 314 Note that messages marked as deleted are not listed. 316 Possible Responses: 317 +OK scan listing follows 318 -ERR no such message 320 Examples: 321 C: LIST 322 S: +OK 2 messages (320 octets) 323 S: 1 120 324 S: 2 200 325 S: . 326 ... 328 Internet DRAFT POP3 October 4, 1995 330 C: LIST 2 331 S: +OK 2 200 332 ... 333 C: LIST 3 334 S: -ERR no such message, only 2 messages in maildrop 336 RETR msg 338 Arguments: 339 a message-number (required) which may not refer to a 340 message marked as deleted 342 Restrictions: 343 may only be given in the TRANSACTION state 345 Discussion: 346 If the POP3 server issues a positive response, then the 347 response given is multi-line. After the initial +OK, the 348 POP3 server sends the message corresponding to the given 349 message-number, being careful to byte-stuff the termination 350 character (as with all multi-line responses). 352 Possible Responses: 353 +OK message follows 354 -ERR no such message 356 Examples: 357 C: RETR 1 358 S: +OK 120 octets 359 S: 360 S: . 362 DELE msg 364 Arguments: 365 a message-number (required) which may not refer to a 366 message marked as deleted 368 Restrictions: 369 may only be given in the TRANSACTION state 371 Discussion: 372 The POP3 server marks the message as deleted. Any future 373 reference to the message-number associated with the message 374 in a POP3 command generates an error. The POP3 server does 375 not actually delete the message until the POP3 session 377 Internet DRAFT POP3 October 4, 1995 379 enters the UPDATE state. 381 Possible Responses: 382 +OK message deleted 383 -ERR no such message 385 Examples: 386 C: DELE 1 387 S: +OK message 1 deleted 388 ... 389 C: DELE 2 390 S: -ERR message 2 already deleted 392 NOOP 394 Arguments: none 396 Restrictions: 397 may only be given in the TRANSACTION state 399 Discussion: 400 The POP3 server does nothing, it merely replies with a 401 positive response. 403 Possible Responses: 404 +OK 406 Examples: 407 C: NOOP 408 S: +OK 410 RSET 412 Arguments: none 414 Restrictions: 415 may only be given in the TRANSACTION state 417 Discussion: 418 If any messages have been marked as deleted by the POP3 419 server, they are unmarked. The POP3 server then replies 420 with a positive response. 422 Possible Responses: 423 +OK 425 Internet DRAFT POP3 October 4, 1995 427 Examples: 428 C: RSET 429 S: +OK maildrop has 2 messages (320 octets) 431 6. The UPDATE State 433 When the client issues the QUIT command from the TRANSACTION state, 434 the POP3 session enters the UPDATE state. (Note that if the client 435 issues the QUIT command from the AUTHORIZATION state, the POP3 436 session terminates but does NOT enter the UPDATE state.) 438 If a session terminates for some reason other than a client-issued 439 QUIT command, the POP3 session does NOT enter the UPDATE state and 440 MUST not remove any messages from the maildrop. 442 QUIT 444 Arguments: none 446 Restrictions: none 448 Discussion: 449 The POP3 server removes all messages marked as deleted 450 from the maildrop and replies as to the status of this 451 operation. If there is an error, such as a resource 452 shortage, encountered while removing messages, the 453 maildrop may result in having some or none of the messages 454 marked as deleted be removed. In no case may the server 455 remove any messages not marked as deleted. 457 Whether the removal was successful or not, the server 458 then releases any exclusive-access lock on the maildrop 459 and closes the TCP connection. 461 Possible Responses: 462 +OK 463 -ERR some deleted messages not removed 465 Examples: 466 C: QUIT 467 S: +OK dewey POP3 server signing off (maildrop empty) 468 ... 469 C: QUIT 470 S: +OK dewey POP3 server signing off (2 messages left) 471 ... 473 Internet DRAFT POP3 October 4, 1995 475 7. Optional POP3 Commands 477 The POP3 commands discussed above must be supported by all minimal 478 implementations of POP3 servers. 480 The optional POP3 commands described below permit a POP3 client 481 greater freedom in message handling, while preserving a simple POP3 482 server implementation. 484 NOTE: This memo STRONGLY encourages implementations to support 485 these commands in lieu of developing augmented drop and scan 486 listings. In short, the philosophy of this memo is to put 487 intelligence in the part of the POP3 client and not the POP3 488 server. 490 TOP msg n 492 Arguments: 493 a message-number (required) which may NOT refer to to a 494 message marked as deleted, and a non-negative number 495 of lines (required) 497 Restrictions: 498 may only be given in the TRANSACTION state 500 Discussion: 501 If the POP3 server issues a positive response, then the 502 response given is multi-line. After the initial +OK, the 503 POP3 server sends the headers of the message, the blank 504 line separating the headers from the body, and then the 505 number of lines of the indicated message's body, being 506 careful to byte-stuff the termination character (as with 507 all multi-line responses). 509 Note that if the number of lines requested by the POP3 510 client is greater than than the number of lines in the 511 body, then the POP3 server sends the entire message. 513 Possible Responses: 514 +OK top of message follows 515 -ERR no such message 517 Examples: 518 C: TOP 1 10 519 S: +OK 520 S: 526 S: . 527 ... 528 C: TOP 100 3 529 S: -ERR no such message 531 UIDL [msg] 533 Arguments: 534 a message-number (optionally) If a message-number is given, 535 it may NOT refer to a message marked as deleted. 537 Restrictions: 538 may only be given in the TRANSACTION state. 540 Discussion: 541 If an argument was given and the POP3 server issues a positive 542 response with a line containing information for that message. 543 This line is called a "unique-id listing" for that message. 545 If no argument was given and the POP3 server issues a positive 546 response, then the response given is multi-line. After the 547 initial +OK, for each message in the maildrop, the POP3 server 548 responds with a line containing information for that message. 549 This line is called a "unique-id listing" for that message. 551 In order to simplify parsing, all POP3 servers are required to 552 use a certain format for unique-id listings. A unique-id 553 listing consists of the message-number of the message, 554 followed by a single space and the unique-id of the message. 555 No information follows the unique-id in the unique-id listing. 557 The unique-id of a message is an arbitrary server-determined 558 string, consisting of one to 70 characters in the range 0x21 559 to 0x7E, which uniquely identifies a message within a 560 maildrop and which persists across sessions. This 561 persistence is required even if a session ends without 562 entering the UPDATE state. The server should never reuse an 563 unique-id in a given maildrop, for as long as the entity 564 using the unique-id exists. 566 Note that messages marked as deleted are not listed. 568 While it is generally preferable for server implementations 569 to store arbitrarily assigned unique-ids in the maildrop, 570 this specification is intended to permit unique-ids to be 571 calculated as a hash of the message. Clients should be able 573 Internet DRAFT POP3 October 4, 1995 575 to handle a situation where two identical copies of a 576 message in a maildrop have the same unique-id. 578 Possible Responses: 579 +OK unique-id listing follows 580 -ERR no such message 582 Examples: 583 C: UIDL 584 S: +OK 585 S: 1 whqtswO00WBw418f9t5JxYwZ 586 S: 2 QhdPYR:00WBw1Ph7x7 587 S: . 588 ... 589 C: UIDL 2 590 S: +OK 2 QhdPYR:00WBw1Ph7x7 591 ... 592 C: UIDL 3 593 S: -ERR no such message, only 2 messages in maildrop 595 USER name 597 Arguments: 598 a string identifying a mailbox (required), which is of 599 significance ONLY to the server 601 Restrictions: 602 may only be given in the AUTHORIZATION state after the POP3 603 greeting or after an unsuccessful USER or PASS command 605 Discussion: 606 To authenticate using the USER and PASS command 607 combination, the client must first issue the USER 608 command. If the POP3 server responds with a positive 609 status indicator ("+OK"), then the client may issue 610 either the PASS command to complete the authentication, 611 or the QUIT command to terminate the POP3 session. If 612 the POP3 server responds with a negative status indicator 613 ("-ERR") to the USER command, then the client may either 614 issue a new authentication command or may issue the QUIT 615 command. 617 The server may return a positive response even though no 618 such mailbox exists. The server may return a negative 619 response if mailbox exists, but does not permit plaintext 620 password authentication. 622 Internet DRAFT POP3 October 4, 1995 624 Possible Responses: 625 +OK name is a valid mailbox 626 -ERR never heard of mailbox name 628 Examples: 629 C: USER frated 630 S: -ERR sorry, no mailbox for frated here 631 ... 632 C: USER mrose 633 S: +OK mrose is a real hoopy frood 635 PASS string 637 Arguments: 638 a server/mailbox-specific password (required) 640 Restrictions: 641 may only be given in the AUTHORIZATION state immediately 642 after a successful USER command 644 Discussion: 645 When the client issues the PASS command, the POP3 server 646 uses the argument pair from the USER and PASS commands to 647 determine if the client should be given access to the 648 appropriate maildrop. 650 Since the PASS command has exactly one argument, a POP3 651 server may treat spaces in the argument as part of the 652 password, instead of as argument separators. 654 Possible Responses: 655 +OK maildrop locked and ready 656 -ERR invalid password 657 -ERR unable to lock maildrop 659 Examples: 660 C: USER mrose 661 S: +OK mrose is a real hoopy frood 662 C: PASS secret 663 S: -ERR maildrop already locked 664 ... 665 C: USER mrose 666 S: +OK mrose is a real hoopy frood 667 C: PASS secret 668 S: +OK mrose's maildrop has 2 messages (320 octets) 670 Internet DRAFT POP3 October 4, 1995 672 APOP name digest 674 Arguments: 675 a string identifying a mailbox and a MD5 digest string 676 (both required) 678 Restrictions: 679 may only be given in the AUTHORIZATION state after the POP3 680 greeting or after an unsuccessful USER or PASS command 682 Discussion: 683 Normally, each POP3 session starts with a USER/PASS 684 exchange. This results in a server/user-id specific 685 password being sent in the clear on the network. For 686 intermittent use of POP3, this may not introduce a sizable 687 risk. However, many POP3 client implementations connect to 688 the POP3 server on a regular basis -- to check for new 689 mail. Further the interval of session initiation may be on 690 the order of five minutes. Hence, the risk of password 691 capture is greatly enhanced. 693 An alternate method of authentication is required which 694 provides for both origin authentication and replay 695 protection, but which does not involve sending a password 696 in the clear over the network. The APOP command provides 697 this functionality. 699 A POP3 server which implements the APOP command will 700 include a timestamp in its banner greeting. The syntax of 701 the timestamp corresponds to the `msg-id' in [RFC822], and 702 MUST be different each time the POP3 server issues a banner 703 greeting. For example, on a UNIX implementation in which a 704 separate UNIX process is used for each instance of a POP3 705 server, the syntax of the timestamp might be: 707 709 where `process-ID' is the decimal value of the process's 710 PID, clock is the decimal value of the system clock, and 711 hostname is the fully-qualified domain-name corresponding 712 to the host where the POP3 server is running. 714 The POP3 client makes note of this timestamp, and then 715 issues the APOP command. The `name' parameter has 716 identical semantics to the `name' parameter of the USER 717 command. The `digest' parameter is calculated by applying 718 the MD5 algorithm [RFC1321] to a string consisting of the 719 timestamp (including angle-brackets) followed by a shared 721 Internet DRAFT POP3 October 4, 1995 723 secret. This shared secret is a string known only to the 724 POP3 client and server. Great care should be taken to 725 prevent unauthorized disclosure of the secret, as knowledge 726 of the secret will allow any entity to successfully 727 masquerade as the named user. The `digest' parameter 728 itself is a 16-octet value which is sent in hexadecimal 729 format, using lower-case ASCII characters. 731 When the POP3 server receives the APOP command, it verifies 732 the digest provided. If the digest is correct, the POP3 733 server issues a positive response, and the POP3 session 734 enters the TRANSACTION state. Otherwise, a negative 735 response is issued and the POP3 session remains in the 736 AUTHORIZATION state. 738 Note that as the length of the shared secret increases, so 739 does the difficulty of deriving it. As such, shared 740 secrets should be long strings (considerably longer than 741 the 8-character example shown below). 743 Possible Responses: 744 +OK maildrop locked and ready 745 -ERR permission denied 747 Examples: 748 S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> 749 C: APOP mrose c4c9334bac560ecc979e58001b3e22fb 750 S: +OK maildrop has 1 message (369 octets) 752 In this example, the shared secret is the string `tan- 753 staaf'. Hence, the MD5 algorithm is applied to the string 755 <1896.697170952@dbc.mtview.ca.us>tanstaaf 757 which produces a digest value of 759 c4c9334bac560ecc979e58001b3e22fb 761 8. POP3 Command Summary 763 Minimal POP3 Commands: 765 USER name valid in the AUTHORIZATION state 766 PASS string 767 QUIT 769 STAT valid in the TRANSACTION state 770 LIST [msg] 772 Internet DRAFT POP3 October 4, 1995 774 RETR msg 775 DELE msg 776 NOOP 777 RSET 779 QUIT valid in the UPDATE state 781 Optional POP3 Commands: 783 APOP name digest valid in the AUTHORIZATION state 785 TOP msg n valid in the TRANSACTION state 786 UIDL [msg] 788 POP3 Replies: 790 +OK 791 -ERR 793 Note that with the exception of the STAT, LIST, and UIDL commands, 794 the reply given by the POP3 server to any command is significant only 795 to "+OK" and "-ERR". Any text occurring after this reply may be 796 ignored by the client. 798 9. Example POP3 Session 800 S: 801 C: 802 S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> 803 C: APOP mrose c4c9334bac560ecc979e58001b3e22fb 804 S: +OK mrose's maildrop has 2 messages (320 octets) 805 C: STAT 806 S: +OK 2 320 807 C: LIST 808 S: +OK 2 messages (320 octets) 809 S: 1 120 810 S: 2 200 811 S: . 812 C: RETR 1 813 S: +OK 120 octets 814 S: 815 S: . 816 C: DELE 1 817 S: +OK message 1 deleted 818 C: RETR 2 819 S: +OK 200 octets 820 S: 821 S: . 823 Internet DRAFT POP3 October 4, 1995 825 C: DELE 2 826 S: +OK message 2 deleted 827 C: QUIT 828 S: +OK dewey POP3 server signing off (maildrop empty) 829 C: 830 S: 832 10. Message Format 834 All messages transmitted during a POP3 session are assumed to conform 835 to the standard for the format of Internet text messages [RFC822]. 837 It is important to note that the octet count for a message on the 838 server host may differ from the octet count assigned to that message 839 due to local conventions for designating end-of-line. Usually, 840 during the AUTHORIZATION state of the POP3 session, the POP3 server 841 can calculate the size of each message in octets when it opens the 842 maildrop. For example, if the POP3 server host internally represents 843 end-of-line as a single character, then the POP3 server simply counts 844 each occurrence of this character in a message as two octets. Note 845 that lines in the message which start with the termination octet need 846 not (and must not) be counted twice, since the POP3 client will 847 remove all byte-stuffed termination characters when it receives a 848 multi-line response. 850 11. References 852 [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 853 821, USC/Information Sciences Institute, August 1982. 855 [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text 856 Messages", STD 11, RFC 822, University of Delaware, August 1982. 858 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 859 MIT Laboratory for Computer Science, April, 1992. 861 [RFC1730] Crispin, M. "Internet Message Access Protocol - Version 4", 862 RFC 1730, University of Washington, December, 1994. 864 [RFC1734] Myers, J. "POP3 AUTHentication command", RFC 1734, Carnegie 865 Mellon, December, 1994. 867 12. Security Considerations 869 It is conjectured that use of the APOP command provides origin 870 identification and replay protection for a POP3 session. 871 Accordingly, a POP3 server which implements both the PASS and APOP 872 commands should not allow both methods of access for a given user; 874 Internet DRAFT POP3 October 4, 1995 876 that is, for a given mailbox name, either the USER/PASS command 877 sequence or the APOP command is allowed, but not both. 879 Further, note that as the length of the shared secret increases, so 880 does the difficulty of deriving it. 882 Servers that answer -ERR to the USER command are giving potential 883 attackers clues about which names are valid. 885 Use of the PASS command sends passwords in the clear over the 886 network. 888 Use of the RETR and TOP commands sends mail in the clear over the 889 network. 891 Otherwise, security issues are not discussed in this memo. 893 13. Acknowledgements 895 The POP family has a long and checkered history. Although primarily 896 a minor revision to RFC 1460, POP3 is based on the ideas presented in 897 RFCs 918, 937, and 1081. 899 In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff 900 provided significant comments on the APOP command. 902 14. Authors' Addresses 904 John G. Myers 905 Carnegie-Mellon University 906 5000 Forbes Ave 907 Pittsburgh, PA 15213 909 EMail: jgm+@cmu.edu 911 Marshall T. Rose 912 Dover Beach Consulting, Inc. 913 420 Whisman Court 914 Mountain View, CA 94043-2186 916 EMail: mrose@dbc.mtview.ca.us 918 Appendix A. Differences from RFC 1725 920 This memo is a revision to RFC 1725, a Draft Standard. It makes the 921 following changes from that document: 923 Internet DRAFT POP3 October 4, 1995 925 - clarifies that command keywords are case insensitive. 927 - specifies that servers must send "+OK" and "-ERR" in 928 upper case. 930 - specifies that the initial greeting is a positive response, 931 instead of any string which should be a positive response. 933 - clarifies behavior for unimplemented commands. 935 - makes the USER and PASS commands optional. 937 - clarified the set of possible responses to the USER command. 939 - reverses the order of the examples in the USER and PASS 940 commands, to reduce confusion. 942 - clarifies that the PASS command may only be given immediately 943 after a successful USER command. 945 - clarified the persistence requirements of UIDs and added some 946 implementation notes. 948 - specifies a UID length limitation of one to 70 octets. 950 - specifies a status indicator length limitation 951 of 512 octets, including the CRLF. 953 - clarifies that LIST with no arguments on an empty mailbox 954 returns success. 956 - adds a reference from the LIST command to the Message Format 957 section 959 - clarifies the behavior of QUIT upon failure 961 - clarifies the security section to not imply the use of the 962 USER command with the APOP command. 964 - adds references to RFCs 1730 and 1734 966 - clarifies the method by which a UA may enter mail into the 967 transport system. 969 - clarifies that the second argument to the TOP command is a 970 number of lines. 972 - changes the suggestion in the Security Considerations section 974 Internet DRAFT POP3 October 4, 1995 976 for a server to not accept both PASS and APOP for a given user 977 from a "must" to a "should". 979 Appendix B. Command Index 981 APOP ....................................................... 15 982 DELE ....................................................... 8 983 LIST ....................................................... 6 984 NOOP ....................................................... 9 985 PASS ....................................................... 14 986 QUIT ....................................................... 5 987 QUIT ....................................................... 10 988 RETR ....................................................... 8 989 RSET ....................................................... 9 990 STAT ....................................................... 6 991 TOP ........................................................ 11 992 UIDL ....................................................... 12 993 USER ....................................................... 13 995 Internet DRAFT POP3 October 4, 1995 997 Table of Contents 999 Status of this Memo ............................................... i 1000 1. Introduction ................................................... 2 1001 2. A Short Digression ............................................. 2 1002 3. Basic Operation ................................................ 3 1003 4. The AUTHORIZATION State ........................................ 4 1004 QUIT Command ................................................... 5 1005 5. The TRANSACTION State .......................................... 5 1006 STAT Command ................................................... 6 1007 LIST Command ................................................... 6 1008 RETR Command ................................................... 8 1009 DELE Command ................................................... 8 1010 NOOP Command ................................................... 9 1011 RSET Command ................................................... 9 1012 6. The UPDATE State ............................................... 10 1013 QUIT Command ................................................... 10 1014 7. Optional POP3 Commands ......................................... 11 1015 TOP Command .................................................... 11 1016 UIDL Command ................................................... 12 1017 USER Command ................................................... 13 1018 PASS Command ................................................... 14 1019 APOP Command ................................................... 15 1020 8. POP3 Command Summary ........................................... 16 1021 9. Example POP3 Session ........................................... 17 1022 10. Message Format ................................................ 18 1023 11. References .................................................... 18 1024 12. Security Considerations ....................................... 18 1025 13. Acknowledgements .............................................. 19 1026 14. Authors' Addresses ............................................ 19 1027 Appendix A. Differences from RFC 1725 ............................. 19 1028 Appendix B. Command Index ......................................... 21