draft POP Version 3: More Service Offerings Apr 92 Post Office Protocol: Version 3 More Service Offerings Fri Apr 17 21:03:20 1992 Marshall T. Rose Dover Beach Consulting, Inc. mrose@dbc.mtview.ca.us 1. Status of this Memo This memo provides information for the Internet community. It does not specify any standard. Distribution of this memo is unlimited. Please send comments to the author. 2. Abstract This memo suggests some modest enhancements to version 3 of the Post Office Protocol (RFC 1081). All of these extensions are optional. In particular, administrators should examine their environment to see if any of these enhancements are useful. M. Rose [Page 1] draft POP Version 3: More Service Offerings Apr 92 3. Historical Overview The Post Office Protocol (POP) was developed to provide a simple mechanism for workstations to download their mailboxes from workgroup and departmental servers. Typically, the workstations and servers are interconnected via a LAN or perhaps an internet-mesh with reasonable throughput and latency. As use of the Internet suite of protocols has grown, different kind of environments are beginning to use the POP. This memo suggests optional enhancements to the POP to allow it to function better in these environments. M. Rose [Page 2] draft POP Version 3: More Service Offerings Apr 92 4. The APOP command Each POP session starts with a USER/PASS exchange. This results in a POP-subscriber password being sent in the clear on the network. For intermittent use of POP, this may not introduce a sizable risk. However, many POP client implementations connect to the POP server on a regular basis -- to check for new mail. Further the interval of session initiation may be on the order of five minutes. Hence, the risk of password capture is greatly enhanced. A new method of authentication is required which provides for both origin authentication and replay protection, but which does not involve sending a password in the clear over the network. This memo introduces a new command, APOP, to provide this functionality. A POP server which implements the APOP command will include a timestamp in its banner greeting. The syntax of the timestamp corresponds to the `msg-id' in RFC 822, and MUST be different each time the POP server issues a banner greeting. For example, on a UNIX implementation in which a separate UNIX process is used for each instance of a POP server, the syntax of the timestamp might be: where `process-ID' is the decimal value of the process's PID, clock is the decimal value of the system clock, and hostname is the fully-qualified domain-name corresponding to the host where the POP server is running. The POP client makes note of this timestamp, and then issues the APOP command. The syntax of this command is: APOP name digest The `name' parameter is a locally-significant string which identifies a particular POP-subscriber. The `digest' parameter is calculated by applying the MD5 algorithm[1] to a string consisting of the timestamp (including angle-brackets) followed by a shared secret. This shared secret is a string known only to the POP client and POP server. Great care should be taken to prevent unauthorized disclosure of the secret, as knowledge of the secret will allow any entity to M. Rose [Page 3] draft POP Version 3: More Service Offerings Apr 92 successfully masquerade as the named POP-subscriber. The `digest' parameter itself is a 16-octet value which is sent in hexadecimal format. When the POP server receives the APOP command, it verifies the digest provided. If the digest is correct, the POP server issues a positive response, and the POP session enters the TRANSACTION state. Otherwise, a negative response is issued and the POP session remains in the AUTHORIZATION state. 4.1. Usage Example S: +OK POP server ready <1896.697170952@dbc.mtview.ca.us> C: USER mrose S: +OK password required for mrose C: APOP c4c9334bac560ecc979e58001b3e22fb S: +OK maildrop has 1 message (369 octets) In this example, the shared secret is the string `tanstaaf'. Hence, the MD5 algorithm is applied to the string <1896.697170952@dbc.mtview.ca.us>tanstaaf which produces a digest value of c4c9334bac560ecc979e58001b3e22fb M. Rose [Page 4] draft POP Version 3: More Service Offerings Apr 92 5. The XTND SCAN command The current POP model works best when network latency and throughput is on the order provided by most LANs. However, when POP is used over low-speed connections (e.g., 2400 baud dialup lines), the POP does not work well. Historically, the POP model has been to make only minimal requirements on the POP server. In order to more effectively operate over low-speed connections, this model must be modified somewhat. Implementation experience shows that the largest improvement can be achieved by making one shift: having the POP server generate a scan listing for the POP client. This memo introduces a new command, XTND SCAN, to provide this functionality. A POP client issues the XTND SCAN command during the TRANSACTION state. The syntax of this command is: XTND SCAN width [format] The `width' parameter is the maximum length for a scan listing. The optional `format' parameter is a quoted-string with the semantics of an mh-format(5) string[2]. If the `format' parameter is not given, the POP server uses a locally-defined default value. Note that the resulting format string must not contain CR or LF. The `format' parameter is the only token in the POP which must be enclosed in double-quotation marks. Within the string, two special sequences are recognized: \" - double-quote \\ - single-\ Otherwise, each character is used verbatim. Note that this string can be quite long (on the order of 400 characters). When the POP server receives the XTND SCAN command and if it implements it, it issues a positive response. Otherwise a negative response is issued. Thereafter, whenever the POP client issues a LIST command, the syntax of the resulting `scan listing' is of the form: msgno size #string M. Rose [Page 5] draft POP Version 3: More Service Offerings Apr 92 As with the standard POP, the `msgno' field gives the message number and the `size' field gives the size of the message in octets. The `string' parameter, which immediately follows the `#' character is the string calculated when the formatting string is applied to the message. Note that the `string' may not be multiline. 5.1. Usage Example S: XTND SCAN 80 "%4(msg)%<(cur)+%| %>%<{replied}-%|... C: +OK SCAN S: LIST 1 C: +OK 1 369 # 1 02/03 17:49PST To:mrose test<< M. Rose [Page 6] draft POP Version 3: More Service Offerings Apr 92 6. Implementations MH 6.7.4 implements the POP extensions described in this memo. Contact Bug-MH@ics.uci.edu for information on how to get MH. M. Rose [Page 7] draft POP Version 3: More Service Offerings Apr 92 7. Acknowledgements The author gratefully acknowledges the comments of Alfred Grimstad and Neil Ostroff of Bellcore, and Keith McCloghrie of Hughes LAN Systems. M. Rose [Page 8] draft POP Version 3: More Service Offerings Apr 92 8. References [1] R.L. Rivest, The MD5 Message-Digest Algorithm. Request for Comments 1321, (April, 1992). [2] M.T. Rose, J.L. Romine, The Rand MH Message Handling System: User's Manual, November, 1985. M. Rose [Page 9] draft POP Version 3: More Service Offerings Apr 92 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 Historical Overview ................................... 2 4 The APOP command ...................................... 3 4.1 Usage Example ....................................... 4 5 The XTND SCAN command ................................. 5 5.1 Usage Example ....................................... 6 6 Implementations ....................................... 7 7 Acknowledgements ...................................... 8 8 References ............................................ 9 M. Rose [Page 10]