![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to pop.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / contrib / mh / support / pop|
Return to pop.txt CVS log | Up to [CSRG BSD Unix] / 43BSD / contrib / mh / support / pop |
1.1 ! root 1: Request For Comments: draft ! 2: ! 3: ! 4: ! 5: ! 6: ! 7: ! 8: ! 9: ! 10: ! 11: ! 12: ! 13: ! 14: Post Office Protocol (revised) ! 15: ! 16: ! 17: Sun Oct 28 19:40:26 1984 ! 18: ! 19: Last Revision ! 20: Wed Oct 23 20:54:26 1985 ! 21: ! 22: Marshall T. Rose ! 23: ! 24: Department of Computer and Information Sciences ! 25: University of Delaware ! 26: Newark, DE 19716 ! 27: ! 28: MRose@UDel ! 29: ! 30: ! 31: ! 32: ! 33: This memo suggests a simple method for workstations to dynamically ! 34: access mail from a mailbox server. This RFC specifies a proposed ! 35: protocol for the ARPA Internet community, and requests discussion ! 36: and suggestions for improvements. ! 37: ! 38: ! 39: Acknowledgements ! 40: ! 41: This memo is based on RFC918. Although similar in form to the ! 42: original POP proposed for the ARPA Internet community, the protocol ! 43: discussed in this memo is similar in spirit to the ideas ! 44: investigated by the MZnet project at the University of California, ! 45: Irvine. ! 46: ! 47: Request For Comments: draft M. Rose ! 48: Post Office Protocol (revised) UDel ! 49: ! 50: ! 51: ! 52: Introduction ! 53: ! 54: On certain types of smaller nodes in the ARPA Internet it is often ! 55: impractical to maintain a message transport system(MTS). For ! 56: example, a workstation may not have sufficient resources (cycles, ! 57: disk space) in order to permit a SMTP server and associated local ! 58: mail delivery system to be kept resident and continuously running. ! 59: Similarly, it may be expensive (or impossible) to keep a personal ! 60: computer interconnected to an IP-style network for long amounts of ! 61: time (the node is lacking the resource known as "connectivity"). ! 62: ! 63: Despite this, it is often very useful to be able to manage mail on ! 64: these smaller nodes, and they often support a user agent(UA) to aid ! 65: the tasks of mail handling. To solve this problem, a node which ! 66: can support an MTS entity offers a maildrop service to these less ! 67: endowned nodes. The Post Office Protocol (POP) is intended to ! 68: permit a workstation to dynamically access a maildrop on a server ! 69: host in a useful fashion. Usually, this means that the POP is used ! 70: to allow a workstation to retrieve mail that the server is holding ! 71: for it. ! 72: ! 73: For the remainder of this memo, the term "client host" refers to a ! 74: host making use of the POP service, while the term "server host" ! 75: refers to a host which offers the POP service. ! 76: ! 77: The status of this protocol is experimental. ! 78: ! 79: ! 80: ! 81: A Short Digression ! 82: ! 83: This memo does not specify how a client host enters mail into the ! 84: transport system, although a method consistent with the philosophy ! 85: of this memo is presented here: ! 86: ! 87: When the user agent on a client host wishes to enter a message ! 88: into the transport system, it establishes an SMTP connection ! 89: to its relay host (this relay host could be, but need not be, ! 90: the POP server host for the client host). ! 91: ! 92: If this method is followed, then the client host appears to the MTS ! 93: as a user agent, and should NOT be regarded as a "trusted" MTS ! 94: entity in any sense whatsoever. This concept, along with the role ! 95: of the POP as a part of a split-UA model is discussed later in this ! 96: memo. ! 97: ! 98: The Protocol ! 99: ! 100: Initially the server host starts the POP service by listening on ! 101: TCP port 109. When a client host wishes to make use of the service ! 102: it establishes a TCP connection with the server host. When the ! 103: connection is established, the POP server sends a greeting. The ! 104: client and POP server then exchange commands and responses ! 105: (respectively) until the connection is closed or aborted. ! 106: ! 107: Commands in the POP consist of a keyword possibly followed by an ! 108: argument. All commands are terminated by a CRLF pair. ! 109: ! 110: Responses in the POP consist of a success indicator and a keyword ! 111: possibly followed by additional information. All responses are ! 112: terminated by a CRLF pair. There are currently two success ! 113: indicators: positive ("+OK") and negative ("-ERR"). ! 114: ! 115: Responses to certain commands are multi-line. In these cases, ! 116: which are clearly indicated below, after sending the first line of ! 117: the response and a CRLF, any additional lines are sent, each ! 118: terminated by a CRLF pair. When all lines of the response have ! 119: been sent, a final line is sent, consisting of a termination octet ! 120: (octal code 056, ".") and a CRLF pair. If any line of the ! 121: multi-line response begins with the termination octet, the line is ! 122: "bit-stuffed" by pre-pending the termination octet to that line of ! 123: the response. Hence a multi-line response is terminated with the ! 124: five octets "CRLF.CRLF". When examining a multi-line response, the ! 125: client checks to see if the line begins with the termination ! 126: octet. If so and if octets other than CRLF follow, the the first ! 127: octet of the line (the termination octet) is stripped away. If so ! 128: and if CRLF immediately follows the termination character, then the ! 129: response from the POP server is ended and the line containing ! 130: ".CRLF" is not considered part of the multi-line response. ! 131: ! 132: A POP session progresses through a number of states during its ! 133: lifetime. Once the TCP connection has been opened and the POP ! 134: server has sent the greeting, the session enters the AUTHORIZATION ! 135: state. In this state, the client must identify itself to the POP ! 136: server. Once the client has successfully done this, the server ! 137: acquires resources associated with the client's maildrop, and the ! 138: session enters the TRANSACTION state. In this state, the client ! 139: requests actions on the part of the POP server. When the client ! 140: has finished its transactions, the session enters the UPDATE state. ! 141: In this state, the POP server releases any resources acquired ! 142: during the TRANSACTION state and says goodbye. The TCP connection ! 143: is then closed. ! 144: ! 145: The AUTHORIZATION State ! 146: ! 147: Once the TCP connection has been opened by a POP client, the POP ! 148: server issues a one line greeting. This can be any string ! 149: terminated by CRLF. An example might be: ! 150: ! 151: S: +OK dewey POP server ready (Comments to: PostMaster@UDel) ! 152: ! 153: Note that this greeting is a POP reply. The POP server should always ! 154: give a positive response as the greeting. ! 155: ! 156: The POP session is now in the AUTHORIZATION state. The client must ! 157: now issue the USER command. If the POP server responds with a ! 158: positive success indicator ("+OK"), then the client may issue ! 159: either the PASS command to complete the authorization, or the QUIT ! 160: command to terminate the POP session. If the POP server responds ! 161: with a negative success indicator ("-ERR") to the USER command, ! 162: then the client may either issue a new USER command or may issue ! 163: the QUIT command. ! 164: ! 165: When the client issues the PASS command, the POP server uses the ! 166: argument pair from the USER and PASS commands to determine if the ! 167: client should be given access to the appropriate maildrop. If so, ! 168: the POP server then acquires an exclusive-access lock on the ! 169: maildrop. If the lock is successfully acquired, the POP server ! 170: parses the maildrop into individual messages (read note below) and ! 171: responds with a positive success indicator. The POP session now ! 172: enters the TRANSACTION state. If the lock can not be acquired or ! 173: the client should is denied access to the appropriate maildrop or ! 174: the maildrop can't be parsed for some reason, the POP server ! 175: responds with a negative success indicator. (If a lock was ! 176: acquired but the POP server intends to respond with a negative ! 177: success indicator, the POP server must release the lock prior to ! 178: rejecting the command.) At this point, the client may either issue ! 179: a new USER command and start again, or the client may issue the ! 180: QUIT command. ! 181: ! 182: NOTE: Minimal implementations of the POP need only be ! 183: able to break a maildrop into its component messages; ! 184: they need NOT be able to parse individual messages. More ! 185: advanced implementations may wish to have this ! 186: capability, for reasons discussed later. ! 187: ! 188: After the POP server has parsed the maildrop into individual ! 189: messages, it assigns a message-id to each message, and notes the ! 190: size of the message in octets. The first message in the maildrop ! 191: is assigned a message-id of "1", the second is assigned "2", and so ! 192: on, so that the n'th message in a maildrop is assigned a message-id ! 193: of "n". In POP commands and responses, all message-id's and ! 194: message sizes are expressed in base-10. ! 195: ! 196: Here are summaries for the three POP command discussed thus far: ! 197: ! 198: USER name ! 199: Arguments: a server specific user-id (required) ! 200: Restrictions: may only be given in the AUTHORIZATION state ! 201: after the POP greeting or after an unsuccessful USER ! 202: or PASS command ! 203: Possible Responses: ! 204: +OK name is welcome here ! 205: -ERR never heard of name ! 206: Examples: ! 207: C: USER mrose ! 208: S: +OK mrose is a real hoopy frood ! 209: ... ! 210: C: USER frated ! 211: S: -ERR sorry, frated doesn't get his mail here ! 212: ! 213: PASS string ! 214: Arguments: a server/user-id specific password (required) ! 215: Restrictions: may only be given in the AUTHORIZATION state ! 216: after a successful USER command ! 217: Possible Responses: ! 218: +OK maildrop locked and ready ! 219: -ERR invalid password ! 220: -ERR unable to lock maildrop ! 221: Examples: ! 222: C: USER mrose ! 223: S: +OK mrose is a real hoopy frood ! 224: C: PASS secret ! 225: S: +OK mrose's maildrop has 2 messages (320 octets) ! 226: ... ! 227: C: USER mrose ! 228: S: +OK mrose is a real hoopy frood ! 229: C: PASS secret ! 230: S: -ERR unable to lock mrose's maildrop, file already locked ! 231: ! 232: QUIT ! 233: Arguments: none ! 234: Restrictions: none ! 235: Possible Responses: ! 236: +OK ! 237: Examples: ! 238: C: QUIT ! 239: S: +OK dewey POP server signing off ! 240: ! 241: ! 242: ! 243: The TRANSACTION State ! 244: ! 245: Once the client has successfully identified itself to the POP ! 246: server and the POP server has locked and burst the appropriate ! 247: maildrop, the POP session is now in the TRANSACTION state. The ! 248: client may now issue any of the following POP commands repeatedly. ! 249: After each command, the POP server issues a response. Eventually, ! 250: the client issues the QUIT command and the POP session enters the ! 251: UPDATE state. ! 252: ! 253: Here are the POP commands valid in the TRANSACTION state: ! 254: ! 255: STAT ! 256: Arguments: none ! 257: Restrictions: may only be given in the TRANSACTION state. ! 258: Discussion: ! 259: ! 260: The POP server issues a positive response with a line ! 261: containing information for the maildrop. This line is ! 262: called a "drop listing" for that maildrop. ! 263: ! 264: In order to simplify parsing, all POP servers are ! 265: required to use a certain format for drop listings. The ! 266: first octets present must indicate the number of messages ! 267: in the maildrop. Following this is the size of the ! 268: maildrop in octets. This memo makes no requirement on ! 269: what follows the maildrop size. Minimal implementations ! 270: should just end that line of the response with a CRLF ! 271: pair. More advanced implementations may include other ! 272: information. ! 273: ! 274: NOTE: This memo STRONGLY discourages implementations ! 275: from supplying additional information in the drop ! 276: listing. Other, optional, facilities are discussed ! 277: later on which permit the client to parse the ! 278: messages in the maildrop. ! 279: ! 280: Note that messages marked as deleted are not counted in ! 281: either total. ! 282: ! 283: Possible Responses: ! 284: +OK nn mm ! 285: Examples: ! 286: C: STAT ! 287: S: +OK 2 320 ! 288: ! 289: LIST [msg] ! 290: Arguments: a message-id (optionally) If a message-id is ! 291: given, it may NOT refer to a message marked as deleted. ! 292: Restrictions: may only be given in the TRANSACTION state. ! 293: Discussion: ! 294: ! 295: If an argument was given and the POP server issues a ! 296: positive response with a line containing information for ! 297: that message. This line is called a "scan listing" ! 298: for that message. ! 299: ! 300: If no argument was given and the POP server issues a ! 301: positive response, then the response given is multi-line. ! 302: After the initial +OK, for each message in the maildrop, ! 303: the POP server responds with a line containing information ! 304: for that message. This line is called a "scan listing" ! 305: for that message. ! 306: ! 307: In order to simplify parsing, all POP servers are required ! 308: to use a certain format for scan listings. The first ! 309: octets present must be the message-id of the message. ! 310: Following the message-id is the size of the message in ! 311: octets. This memo makes no requirement on what follows ! 312: the message size in the scan listing. Minimal ! 313: implementations should just end that line of the response ! 314: with a CRLF pair. More advanced implementations may ! 315: include other information, as parsed from the message. ! 316: ! 317: NOTE: This memo STRONGLY discourages implementations ! 318: from supplying additional information in the scan ! 319: listing. Other, optional, facilities are discussed ! 320: later on which permit the client to parse the ! 321: messages in the maildrop. ! 322: ! 323: Note that messages marked as deleted are not listed. ! 324: ! 325: Possible Responses: ! 326: +OK scan listing follows ! 327: -ERR no such message ! 328: Examples: ! 329: C: LIST ! 330: S: +OK 2 messages (320 octets) ! 331: S: 1 120 ! 332: S: 2 200 ! 333: S: . ! 334: ... ! 335: C: LIST 2 ! 336: S: +OK 2 200 ! 337: ... ! 338: C: LIST 3 ! 339: S: -ERR no such message, only 2 messages in maildrop ! 340: ! 341: RETR msg ! 342: Arguments: a message-id (required) This message-id may NOT ! 343: refer to a message marked as deleted. ! 344: Restrictions: may only be given in the TRANSACTION state. ! 345: Discussion: ! 346: ! 347: If the POP server issues a positive response, then the ! 348: response given is multi-line. After the initial +OK, the ! 349: POP server sends the message corresponding to the given ! 350: message-id, being careful to bit-stuff the termination ! 351: character (as with all multi-line responses). ! 352: ! 353: Possible Responses: ! 354: +OK message follows ! 355: -ERR no such message ! 356: Examples: ! 357: C: RETR 1 ! 358: S: +OK 120 octets ! 359: S: <the POP server sends the entire message here> ! 360: S: . ! 361: ! 362: DELE msg ! 363: Arguments: a message-id (required) This message-id may NOT ! 364: refer to a message marked as deleted. ! 365: Restrictions: may only be given in the TRANSACTION state. ! 366: Discussion: ! 367: ! 368: The POP server marks the message as deleted. Any future ! 369: reference to the message-id associated with the message ! 370: in a POP command generates an error. The POP server does ! 371: not actually delete the message until the POP session ! 372: enters the UPDATE state. ! 373: ! 374: Possible Responses: ! 375: +OK message deleted ! 376: -ERR no such message ! 377: Examples: ! 378: C: DELE 1 ! 379: S: +OK message 1 deleted ! 380: ... ! 381: C: DELE 2 ! 382: S: -ERR message 2 already deleted ! 383: ! 384: NOOP ! 385: Arguments: none ! 386: Restrictions: may only be given in the TRANSACTION state. ! 387: Discussion: ! 388: ! 389: The POP server does nothing, it merely replies with a ! 390: positive response. ! 391: ! 392: Possible Responses: ! 393: +OK ! 394: Examples: ! 395: C: NOOP ! 396: S: +OK ! 397: ! 398: RSET ! 399: Arguments: none ! 400: Restrictions: may only be given in the TRANSACTION state. ! 401: Discussion: ! 402: ! 403: If any messages have been marked as deleted by the POP ! 404: server, they are unmarked. The POP server then replies ! 405: with a positive response. ! 406: ! 407: Possible Responses: ! 408: +OK ! 409: Examples: ! 410: C: RSET ! 411: S: +OK maildrop has 2 messages (320 octets) ! 412: ! 413: ! 414: ! 415: The UPDATE State ! 416: ! 417: When the client issues the QUIT command from the TRANSACTION state ! 418: the POP session enters the UPDATE state. (Note that if the client ! 419: issues the QUIT command from the AUTHORIZATION state, the POP ! 420: session terminates but does NOT enter the UPDATE state). ! 421: ! 422: QUIT ! 423: Arguments: none ! 424: Restrictions: none ! 425: Discussion: ! 426: ! 427: The POP server removes all messages marked as deleted ! 428: from the maildrop. It then releases the exclusive-access ! 429: lock on the maildrop and replies as to the success of ! 430: these operations. The TCP connection is then closed. ! 431: ! 432: Possible Responses: ! 433: +OK ! 434: Examples: ! 435: C: QUIT ! 436: S: +OK dewey POP server signing off (maildrop empty) ! 437: ... ! 438: C: QUIT ! 439: S: +OK dewey POP server signing off (2 messages left) ! 440: ... ! 441: ! 442: Optional POP Commands ! 443: ! 444: The POP commands discussed above must be supported by all minimal ! 445: implementations of POP servers. ! 446: ! 447: The optional POP commands described below permit a POP client ! 448: greater freedom in message handling, while preserving a simple POP ! 449: server implementation. ! 450: ! 451: NOTE: This memo STRONGLY encourages implementations to ! 452: support these commands in lieu of developing augmented ! 453: drop and scan listings. In short, the philosophy of this ! 454: memo is to put intelligence in the part of the POP client ! 455: and not the POP server. ! 456: ! 457: TOP msg n ! 458: Arguments: a message-id (required) and a number. This ! 459: message-id may NOT refer to a message marked as deleted. ! 460: Restrictions: may only be given in the TRANSACTION state. ! 461: Discussion: ! 462: ! 463: If the POP server issues a positive response, then the ! 464: response given is multi-line. After the initial +OK, the ! 465: POP server sends the headers of the message, the blank ! 466: line separating the headers from the body, and then the ! 467: number of lines indicated message's body, being careful to ! 468: bit-stuff the termination character (as with all ! 469: multi-line responses). ! 470: ! 471: Note that if the number of lines requested by the POP ! 472: client is greater than than the number of lines in the ! 473: body, then the POP server sends the entire message. ! 474: ! 475: Possible Responses: ! 476: +OK top of message follows ! 477: -ERR no such message ! 478: Examples: ! 479: C: TOP 10 ! 480: S: +OK ! 481: S: <the POP server sends the headers of the message, ! 482: a blank line, and the first 10 lines of the ! 483: body of the message> ! 484: S: . ! 485: ... ! 486: C: TOP 100 ! 487: S: -ERR no such message ! 488: ! 489: RPOP user ! 490: Arguments: a client specific user-id (required) ! 491: Restrictions: may only be given in the AUTHORIZATION state ! 492: after a successful USER command; in addition, may ! 493: only be given if the client used a reserved (privileged) ! 494: TCP port to connect to the server. ! 495: Discussion: ! 496: ! 497: The RPOP command may be used instead of the PASS command ! 498: to authenticate access to the maildrop. In order for this ! 499: command to be successful, the POP client must use a ! 500: reserved TCP port (port < 1024) to connect to the server. ! 501: The POP server uses the argument pair from the USER and ! 502: RPOP commands to determine if the client should be given ! 503: access to the appropriate maildrop. Unlike the PASS ! 504: command however, the POP server considers if the remote ! 505: user specified by the RPOP command who resides on the POP ! 506: client host is allowed to access the maildrop for the user ! 507: specified by the USER command (e.g., on Berkeley UNIX, the ! 508: .rhosts mechanism is used). With the exception of this ! 509: differing in authentication, this command is identical to ! 510: the PASS command. ! 511: ! 512: Possible Responses: ! 513: +OK maildrop locked and ready ! 514: -ERR permission denied ! 515: Examples: ! 516: C: USER mrose ! 517: S: +OK mrose is a real hoopy frood ! 518: C: RPOP mrose ! 519: S: +OK mrose's maildrop has 2 messages (320 octets) ! 520: ! 521: POP Command/Reply Summary ! 522: ! 523: Minimal POP Commands: ! 524: USER name valid in the AUTHORIZATION state ! 525: PASS string ! 526: QUIT ! 527: ! 528: STAT valid in the TRANSACTION state ! 529: LIST [msg] ! 530: RETR msg ! 531: DELE msg ! 532: NOOP ! 533: RSET ! 534: ! 535: QUIT valid in the UPDATE state ! 536: ! 537: Optional POP Commands: ! 538: RPOP user valid in the AUTHORIZATION state ! 539: ! 540: TOP msg n valid in the TRANSACTION state ! 541: ! 542: POP Replies: ! 543: +OK ! 544: -ERR ! 545: ! 546: Note that with the exception of the STAT command, the reply given ! 547: by the POP server to any command is significant only to "+OK" and ! 548: "-ERR". Any text occurring after this reply may be ignored by the ! 549: client. ! 550: ! 551: Example POP Session ! 552: ! 553: S: <wait for connection on TCP port 109> ! 554: ... ! 555: C: <open connection> ! 556: S: +OK dewey POP server ready (Comments to: PostMaster@UDel) ! 557: C: USER mrose ! 558: S: +OK mrose is a real hoopy frood ! 559: C: PASS secret ! 560: S: +OK mrose's maildrop has 2 messages (320 octets) ! 561: C: STAT ! 562: S: +OK 2 320 ! 563: C: LIST ! 564: S: +OK 2 messages (320 octets) ! 565: S: 1 120 ! 566: S: 2 200 ! 567: S: . ! 568: C: RETR 1 ! 569: S: +OK 120 octets ! 570: S: <the POP server sends message 1> ! 571: S: . ! 572: C: DELE 1 ! 573: S: +OK message 1 deleted ! 574: C: RETR 2 ! 575: S: +OK 200 octets ! 576: S: <the POP server sends message 2> ! 577: S: . ! 578: C: DELE 2 ! 579: S: +OK message 2 deleted ! 580: C: QUIT ! 581: S: +OK dewey POP server signing off (maildrop empty) ! 582: C: <close connection> ! 583: S: <wait for next connection> ! 584: ! 585: ! 586: ! 587: Message Format ! 588: ! 589: All messages transmitted during a POP session are assumed to ! 590: conform to the standard for the format of ARPA Internet text ! 591: messages [RFC822]. ! 592: ! 593: It is important to note that the byte count for a message on the ! 594: server host may differ from the octet count assigned to that ! 595: message due to local conventions for designating end-of-line. ! 596: Usually, during the AUTHORIZATION state of the POP session, the POP ! 597: client can calculate the size of each message in octets when it ! 598: parses the maildrop into messages. For example, if the POP server ! 599: host internally represents end-of-line as a single character, then ! 600: the POP server simply counts each occurrence of this character in a ! 601: message as two octets. Note that lines in the message which start ! 602: with the termination octet need not be counted twice, since the POP ! 603: client will remove all bit-stuffed termination characters when it ! 604: receives a multi-line response. ! 605: ! 606: ! 607: ! 608: The POP and the Split-UA model ! 609: ! 610: The underlying paradigm in which the POP functions is that of a ! 611: split-UA model. The POP client host, being a remote PC based ! 612: workstation, acts solely as a client to the message transport ! 613: system. It does not provide delivery/authentication services to ! 614: others. Hence, it is acting as a UA, on behalf of the person using ! 615: the workstation. Furthermore, the workstation uses SMTP to enter ! 616: mail into the MTS. ! 617: ! 618: In this sense we have two UA functions which interface to the ! 619: message transport system: Posting (SMTP) and Retrieval (POP). The ! 620: entity which supports this type of environment is called a split-UA ! 621: (since the user agent is split between two hosts which must ! 622: interoperate to provide these functions). ! 623: ! 624: ASIDE: Others might term this a remote-UA instead. There ! 625: are arguments supporting the use of both terms. ! 626: ! 627: This memo has explicitly referenced TCP as the underlying transport ! 628: agent for the POP. This need not be the case. In the MZnet ! 629: split-UA, for example, personal micro-computer systems are used ! 630: which do not have IP-style networking capability. To connect to ! 631: the POP server host, a PC establishes a terminal connection using ! 632: some simple protocol (PhoneNet). A program on the PC drives the ! 633: connection, first establishing a login session as a normal user. ! 634: The login shell for this pseudo-user is a program which drives the ! 635: other half of the terminal protocol and communicates with one of ! 636: two servers. Although MZnet can support several PCs, a single ! 637: pseudo-user login is present on the server host. The user-id and ! 638: password for this pseudo-user login is known to all members of ! 639: MZnet. Hence, the first action of the login shell, after starting ! 640: the terminal protocol, is to demand a USER/PASS authorization pair ! 641: from the PC. This second level of authorization is used to ! 642: ascertain who is interacting with the MTS. Although the server host ! 643: is deemed to support a "trusted" MTS entity, PCs in MZnet are not. ! 644: Naturally, the USER/PASS authorization pair for a PC is known only ! 645: to the owner of the PC (in theory, at least). ! 646: ! 647: After successfully verifying the identity of the client, a modified ! 648: SMTP server is started, and the PC posts mail with the server host. ! 649: After the QUIT command is given to the SMTP server and it ! 650: terminates, a modified POP server is started, and the PC retrieves ! 651: mail from the server host. After the QUIT command is given to the ! 652: POP server and it terminates, the login shell for the pseudo-user ! 653: terminates the terminal protocol and logs the job out. The PC then ! 654: closes the terminal connection to the server host. ! 655: ! 656: The SMTP server used by MZnet is modified in the sense that it ! 657: knows that it's talking to a user agent and not a "trusted" entity ! 658: in the message transport system. Hence, it does performs the ! 659: validation activities normally performed by an entity in the MTS ! 660: when it accepts a message from a UA. ! 661: ! 662: The POP server used by MZnet is modified in the sense that it does ! 663: not require a USER/PASS combination before entering the TRANSACTION ! 664: state. The reason for this (of course) is that the PC has already ! 665: identified itself during the second-level authorization step ! 666: described above. ! 667: ! 668: NOTE: Truth in advertising laws require that the author ! 669: of this memo state that MZnet has not actually been fully ! 670: implemented. The concepts presented and proven by the ! 671: project led to the notion of the MZnet split-slot model. ! 672: This notion has inspired the split-UA concept described ! 673: in this memo, led to the author's interest in the POP, ! 674: and heavily influenced the the description of the POP ! 675: herein. ! 676: ! 677: In fact, some UAs present in the ARPA Internet already support the ! 678: notion of posting directly to an SMTP server and retreiving mail ! 679: directly from a POP server, even if the POP server and client ! 680: resided on the same host! ! 681: ! 682: ASIDE: this discussion raises an issue which this memo ! 683: purposedly avoids: how does SMTP know that it's talking ! 684: to a "trusted" MTS entity? ! 685: ! 686: References ! 687: ! 688: [MZnet] E.A. Stefferud, J.N. Sweet, T.P. Domae. ! 689: "MZnet: Mail Service for Personal Micro-Computer ! 690: Systems", Proceedings, IFIP 6.5 International ! 691: Conference on Computer Message Systems, Nottingham, U.K. ! 692: (May, 1984) ! 693: ! 694: [RFC821] J.B. Postel. ! 695: "Simple Mail Transfer Protocol", USC/Information Sciences ! 696: Institute. (August, 1982) ! 697: ! 698: [RFC822] D.H. Crocker. ! 699: "Standard for the Format of ARPA Internet Text ! 700: Messages", University of Delaware. (August, 1982) ! 701: ! 702: [RFC918] J.K. Reynolds. ! 703: "Post Office Protocol", USC/Information Sciences Institute. ! 704: (October, 1984) ! 705: ! 706: [RFC923] J.K. Reynolds, J.B. Postel. ! 707: "Assigned Numbers", USC/Information Sciences Institute. ! 708: (October, 1984)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.