home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 3 Comm / 03-Comm.zip / md5.zip / RFC1725.TXT < prev   
Text File  |  1994-12-30  |  36KB  |  1,012 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           J. Myers
  8. Request for Comments: 1725                               Carnegie Mellon
  9. Obsoletes: 1460                                                  M. Rose
  10. Category: Standards Track                   Dover Beach Consulting, Inc.
  11.                                                            November 1994
  12.  
  13.  
  14.                     Post Office Protocol - Version 3
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Overview
  25.  
  26.    This memo is a revision to RFC 1460, a Draft Standard.  It makes the
  27.    following changes from that document:
  28.  
  29.       - removed text regarding "split-UA model", which didn't add
  30.         anything to the understanding of POP
  31.  
  32.       - clarified syntax of commands, keywords, and arguments
  33.  
  34.       - clarified behavior on broken connection
  35.  
  36.       - explicitly permitted an inactivity autologout timer
  37.  
  38.       - clarified the requirements of the "exclusive-access lock"
  39.  
  40.       - removed implementation-specific wording regarding the parsing of
  41.         the maildrop
  42.  
  43.       - allowed servers to close the connection after a failed
  44.         authentication command
  45.  
  46.       - removed the LAST command
  47.  
  48.       - fixed typo in example of TOP command
  49.  
  50.       - clarified that the second argument to the TOP command is non-
  51.         negative
  52.  
  53.       - added the optional UIDL command
  54.  
  55.  
  56.  
  57.  
  58. Myers & Rose                                                    [Page 1]
  59.  
  60. RFC 1725                          POP3                     November 1994
  61.  
  62.  
  63.       - added warning regarding length of shared secrets with APOP
  64.  
  65.       - added additional warnings to the security considerations section
  66.  
  67. 1. Introduction
  68.  
  69.    On certain types of smaller nodes in the Internet it is often
  70.    impractical to maintain a message transport system (MTS).  For
  71.    example, a workstation may not have sufficient resources (cycles,
  72.    disk space) in order to permit a SMTP server [RFC821] and associated
  73.    local mail delivery system to be kept resident and continuously
  74.    running.  Similarly, it may be expensive (or impossible) to keep a
  75.    personal computer interconnected to an IP-style network for long
  76.    amounts of time (the node is lacking the resource known as
  77.    "connectivity").
  78.  
  79.    Despite this, it is often very useful to be able to manage mail on
  80.    these smaller nodes, and they often support a user agent (UA) to aid
  81.    the tasks of mail handling.  To solve this problem, a node which can
  82.    support an MTS entity offers a maildrop service to these less endowed
  83.    nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
  84.    permit a workstation to dynamically access a maildrop on a server
  85.    host in a useful fashion.  Usually, this means that the POP3 is used
  86.    to allow a workstation to retrieve mail that the server is holding
  87.    for it.
  88.  
  89.    For the remainder of this memo, the term "client host" refers to a
  90.    host making use of the POP3 service, while the term "server host"
  91.    refers to a host which offers the POP3 service.
  92.  
  93. 2. A Short Digression
  94.  
  95.    This memo does not specify how a client host enters mail into the
  96.    transport system, although a method consistent with the philosophy of
  97.    this memo is presented here:
  98.  
  99.       When the user agent on a client host wishes to enter a message
  100.       into the transport system, it establishes an SMTP connection to
  101.       its relay host (this relay host could be, but need not be, the
  102.       POP3 server host for the client host).
  103.  
  104. 3. Basic Operation
  105.  
  106.    Initially, the server host starts the POP3 service by listening on
  107.    TCP port 110.  When a client host wishes to make use of the service,
  108.    it establishes a TCP connection with the server host.  When the
  109.    connection is established, the POP3 server sends a greeting.  The
  110.    client and POP3 server then exchange commands and responses
  111.  
  112.  
  113.  
  114. Myers & Rose                                                    [Page 2]
  115.  
  116. RFC 1725                          POP3                     November 1994
  117.  
  118.  
  119.    (respectively) until the connection is closed or aborted.
  120.  
  121.    Commands in the POP3 consist of a keyword, possibly followed by one
  122.    or more arguments.  All commands are terminated by a CRLF pair.
  123.    Keywords and arguments consist of printable ASCII characters.
  124.    Keywords and arguments are each separated by a single SPACE
  125.    character.  Keywords are three or four characters long. Each argument
  126.    may be up to 40 characters long.
  127.  
  128.    Responses in the POP3 consist of a status indicator and a keyword
  129.    possibly followed by additional information.  All responses are
  130.    terminated by a CRLF pair.  There are currently two status
  131.    indicators: positive ("+OK") and negative ("-ERR").
  132.  
  133.    Responses to certain commands are multi-line.  In these cases, which
  134.    are clearly indicated below, after sending the first line of the
  135.    response and a CRLF, any additional lines are sent, each terminated
  136.    by a CRLF pair.  When all lines of the response have been sent, a
  137.    final line is sent, consisting of a termination octet (decimal code
  138.    046, ".") and a CRLF pair.  If any line of the multi-line response
  139.    begins with the termination octet, the line is "byte-stuffed" by
  140.    pre-pending the termination octet to that line of the response.
  141.    Hence a multi-line response is terminated with the five octets
  142.    "CRLF.CRLF".  When examining a multi-line response, the client checks
  143.    to see if the line begins with the termination octet.  If so and if
  144.    octets other than CRLF follow, the the first octet of the line (the
  145.    termination octet) is stripped away.  If so and if CRLF immediately
  146.    follows the termination character, then the response from the POP
  147.    server is ended and the line containing ".CRLF" is not considered
  148.    part of the multi-line response.
  149.  
  150.    A POP3 session progresses through a number of states during its
  151.    lifetime.  Once the TCP connection has been opened and the POP3
  152.    server has sent the greeting, the session enters the AUTHORIZATION
  153.    state.  In this state, the client must identify itself to the POP3
  154.    server.  Once the client has successfully done this, the server
  155.    acquires resources associated with the client's maildrop, and the
  156.    session enters the TRANSACTION state.  In this state, the client
  157.    requests actions on the part of the POP3 server.  When the client has
  158.    issued the QUIT command, the session enters the UPDATE state.  In
  159.    this state, the POP3 server releases any resources acquired during
  160.    the TRANSACTION state and says goodbye.  The TCP connection is then
  161.    closed.
  162.  
  163.    A POP3 server MAY have an inactivity autologout timer.  Such a timer
  164.    MUST be of at least 10 minutes' duration.  The receipt of any command
  165.    from the client during that interval should suffice to reset the
  166.    autologout timer.  When the timer expires, the session does NOT enter
  167.  
  168.  
  169.  
  170. Myers & Rose                                                    [Page 3]
  171.  
  172. RFC 1725                          POP3                     November 1994
  173.  
  174.  
  175.    the UPDATE state--the server should close the TCP connection without
  176.    removing any messages or sending any response to the client.
  177.  
  178. 4. The AUTHORIZATION State
  179.  
  180.    Once the TCP connection has been opened by a POP3 client, the POP3
  181.    server issues a one line greeting.  This can be any string terminated
  182.    by CRLF.  An example might be:
  183.  
  184.       S:  +OK POP3 server ready
  185.  
  186.    Note that this greeting is a POP3 reply.  The POP3 server should
  187.    always give a positive response as the greeting.
  188.  
  189.    The POP3 session is now in the AUTHORIZATION state.  The client must
  190.    now identify and authenticate itself to the POP3 server.  Two
  191.    possible mechanisms for doing this are described in this document,
  192.    the USER and PASS command combination and the APOP command.  The APOP
  193.    command is described later in this document.
  194.  
  195.    To authenticate using the USER and PASS command combination, the
  196.    client must first issue the USER command.  If the POP3 server
  197.    responds with a positive status indicator ("+OK"), then the client
  198.    may issue either the PASS command to complete the authentication, or
  199.    the QUIT command to terminate the POP3 session.  If the POP3 server
  200.    responds with a negative status indicator ("-ERR") to the USER
  201.    command, then the client may either issue a new authentication
  202.    command or may issue the QUIT command.
  203.  
  204.    When the client issues the PASS command, the POP3 server uses the
  205.    argument pair from the USER and PASS commands to determine if the
  206.    client should be given access to the appropriate maildrop.
  207.  
  208.    Once the POP3 server has determined through the use of any
  209.    authentication command that the client should be given access to the
  210.    appropriate maildrop, the POP3 server then acquires an exclusive-
  211.    access lock on the maildrop, as necessary to prevent messages from
  212.    being modified or removed before the session enters the UPDATE state.
  213.    If the lock is successfully acquired, the POP3 server responds with a
  214.    positive status indicator.  The POP3 session now enters the
  215.    TRANSACTION state, with no messages marked as deleted.  If the the
  216.    maildrop cannot be opened for some reason (for example, a lock can
  217.    not be acquired, the client is denied access to the appropriate
  218.    maildrop, or the maildrop cannot be parsed), the POP3 server responds
  219.    with a negative status indicator.  (If a lock was acquired but the
  220.    POP3 server intends to respond with a negative status indicator, the
  221.    POP3 server must release the lock prior to rejecting the command.)
  222.    After returning a negative status indicator, the server may close the
  223.  
  224.  
  225.  
  226. Myers & Rose                                                    [Page 4]
  227.  
  228. RFC 1725                          POP3                     November 1994
  229.  
  230.  
  231.    connection.  If the server does not close the connection, the client
  232.    may either issue a new authentication command and start again, or the
  233.    client may issue the QUIT command.
  234.  
  235.    After the POP3 server has opened the maildrop, it assigns a message-
  236.    number to each message, and notes the size of each message in octets.
  237.    The first message in the maildrop is assigned a message-number of
  238.    "1", the second is assigned "2", and so on, so that the n'th message
  239.    in a maildrop is assigned a message-number of "n".  In POP3 commands
  240.    and responses, all message-number's and message sizes are expressed
  241.    in base-10 (i.e., decimal).
  242.  
  243.    Here are summaries for the three POP3 commands discussed thus far:
  244.  
  245.       USER name
  246.  
  247.          Arguments:
  248.              a string identifying a mailbox (required), which is of
  249.              significance ONLY to the server
  250.  
  251.          Restrictions:
  252.              may only be given in the AUTHORIZATION state after the POP3
  253.              greeting or after an unsuccessful USER or PASS command
  254.  
  255.          Possible Responses:
  256.              +OK name is a valid mailbox
  257.              -ERR never heard of mailbox name
  258.  
  259.          Examples:
  260.              C: USER mrose
  261.              S: +OK mrose is a real hoopy frood
  262.                 ...
  263.              C: USER frated
  264.              S: -ERR sorry, no mailbox for frated here
  265.  
  266.       PASS string
  267.  
  268.          Arguments:
  269.              a server/mailbox-specific password (required)
  270.  
  271.          Restrictions:
  272.              may only be given in the AUTHORIZATION state after a
  273.              successful USER command
  274.  
  275.          Discussion:
  276.              Since the PASS command has exactly one argument, a POP3
  277.              server may treat spaces in the argument as part of the
  278.              password, instead of as argument separators.
  279.  
  280.  
  281.  
  282. Myers & Rose                                                    [Page 5]
  283.  
  284. RFC 1725                          POP3                     November 1994
  285.  
  286.  
  287.          Possible Responses:
  288.              +OK maildrop locked and ready
  289.              -ERR invalid password
  290.              -ERR unable to lock maildrop
  291.  
  292.          Examples:
  293.              C: USER mrose
  294.              S: +OK mrose is a real hoopy frood
  295.              C: PASS secret
  296.              S: +OK mrose's maildrop has 2 messages (320 octets)
  297.                ...
  298.              C: USER mrose
  299.              S: +OK mrose is a real hoopy frood
  300.              C: PASS secret
  301.              S: -ERR maildrop already locked
  302.  
  303.       QUIT
  304.  
  305.          Arguments: none
  306.  
  307.          Restrictions: none
  308.  
  309.          Possible Responses:
  310.              +OK
  311.  
  312.          Examples:
  313.              C: QUIT
  314.              S: +OK dewey POP3 server signing off
  315.  
  316. 5. The TRANSACTION State
  317.  
  318.    Once the client has successfully identified itself to the POP3 server
  319.    and the POP3 server has locked and opened the appropriate maildrop,
  320.    the POP3 session is now in the TRANSACTION state.  The client may now
  321.    issue any of the following POP3 commands repeatedly.  After each
  322.    command, the POP3 server issues a response.  Eventually, the client
  323.    issues the QUIT command and the POP3 session enters the UPDATE state.
  324.  
  325.    Here are the POP3 commands valid in the TRANSACTION state:
  326.  
  327.       STAT
  328.  
  329.          Arguments: none
  330.  
  331.          Restrictions:
  332.              may only be given in the TRANSACTION state
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Myers & Rose                                                    [Page 6]
  339.  
  340. RFC 1725                          POP3                     November 1994
  341.  
  342.  
  343.          Discussion:
  344.              The POP3 server issues a positive response with a line
  345.              containing information for the maildrop.  This line is
  346.              called a "drop listing" for that maildrop.
  347.  
  348.              In order to simplify parsing, all POP3 servers required to
  349.              use a certain format for drop listings.  The positive
  350.              response consists of "+OK" followed by a single space, the
  351.              number of messages in the maildrop, a single space, and the
  352.              size of the maildrop in octets.  This memo makes no
  353.              requirement on what follows the maildrop size.  Minimal
  354.              implementations should just end that line of the response
  355.              with a CRLF pair.  More advanced implementations may
  356.              include other information.
  357.  
  358.                 NOTE: This memo STRONGLY discourages implementations
  359.                 from supplying additional information in the drop
  360.                 listing.  Other, optional, facilities are discussed
  361.                 later on which permit the client to parse the messages
  362.                 in the maildrop.
  363.  
  364.              Note that messages marked as deleted are not counted in
  365.              either total.
  366.  
  367.          Possible Responses:
  368.              +OK nn mm
  369.  
  370.          Examples:
  371.              C: STAT
  372.              S: +OK 2 320
  373.  
  374.       LIST [msg]
  375.  
  376.          Arguments:
  377.              a message-number (optional), which, if present, may NOT
  378.              refer to a message marked as deleted
  379.  
  380.          Restrictions:
  381.              may only be given in the TRANSACTION state
  382.  
  383.          Discussion:
  384.              If an argument was given and the POP3 server issues a
  385.              positive response with a line containing information for
  386.              that message.  This line is called a "scan listing" for
  387.              that message.
  388.  
  389.              If no argument was given and the POP3 server issues a
  390.              positive response, then the response given is multi-line.
  391.  
  392.  
  393.  
  394. Myers & Rose                                                    [Page 7]
  395.  
  396. RFC 1725                          POP3                     November 1994
  397.  
  398.  
  399.              After the initial +OK, for each message in the maildrop,
  400.              the POP3 server responds with a line containing information
  401.              for that message.  This line is also called a "scan
  402.              listing" for that message.
  403.  
  404.              In order to simplify parsing, all POP3 servers are required
  405.              to use a certain format for scan listings.  A scan listing
  406.              consists of the message-number of the message, followed by
  407.              a single space and the exact size of the message in octets.
  408.              This memo makes no requirement on what follows the message
  409.              size in the scan listing.  Minimal implementations should
  410.              just end that line of the response with a CRLF pair.  More
  411.              advanced implementations may include other information, as
  412.              parsed from the message.
  413.  
  414.                 NOTE: This memo STRONGLY discourages implementations
  415.                 from supplying additional information in the scan
  416.                 listing.  Other, optional, facilities are discussed
  417.                 later on which permit the client to parse the messages
  418.                 in the maildrop.
  419.  
  420.              Note that messages marked as deleted are not listed.
  421.  
  422.          Possible Responses:
  423.              +OK scan listing follows
  424.              -ERR no such message
  425.  
  426.          Examples:
  427.              C: LIST
  428.              S: +OK 2 messages (320 octets)
  429.              S: 1 120
  430.              S: 2 200
  431.              S: .
  432.                ...
  433.              C: LIST 2
  434.              S: +OK 2 200
  435.                ...
  436.              C: LIST 3
  437.              S: -ERR no such message, only 2 messages in maildrop
  438.  
  439.       RETR msg
  440.  
  441.          Arguments:
  442.              a message-number (required) which may not refer to a
  443.              message marked as deleted
  444.  
  445.          Restrictions:
  446.              may only be given in the TRANSACTION state
  447.  
  448.  
  449.  
  450. Myers & Rose                                                    [Page 8]
  451.  
  452. RFC 1725                          POP3                     November 1994
  453.  
  454.  
  455.          Discussion:
  456.              If the POP3 server issues a positive response, then the
  457.              response given is multi-line.  After the initial +OK, the
  458.              POP3 server sends the message corresponding to the given
  459.              message-number, being careful to byte-stuff the termination
  460.              character (as with all multi-line responses).
  461.  
  462.          Possible Responses:
  463.              +OK message follows
  464.              -ERR no such message
  465.  
  466.          Examples:
  467.              C: RETR 1
  468.              S: +OK 120 octets
  469.              S: <the POP3 server sends the entire message here>
  470.              S: .
  471.  
  472.       DELE msg
  473.  
  474.          Arguments:
  475.              a message-number (required) which may not refer to a
  476.              message marked as deleted
  477.  
  478.          Restrictions:
  479.              may only be given in the TRANSACTION state
  480.  
  481.          Discussion:
  482.              The POP3 server marks the message as deleted.  Any future
  483.              reference to the message-number associated with the message
  484.              in a POP3 command generates an error.  The POP3 server does
  485.              not actually delete the message until the POP3 session
  486.              enters the UPDATE state.
  487.  
  488.          Possible Responses:
  489.              +OK message deleted
  490.              -ERR no such message
  491.  
  492.          Examples:
  493.              C: DELE 1
  494.              S: +OK message 1 deleted
  495.                 ...
  496.              C: DELE 2
  497.              S: -ERR message 2 already deleted
  498.  
  499.       NOOP
  500.  
  501.          Arguments: none
  502.  
  503.  
  504.  
  505.  
  506. Myers & Rose                                                    [Page 9]
  507.  
  508. RFC 1725                          POP3                     November 1994
  509.  
  510.  
  511.          Restrictions:
  512.              may only be given in the TRANSACTION state
  513.  
  514.          Discussion:
  515.              The POP3 server does nothing, it merely replies with a
  516.              positive response.
  517.  
  518.          Possible Responses:
  519.              +OK
  520.  
  521.          Examples:
  522.              C: NOOP
  523.              S: +OK
  524.  
  525.       RSET
  526.  
  527.          Arguments: none
  528.  
  529.          Restrictions:
  530.              may only be given in the TRANSACTION state
  531.  
  532.          Discussion:
  533.              If any messages have been marked as deleted by the POP3
  534.              server, they are unmarked.  The POP3 server then replies
  535.              with a positive response.
  536.  
  537.          Possible Responses:
  538.              +OK
  539.  
  540.          Examples:
  541.              C: RSET
  542.              S: +OK maildrop has 2 messages (320 octets)
  543.  
  544. 6. The UPDATE State
  545.  
  546.    When the client issues the QUIT command from the TRANSACTION state,
  547.    the POP3 session enters the UPDATE state.  (Note that if the client
  548.    issues the QUIT command from the AUTHORIZATION state, the POP3
  549.    session terminates but does NOT enter the UPDATE state.)
  550.  
  551.    If a session terminates for some reason other than a client-issued
  552.    QUIT command, the POP3 session does NOT enter the UPDATE state and
  553.    MUST not remove any messages from the maildrop.
  554.  
  555.       QUIT
  556.  
  557.          Arguments: none
  558.  
  559.  
  560.  
  561.  
  562. Myers & Rose                                                   [Page 10]
  563.  
  564. RFC 1725                          POP3                     November 1994
  565.  
  566.  
  567.          Restrictions: none
  568.  
  569.          Discussion:
  570.              The POP3 server removes all messages marked as deleted from
  571.              the maildrop.  It then releases any exclusive-access lock
  572.              on the maildrop and replies as to the status of these
  573.              operations.  The TCP connection is then closed.
  574.  
  575.          Possible Responses:
  576.              +OK
  577.  
  578.          Examples:
  579.              C: QUIT
  580.              S: +OK dewey POP3 server signing off (maildrop empty)
  581.                 ...
  582.              C: QUIT
  583.              S: +OK dewey POP3 server signing off (2 messages left)
  584.                 ...
  585.  
  586. 7. Optional POP3 Commands
  587.  
  588.    The POP3 commands discussed above must be supported by all minimal
  589.    implementations of POP3 servers.
  590.  
  591.    The optional POP3 commands described below permit a POP3 client
  592.    greater freedom in message handling, while preserving a simple POP3
  593.    server implementation.
  594.  
  595.       NOTE: This memo STRONGLY encourages implementations to support
  596.       these commands in lieu of developing augmented drop and scan
  597.       listings.  In short, the philosophy of this memo is to put
  598.       intelligence in the part of the POP3 client and not the POP3
  599.       server.
  600.  
  601.       TOP msg n
  602.  
  603.          Arguments:
  604.              a message-number (required) which may NOT refer to to a
  605.              message marked as deleted, and a non-negative number
  606.              (required)
  607.  
  608.          Restrictions:
  609.              may only be given in the TRANSACTION state
  610.  
  611.          Discussion:
  612.              If the POP3 server issues a positive response, then the
  613.              response given is multi-line.  After the initial +OK, the
  614.              POP3 server sends the headers of the message, the blank
  615.  
  616.  
  617.  
  618. Myers & Rose                                                   [Page 11]
  619.  
  620. RFC 1725                          POP3                     November 1994
  621.  
  622.  
  623.              line separating the headers from the body, and then the
  624.              number of lines indicated message's body, being careful to
  625.              byte-stuff the termination character (as with all multi-
  626.              line responses).
  627.  
  628.              Note that if the number of lines requested by the POP3
  629.              client is greater than than the number of lines in the
  630.              body, then the POP3 server sends the entire message.
  631.  
  632.          Possible Responses:
  633.              +OK top of message follows
  634.              -ERR no such message
  635.  
  636.          Examples:
  637.              C: TOP 1 10
  638.              S: +OK
  639.              S: <the POP3 server sends the headers of the
  640.                 message, a blank line, and the first 10 lines
  641.                 of the body of the message>
  642.              S: .
  643.                 ...
  644.              C: TOP 100 3
  645.              S: -ERR no such message
  646.  
  647.       UIDL [msg]
  648.  
  649.       Arguments:
  650.           a message-number (optionally)  If a message-number is given,
  651.           it may NOT refer to a message marked as deleted.
  652.  
  653.       Restrictions:
  654.           may only be given in the TRANSACTION state.
  655.  
  656.       Discussion:
  657.           If an argument was given and the POP3 server issues a positive
  658.           response with a line containing information for that message.
  659.           This line is called a "unique-id listing" for that message.
  660.  
  661.           If no argument was given and the POP3 server issues a positive
  662.           response, then the response given is multi-line.  After the
  663.           initial +OK, for each message in the maildrop, the POP3 server
  664.           responds with a line containing information for that message.
  665.           This line is called a "unique-id listing" for that message.
  666.  
  667.           In order to simplify parsing, all POP3 servers are required to
  668.           use a certain format for unique-id listings.  A unique-id
  669.           listing consists of the message-number of the message,
  670.           followed by a single space and the unique-id of the message.
  671.  
  672.  
  673.  
  674. Myers & Rose                                                   [Page 12]
  675.  
  676. RFC 1725                          POP3                     November 1994
  677.  
  678.  
  679.           No information follows the unique-id in the unique-id listing.
  680.  
  681.           The unique-id of a message is an arbitrary server-determined
  682.           string, consisting of characters in the range 0x21 to 0x7E,
  683.           which uniquely identifies a message within a maildrop and
  684.           which persists across sessions. The server should never reuse
  685.           an unique-id in a given maildrop, for as long as the entity
  686.           using the unique-id exists.
  687.  
  688.           Note that messages marked as deleted are not listed.
  689.  
  690.       Possible Responses:
  691.           +OK unique-id listing follows
  692.           -ERR no such message
  693.  
  694.       Examples:
  695.           C: UIDL
  696.           S: +OK
  697.           S: 1 whqtswO00WBw418f9t5JxYwZ
  698.           S: 2 QhdPYR:00WBw1Ph7x7
  699.           S: .
  700.              ...
  701.           C: UIDL 2
  702.           S: +OK 2 QhdPYR:00WBw1Ph7x7
  703.              ...
  704.           C: UIDL 3
  705.           S: -ERR no such message, only 2 messages in maildrop
  706.  
  707.       APOP name digest
  708.  
  709.          Arguments:
  710.              a string identifying a mailbox and a MD5 digest string
  711.              (both required)
  712.  
  713.          Restrictions:
  714.              may only be given in the AUTHORIZATION state after the POP3
  715.              greeting
  716.  
  717.          Discussion:
  718.              Normally, each POP3 session starts with a USER/PASS
  719.              exchange.  This results in a server/user-id specific
  720.              password being sent in the clear on the network.  For
  721.              intermittent use of POP3, this may not introduce a sizable
  722.              risk.  However, many POP3 client implementations connect to
  723.              the POP3 server on a regular basis -- to check for new
  724.              mail.  Further the interval of session initiation may be on
  725.              the order of five minutes.  Hence, the risk of password
  726.              capture is greatly enhanced.
  727.  
  728.  
  729.  
  730. Myers & Rose                                                   [Page 13]
  731.  
  732. RFC 1725                          POP3                     November 1994
  733.  
  734.  
  735.              An alternate method of authentication is required which
  736.              provides for both origin authentication and replay
  737.              protection, but which does not involve sending a password
  738.              in the clear over the network.  The APOP command provides
  739.              this functionality.
  740.  
  741.              A POP3 server which implements the APOP command will
  742.              include a timestamp in its banner greeting.  The syntax of
  743.              the timestamp corresponds to the `msg-id' in [RFC822], and
  744.              MUST be different each time the POP3 server issues a banner
  745.              greeting.  For example, on a UNIX implementation in which a
  746.              separate UNIX process is used for each instance of a POP3
  747.              server, the syntax of the timestamp might be:
  748.  
  749.                 <process-ID.clock@hostname>
  750.  
  751.              where `process-ID' is the decimal value of the process's
  752.              PID, clock is the decimal value of the system clock, and
  753.              hostname is the fully-qualified domain-name corresponding
  754.              to the host where the POP3 server is running.
  755.  
  756.              The POP3 client makes note of this timestamp, and then
  757.              issues the APOP command.  The `name' parameter has
  758.              identical semantics to the `name' parameter of the USER
  759.              command. The `digest' parameter is calculated by applying
  760.              the MD5 algorithm [RFC1321] to a string consisting of the
  761.              timestamp (including angle-brackets) followed by a shared
  762.              secret.  This shared secret is a string known only to the
  763.              POP3 client and server.  Great care should be taken to
  764.              prevent unauthorized disclosure of the secret, as knowledge
  765.              of the secret will allow any entity to successfully
  766.              masquerade as the named user.  The `digest' parameter
  767.              itself is a 16-octet value which is sent in hexadecimal
  768.              format, using lower-case ASCII characters.
  769.  
  770.              When the POP3 server receives the APOP command, it verifies
  771.              the digest provided.  If the digest is correct, the POP3
  772.              server issues a positive response, and the POP3 session
  773.              enters the TRANSACTION state.  Otherwise, a negative
  774.              response is issued and the POP3 session remains in the
  775.              AUTHORIZATION state.
  776.  
  777.              Note that as the length of the shared secret increases, so
  778.              does the difficulty of deriving it.  As such, shared
  779.              secrets should be long strings (considerably longer than
  780.              the 8-character example shown below).
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Myers & Rose                                                   [Page 14]
  787.  
  788. RFC 1725                          POP3                     November 1994
  789.  
  790.  
  791.          Possible Responses:
  792.              +OK maildrop locked and ready
  793.              -ERR permission denied
  794.  
  795.          Examples:
  796.              S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
  797.              C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
  798.              S: +OK maildrop has 1 message (369 octets)
  799.  
  800.              In this example, the shared  secret  is  the  string  `tan-
  801.              staaf'.  Hence, the MD5 algorithm is applied to the string
  802.  
  803.                 <1896.697170952@dbc.mtview.ca.us>tanstaaf
  804.  
  805.              which produces a digest value of
  806.  
  807.                 c4c9334bac560ecc979e58001b3e22fb
  808.  
  809. 8. POP3 Command Summary
  810.  
  811.    Minimal POP3 Commands:
  812.  
  813.       USER name               valid in the AUTHORIZATION state
  814.       PASS string
  815.       QUIT
  816.  
  817.       STAT                    valid in the TRANSACTION state
  818.       LIST [msg]
  819.       RETR msg
  820.       DELE msg
  821.       NOOP
  822.       RSET
  823.  
  824.       QUIT                    valid in the UPDATE state
  825.  
  826.    Optional POP3 Commands:
  827.  
  828.       APOP name digest        valid in the AUTHORIZATION state
  829.  
  830.       TOP msg n               valid in the TRANSACTION state
  831.       UIDL [msg]
  832.  
  833.    POP3 Replies:
  834.  
  835.       +OK
  836.       -ERR
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Myers & Rose                                                   [Page 15]
  843.  
  844. RFC 1725                          POP3                     November 1994
  845.  
  846.  
  847.    Note that with the exception of the STAT, LIST, and UIDL commands,
  848.    the reply given by the POP3 server to any command is significant only
  849.    to "+OK" and "-ERR".  Any text occurring after this reply may be
  850.    ignored by the client.
  851.  
  852. 9. Example POP3 Session
  853.  
  854.    S: <wait for connection on TCP port 110>
  855.    C: <open connection>
  856.    S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
  857.    C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
  858.    S:    +OK mrose's maildrop has 2 messages (320 octets)
  859.    C:    STAT
  860.    S:    +OK 2 320
  861.    C:    LIST
  862.    S:    +OK 2 messages (320 octets)
  863.    S:    1 120
  864.    S:    2 200
  865.    S:    .
  866.    C:    RETR 1
  867.    S:    +OK 120 octets
  868.    S:    <the POP3 server sends message 1>
  869.    S:    .
  870.    C:    DELE 1
  871.    S:    +OK message 1 deleted
  872.    C:    RETR 2
  873.    S:    +OK 200 octets
  874.    S:    <the POP3 server sends message 2>
  875.    S:    .
  876.    C:    DELE 2
  877.    S:    +OK message 2 deleted
  878.    C:    QUIT
  879.    S:    +OK dewey POP3 server signing off (maildrop empty)
  880.    C:  <close connection>
  881.    S:  <wait for next connection>
  882.  
  883. 10. Message Format
  884.  
  885.    All messages transmitted during a POP3 session are assumed to conform
  886.    to the standard for the format of Internet text messages [RFC822].
  887.  
  888.    It is important to note that the octet count for a message on the
  889.    server host may differ from the octet count assigned to that message
  890.    due to local conventions for designating end-of-line.  Usually,
  891.    during the AUTHORIZATION state of the POP3 session, the POP3 server
  892.    can calculate the size of each message in octets when it opens the
  893.    maildrop.  For example, if the POP3 server host internally represents
  894.    end-of-line as a single character, then the POP3 server simply counts
  895.  
  896.  
  897.  
  898. Myers & Rose                                                   [Page 16]
  899.  
  900. RFC 1725                          POP3                     November 1994
  901.  
  902.  
  903.    each occurrence of this character in a message as two octets.  Note
  904.    that lines in the message which start with the termination octet need
  905.    not be counted twice, since the POP3 client will remove all byte-
  906.    stuffed termination characters when it receives a multi-line
  907.    response.
  908.  
  909. 11. References
  910.  
  911.    [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
  912.        821, USC/Information Sciences Institute, August 1982.
  913.  
  914.    [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
  915.        Messages", STD 11, RFC 822, University of Delaware, August 1982.
  916.  
  917.    [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321,
  918.        MIT Laboratory for Computer Science, April, 1992.
  919.  
  920. 12. Security Considerations
  921.  
  922.    It is conjectured that use of the APOP command provides origin
  923.    identification and replay protection for a POP3 session.
  924.    Accordingly, a POP3 server which implements both the PASS and APOP
  925.    commands must not allow both methods of access for a given user; that
  926.    is, for a given "USER name" either the PASS or APOP command is
  927.    allowed, but not both.
  928.  
  929.    Further, note that as the length of the shared secret increases, so
  930.    does the difficulty of deriving it.
  931.  
  932.    Servers that answer -ERR to the USER command are giving potential
  933.    attackers clues about which names are valid
  934.  
  935.    Use of the PASS command sends passwords in the clear over the
  936.    network.
  937.  
  938.    Use of the RETR and TOP commands sends mail in the clear over the
  939.    network.
  940.  
  941.    Otherwise, security issues are not discussed in this memo.
  942.  
  943. 13. Acknowledgements
  944.  
  945.    The POP family has a long and checkered history.  Although primarily
  946.    a minor revision to RFC 1460, POP3 is based on the ideas presented in
  947.    RFCs 918, 937, and 1081.
  948.  
  949.    In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
  950.    provided significant comments on the APOP command.
  951.  
  952.  
  953.  
  954. Myers & Rose                                                   [Page 17]
  955.  
  956. RFC 1725                          POP3                     November 1994
  957.  
  958.  
  959. 14. Authors' Addresses
  960.  
  961.    John G. Myers
  962.    Carnegie-Mellon University
  963.    5000 Forbes Ave
  964.    Pittsburgh, PA 15213
  965.  
  966.    EMail: jgm+@cmu.edu
  967.  
  968.  
  969.    Marshall T. Rose
  970.    Dover Beach Consulting, Inc.
  971.    420 Whisman Court
  972.    Mountain View, CA  94043-2186
  973.  
  974.    EMail: mrose@dbc.mtview.ca.us
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Myers & Rose                                                   [Page 18]
  1011.  
  1012.