Added all of the MH sources, including RCS files, in

[mmh] / docs / historical / mh-6.8.5 / support / pop / pop-more.txt

          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]
\f




          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]
\f




          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:

               <process-ID.clock@hostname>

          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]
\f




          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]
\f




          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]
\f




          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]
\f




          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]
\f




          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]
\f




          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]
\f




          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]
\f