doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc1939.txt b/doc/rfc/rfc1939.txt
new file mode 100644
index 0000000..b11350e
--- /dev/null
+++ b/doc/rfc/rfc1939.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 1939                               Carnegie Mellon
+STD: 53                                                          M. Rose
+Obsoletes: 1725                             Dover Beach Consulting, Inc.
+Category: Standards Track                                       May 1996
+
+
+                    Post Office Protocol - Version 3
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Table of Contents
+
+   1. Introduction ................................................    2
+   2. A Short Digression ..........................................    2
+   3. Basic Operation .............................................    3
+   4. The AUTHORIZATION State .....................................    4
+      QUIT Command ................................................    5
+   5. The TRANSACTION State .......................................    5
+      STAT Command ................................................    6
+      LIST Command ................................................    6
+      RETR Command ................................................    8
+      DELE Command ................................................    8
+      NOOP Command ................................................    9
+      RSET Command ................................................    9
+   6. The UPDATE State ............................................   10
+      QUIT Command ................................................   10
+   7. Optional POP3 Commands ......................................   11
+      TOP Command .................................................   11
+      UIDL Command ................................................   12
+      USER Command ................................................   13
+      PASS Command ................................................   14
+      APOP Command ................................................   15
+   8. Scaling and Operational Considerations ......................   16
+   9. POP3 Command Summary ........................................   18
+   10. Example POP3 Session .......................................   19
+   11. Message Format .............................................   19
+   12. References .................................................   20
+   13. Security Considerations ....................................   20
+   14. Acknowledgements ...........................................   20
+   15. Authors' Addresses .........................................   21
+   Appendix A. Differences from RFC 1725 ..........................   22
+
+
+
+Myers & Rose                Standards Track                     [Page 1]
+
+RFC 1939                          POP3                          May 1996
+
+
+   Appendix B. Command Index ......................................   23
+
+1. Introduction
+
+   On certain types of smaller nodes in the Internet it is often
+   impractical to maintain a message transport system (MTS).  For
+   example, a workstation may not have sufficient resources (cycles,
+   disk space) in order to permit a SMTP server [RFC821] and associated
+   local mail delivery system to be kept resident and continuously
+   running.  Similarly, it may be expensive (or impossible) to keep a
+   personal computer interconnected to an IP-style network for long
+   amounts of time (the node is lacking the resource known as
+   "connectivity").
+
+   Despite this, it is often very useful to be able to manage mail on
+   these smaller nodes, and they often support a user agent (UA) to aid
+   the tasks of mail handling.  To solve this problem, a node which can
+   support an MTS entity offers a maildrop service to these less endowed
+   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
+   permit a workstation to dynamically access a maildrop on a server
+   host in a useful fashion.  Usually, this means that the POP3 protocol
+   is used to allow a workstation to retrieve mail that the server is
+   holding for it.
+
+   POP3 is not intended to provide extensive manipulation operations of
+   mail on the server; normally, mail is downloaded and then deleted.  A
+   more advanced (and complex) protocol, IMAP4, is discussed in
+   [RFC1730].
+
+   For the remainder of this memo, the term "client host" refers to a
+   host making use of the POP3 service, while the term "server host"
+   refers to a host which offers the POP3 service.
+
+2. A Short Digression
+
+   This memo does not specify how a client host enters mail into the
+   transport system, although a method consistent with the philosophy of
+   this memo is presented here:
+
+      When the user agent on a client host wishes to enter a message
+      into the transport system, it establishes an SMTP connection to
+      its relay host and sends all mail to it.  This relay host could
+      be, but need not be, the POP3 server host for the client host.  Of
+      course, the relay host must accept mail for delivery to arbitrary
+      recipient addresses, that functionality is not required of all
+      SMTP servers.
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 2]
+
+RFC 1939                          POP3                          May 1996
+
+
+3. Basic Operation
+
+   Initially, the server host starts the POP3 service by listening on
+   TCP port 110.  When a client host wishes to make use of the service,
+   it establishes a TCP connection with the server host.  When the
+   connection is established, the POP3 server sends a greeting.  The
+   client and POP3 server then exchange commands and responses
+   (respectively) until the connection is closed or aborted.
+
+   Commands in the POP3 consist of a case-insensitive keyword, possibly
+   followed by one or more arguments.  All commands are terminated by a
+   CRLF pair.  Keywords and arguments consist of printable ASCII
+   characters.  Keywords and arguments are each separated by a single
+   SPACE character.  Keywords are three or four characters long. Each
+   argument may be up to 40 characters long.
+
+   Responses in the POP3 consist of a status indicator and a keyword
+   possibly followed by additional information.  All responses are
+   terminated by a CRLF pair.  Responses may be up to 512 characters
+   long, including the terminating CRLF.  There are currently two status
+   indicators: positive ("+OK") and negative ("-ERR").  Servers MUST
+   send the "+OK" and "-ERR" in upper case.
+
+   Responses to certain commands are multi-line.  In these cases, which
+   are clearly indicated below, after sending the first line of the
+   response and a CRLF, any additional lines are sent, each terminated
+   by a CRLF pair.  When all lines of the response have been sent, a
+   final line is sent, consisting of a termination octet (decimal code
+   046, ".") and a CRLF pair.  If any line of the multi-line response
+   begins with the termination octet, the line is "byte-stuffed" by
+   pre-pending the termination octet to that line of the response.
+   Hence a multi-line response is terminated with the five octets
+   "CRLF.CRLF".  When examining a multi-line response, the client checks
+   to see if the line begins with the termination octet.  If so and if
+   octets other than CRLF follow, the first octet of the line (the
+   termination octet) is stripped away.  If so and if CRLF immediately
+   follows the termination character, then the response from the POP
+   server is ended and the line containing ".CRLF" is not considered
+   part of the multi-line response.
+
+   A POP3 session progresses through a number of states during its
+   lifetime.  Once the TCP connection has been opened and the POP3
+   server has sent the greeting, the session enters the AUTHORIZATION
+   state.  In this state, the client must identify itself to the POP3
+   server.  Once the client has successfully done this, the server
+   acquires resources associated with the client's maildrop, and the
+   session enters the TRANSACTION state.  In this state, the client
+   requests actions on the part of the POP3 server.  When the client has
+
+
+
+Myers & Rose                Standards Track                     [Page 3]
+
+RFC 1939                          POP3                          May 1996
+
+
+   issued the QUIT command, the session enters the UPDATE state.  In
+   this state, the POP3 server releases any resources acquired during
+   the TRANSACTION state and says goodbye.  The TCP connection is then
+   closed.
+
+   A server MUST respond to an unrecognized, unimplemented, or
+   syntactically invalid command by responding with a negative status
+   indicator.  A server MUST respond to a command issued when the
+   session is in an incorrect state by responding with a negative status
+   indicator.  There is no general method for a client to distinguish
+   between a server which does not implement an optional command and a
+   server which is unwilling or unable to process the command.
+
+   A POP3 server MAY have an inactivity autologout timer.  Such a timer
+   MUST be of at least 10 minutes' duration.  The receipt of any command
+   from the client during that interval should suffice to reset the
+   autologout timer.  When the timer expires, the session does NOT enter
+   the UPDATE state--the server should close the TCP connection without
+   removing any messages or sending any response to the client.
+
+4. The AUTHORIZATION State
+
+   Once the TCP connection has been opened by a POP3 client, the POP3
+   server issues a one line greeting.  This can be any positive
+   response.  An example might be:
+
+      S:  +OK POP3 server ready
+
+   The POP3 session is now in the AUTHORIZATION state.  The client must
+   now identify and authenticate itself to the POP3 server.  Two
+   possible mechanisms for doing this are described in this document,
+   the USER and PASS command combination and the APOP command.  Both
+   mechanisms are described later in this document.  Additional
+   authentication mechanisms are described in [RFC1734].  While there is
+   no single authentication mechanism that is required of all POP3
+   servers, a POP3 server must of course support at least one
+   authentication mechanism.
+
+   Once the POP3 server has determined through the use of any
+   authentication command that the client should be given access to the
+   appropriate maildrop, the POP3 server then acquires an exclusive-
+   access lock on the maildrop, as necessary to prevent messages from
+   being modified or removed before the session enters the UPDATE state.
+   If the lock is successfully acquired, the POP3 server responds with a
+   positive status indicator.  The POP3 session now enters the
+   TRANSACTION state, with no messages marked as deleted.  If the
+   maildrop cannot be opened for some reason (for example, a lock can
+   not be acquired, the client is denied access to the appropriate
+
+
+
+Myers & Rose                Standards Track                     [Page 4]
+
+RFC 1939                          POP3                          May 1996
+
+
+   maildrop, or the maildrop cannot be parsed), the POP3 server responds
+   with a negative status indicator.  (If a lock was acquired but the
+   POP3 server intends to respond with a negative status indicator, the
+   POP3 server must release the lock prior to rejecting the command.)
+   After returning a negative status indicator, the server may close the
+   connection.  If the server does not close the connection, the client
+   may either issue a new authentication command and start again, or the
+   client may issue the QUIT command.
+
+   After the POP3 server has opened the maildrop, it assigns a message-
+   number to each message, and notes the size of each message in octets.
+   The first message in the maildrop is assigned a message-number of
+   "1", the second is assigned "2", and so on, so that the nth message
+   in a maildrop is assigned a message-number of "n".  In POP3 commands
+   and responses, all message-numbers and message sizes are expressed in
+   base-10 (i.e., decimal).
+
+   Here is the summary for the QUIT command when used in the
+   AUTHORIZATION state:
+
+      QUIT
+
+         Arguments: none
+
+         Restrictions: none
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: QUIT
+             S: +OK dewey POP3 server signing off
+
+5. The TRANSACTION State
+
+   Once the client has successfully identified itself to the POP3 server
+   and the POP3 server has locked and opened the appropriate maildrop,
+   the POP3 session is now in the TRANSACTION state.  The client may now
+   issue any of the following POP3 commands repeatedly.  After each
+   command, the POP3 server issues a response.  Eventually, the client
+   issues the QUIT command and the POP3 session enters the UPDATE state.
+
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 5]
+
+RFC 1939                          POP3                          May 1996
+
+
+   Here are the POP3 commands valid in the TRANSACTION state:
+
+      STAT
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             The POP3 server issues a positive response with a line
+             containing information for the maildrop.  This line is
+             called a "drop listing" for that maildrop.
+
+             In order to simplify parsing, all POP3 servers are
+             required to use a certain format for drop listings.  The
+             positive response consists of "+OK" followed by a single
+             space, the number of messages in the maildrop, a single
+             space, and the size of the maildrop in octets.  This memo
+             makes no requirement on what follows the maildrop size.
+             Minimal implementations should just end that line of the
+             response with a CRLF pair.  More advanced implementations
+             may include other information.
+
+                NOTE: This memo STRONGLY discourages implementations
+                from supplying additional information in the drop
+                listing.  Other, optional, facilities are discussed
+                later on which permit the client to parse the messages
+                in the maildrop.
+
+             Note that messages marked as deleted are not counted in
+             either total.
+
+         Possible Responses:
+             +OK nn mm
+
+         Examples:
+             C: STAT
+             S: +OK 2 320
+
+
+      LIST [msg]
+
+         Arguments:
+             a message-number (optional), which, if present, may NOT
+             refer to a message marked as deleted
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 6]
+
+RFC 1939                          POP3                          May 1996
+
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If an argument was given and the POP3 server issues a
+             positive response with a line containing information for
+             that message.  This line is called a "scan listing" for
+             that message.
+
+             If no argument was given and the POP3 server issues a
+             positive response, then the response given is multi-line.
+             After the initial +OK, for each message in the maildrop,
+             the POP3 server responds with a line containing
+             information for that message.  This line is also called a
+             "scan listing" for that message.  If there are no
+             messages in the maildrop, then the POP3 server responds
+             with no scan listings--it issues a positive response
+             followed by a line containing a termination octet and a
+             CRLF pair.
+
+             In order to simplify parsing, all POP3 servers are
+             required to use a certain format for scan listings.  A
+             scan listing consists of the message-number of the
+             message, followed by a single space and the exact size of
+             the message in octets.  Methods for calculating the exact
+             size of the message are described in the "Message Format"
+             section below.  This memo makes no requirement on what
+             follows the message size in the scan listing.  Minimal
+             implementations should just end that line of the response
+             with a CRLF pair.  More advanced implementations may
+             include other information, as parsed from the message.
+
+                NOTE: This memo STRONGLY discourages implementations
+                from supplying additional information in the scan
+                listing.  Other, optional, facilities are discussed
+                later on which permit the client to parse the messages
+                in the maildrop.
+
+             Note that messages marked as deleted are not listed.
+
+         Possible Responses:
+             +OK scan listing follows
+             -ERR no such message
+
+         Examples:
+             C: LIST
+             S: +OK 2 messages (320 octets)
+             S: 1 120
+
+
+
+Myers & Rose                Standards Track                     [Page 7]
+
+RFC 1939                          POP3                          May 1996
+
+
+             S: 2 200
+             S: .
+               ...
+             C: LIST 2
+             S: +OK 2 200
+               ...
+             C: LIST 3
+             S: -ERR no such message, only 2 messages in maildrop
+
+
+      RETR msg
+
+         Arguments:
+             a message-number (required) which may NOT refer to a
+             message marked as deleted
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If the POP3 server issues a positive response, then the
+             response given is multi-line.  After the initial +OK, the
+             POP3 server sends the message corresponding to the given
+             message-number, being careful to byte-stuff the termination
+             character (as with all multi-line responses).
+
+         Possible Responses:
+             +OK message follows
+             -ERR no such message
+
+         Examples:
+             C: RETR 1
+             S: +OK 120 octets
+             S: <the POP3 server sends the entire message here>
+             S: .
+
+
+      DELE msg
+
+         Arguments:
+             a message-number (required) which may NOT refer to a
+             message marked as deleted
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 8]
+
+RFC 1939                          POP3                          May 1996
+
+
+         Discussion:
+             The POP3 server marks the message as deleted.  Any future
+             reference to the message-number associated with the message
+             in a POP3 command generates an error.  The POP3 server does
+             not actually delete the message until the POP3 session
+             enters the UPDATE state.
+
+         Possible Responses:
+             +OK message deleted
+             -ERR no such message
+
+         Examples:
+             C: DELE 1
+             S: +OK message 1 deleted
+                ...
+             C: DELE 2
+             S: -ERR message 2 already deleted
+
+
+      NOOP
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             The POP3 server does nothing, it merely replies with a
+             positive response.
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: NOOP
+             S: +OK
+
+
+      RSET
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If any messages have been marked as deleted by the POP3
+             server, they are unmarked.  The POP3 server then replies
+
+
+
+Myers & Rose                Standards Track                     [Page 9]
+
+RFC 1939                          POP3                          May 1996
+
+
+             with a positive response.
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: RSET
+             S: +OK maildrop has 2 messages (320 octets)
+
+6. The UPDATE State
+
+   When the client issues the QUIT command from the TRANSACTION state,
+   the POP3 session enters the UPDATE state.  (Note that if the client
+   issues the QUIT command from the AUTHORIZATION state, the POP3
+   session terminates but does NOT enter the UPDATE state.)
+
+   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.
+
+      QUIT
+
+         Arguments: none
+
+         Restrictions: none
+
+         Discussion:
+             The POP3 server removes all messages marked as deleted
+             from the maildrop and replies as to the status of this
+             operation.  If there is an error, such as a resource
+             shortage, encountered while removing messages, the
+             maildrop may result in having some or none of the messages
+             marked as deleted be removed.  In no case may the server
+             remove any messages not marked as deleted.
+
+             Whether the removal was successful or not, the server
+             then releases any exclusive-access lock on the maildrop
+             and closes the TCP connection.
+
+         Possible Responses:
+             +OK
+             -ERR some deleted messages not removed
+
+         Examples:
+             C: QUIT
+             S: +OK dewey POP3 server signing off (maildrop empty)
+                ...
+             C: QUIT
+
+
+
+Myers & Rose                Standards Track                    [Page 10]
+
+RFC 1939                          POP3                          May 1996
+
+
+             S: +OK dewey POP3 server signing off (2 messages left)
+                ...
+
+7. Optional POP3 Commands
+
+   The POP3 commands discussed above must be supported by all minimal
+   implementations of POP3 servers.
+
+   The optional POP3 commands described below permit a POP3 client
+   greater freedom in message handling, while preserving a simple POP3
+   server implementation.
+
+      NOTE: This memo STRONGLY encourages implementations to support
+      these commands in lieu of developing augmented drop and scan
+      listings.  In short, the philosophy of this memo is to put
+      intelligence in the part of the POP3 client and not the POP3
+      server.
+
+      TOP msg n
+
+         Arguments:
+             a message-number (required) which may NOT refer to to a
+             message marked as deleted, and a non-negative number
+             of lines (required)
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If the POP3 server issues a positive response, then the
+             response given is multi-line.  After the initial +OK, the
+             POP3 server sends the headers of the message, the blank
+             line separating the headers from the body, and then the
+             number of lines of the indicated message's body, being
+             careful to byte-stuff the termination character (as with
+             all multi-line responses).
+
+             Note that if the number of lines requested by the POP3
+             client is greater than than the number of lines in the
+             body, then the POP3 server sends the entire message.
+
+         Possible Responses:
+             +OK top of message follows
+             -ERR no such message
+
+         Examples:
+             C: TOP 1 10
+             S: +OK
+
+
+
+Myers & Rose                Standards Track                    [Page 11]
+
+RFC 1939                          POP3                          May 1996
+
+
+             S: <the POP3 server sends the headers of the
+                message, a blank line, and the first 10 lines
+                of the body of the message>
+             S: .
+                ...
+             C: TOP 100 3
+             S: -ERR no such message
+
+
+      UIDL [msg]
+
+      Arguments:
+          a message-number (optional), which, if present, may NOT
+          refer to a message marked as deleted
+
+      Restrictions:
+          may only be given in the TRANSACTION state.
+
+      Discussion:
+          If an argument was given and the POP3 server issues a positive
+          response with a line containing information for that message.
+          This line is called a "unique-id listing" for that message.
+
+          If no argument was given and the POP3 server issues a positive
+          response, then the response given is multi-line.  After the
+          initial +OK, for each message in the maildrop, the POP3 server
+          responds with a line containing information for that message.
+          This line is called a "unique-id listing" for that message.
+
+          In order to simplify parsing, all POP3 servers are required to
+          use a certain format for unique-id listings.  A unique-id
+          listing consists of the message-number of the message,
+          followed by a single space and the unique-id of the message.
+          No information follows the unique-id in the unique-id listing.
+
+          The unique-id of a message is an arbitrary server-determined
+          string, consisting of one to 70 characters in the range 0x21
+          to 0x7E, which uniquely identifies a message within a
+          maildrop and which persists across sessions.  This
+          persistence is required even if a session ends without
+          entering the UPDATE state.  The server should never reuse an
+          unique-id in a given maildrop, for as long as the entity
+          using the unique-id exists.
+
+          Note that messages marked as deleted are not listed.
+
+          While it is generally preferable for server implementations
+          to store arbitrarily assigned unique-ids in the maildrop,
+
+
+
+Myers & Rose                Standards Track                    [Page 12]
+
+RFC 1939                          POP3                          May 1996
+
+
+          this specification is intended to permit unique-ids to be
+          calculated as a hash of the message.  Clients should be able
+          to handle a situation where two identical copies of a
+          message in a maildrop have the same unique-id.
+
+      Possible Responses:
+          +OK unique-id listing follows
+          -ERR no such message
+
+      Examples:
+          C: UIDL
+          S: +OK
+          S: 1 whqtswO00WBw418f9t5JxYwZ
+          S: 2 QhdPYR:00WBw1Ph7x7
+          S: .
+             ...
+          C: UIDL 2
+          S: +OK 2 QhdPYR:00WBw1Ph7x7
+             ...
+          C: UIDL 3
+          S: -ERR no such message, only 2 messages in maildrop
+
+
+      USER name
+
+         Arguments:
+             a string identifying a mailbox (required), which is of
+             significance ONLY to the server
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state after the POP3
+             greeting or after an unsuccessful USER or PASS command
+
+         Discussion:
+             To authenticate using the USER and PASS command
+             combination, the client must first issue the USER
+             command.  If the POP3 server responds with a positive
+             status indicator ("+OK"), then the client may issue
+             either the PASS command to complete the authentication,
+             or the QUIT command to terminate the POP3 session.  If
+             the POP3 server responds with a negative status indicator
+             ("-ERR") to the USER command, then the client may either
+             issue a new authentication command or may issue the QUIT
+             command.
+
+             The server may return a positive response even though no
+             such mailbox exists.  The server may return a negative
+             response if mailbox exists, but does not permit plaintext
+
+
+
+Myers & Rose                Standards Track                    [Page 13]
+
+RFC 1939                          POP3                          May 1996
+
+
+             password authentication.
+
+         Possible Responses:
+             +OK name is a valid mailbox
+             -ERR never heard of mailbox name
+
+         Examples:
+             C: USER frated
+             S: -ERR sorry, no mailbox for frated here
+                ...
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+
+
+      PASS string
+
+         Arguments:
+             a server/mailbox-specific password (required)
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state immediately
+             after a successful USER command
+
+         Discussion:
+             When the client issues the PASS command, the POP3 server
+             uses the argument pair from the USER and PASS commands to
+             determine if the client should be given access to the
+             appropriate maildrop.
+
+             Since the PASS command has exactly one argument, a POP3
+             server may treat spaces in the argument as part of the
+             password, instead of as argument separators.
+
+         Possible Responses:
+             +OK maildrop locked and ready
+             -ERR invalid password
+             -ERR unable to lock maildrop
+
+         Examples:
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+             C: PASS secret
+             S: -ERR maildrop already locked
+               ...
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+             C: PASS secret
+             S: +OK mrose's maildrop has 2 messages (320 octets)
+
+
+
+Myers & Rose                Standards Track                    [Page 14]
+
+RFC 1939                          POP3                          May 1996
+
+
+      APOP name digest
+
+         Arguments:
+             a string identifying a mailbox and a MD5 digest string
+             (both required)
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state after the POP3
+             greeting or after an unsuccessful USER or PASS command
+
+         Discussion:
+             Normally, each POP3 session starts with a USER/PASS
+             exchange.  This results in a server/user-id specific
+             password being sent in the clear on the network.  For
+             intermittent use of POP3, this may not introduce a sizable
+             risk.  However, many POP3 client implementations connect to
+             the POP3 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.
+
+             An alternate 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.  The APOP command provides
+             this functionality.
+
+             A POP3 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 [RFC822], and
+             MUST be different each time the POP3 server issues a banner
+             greeting.  For example, on a UNIX implementation in which a
+             separate UNIX process is used for each instance of a POP3
+             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 POP3 server is running.
+
+             The POP3 client makes note of this timestamp, and then
+             issues the APOP command.  The `name' parameter has
+             identical semantics to the `name' parameter of the USER
+             command. The `digest' parameter is calculated by applying
+             the MD5 algorithm [RFC1321] to a string consisting of the
+             timestamp (including angle-brackets) followed by a shared
+
+
+
+Myers & Rose                Standards Track                    [Page 15]
+
+RFC 1939                          POP3                          May 1996
+
+
+             secret.  This shared secret is a string known only to the
+             POP3 client and server.  Great care should be taken to
+             prevent unauthorized disclosure of the secret, as knowledge
+             of the secret will allow any entity to successfully
+             masquerade as the named user.  The `digest' parameter
+             itself is a 16-octet value which is sent in hexadecimal
+             format, using lower-case ASCII characters.
+
+             When the POP3 server receives the APOP command, it verifies
+             the digest provided.  If the digest is correct, the POP3
+             server issues a positive response, and the POP3 session
+             enters the TRANSACTION state.  Otherwise, a negative
+             response is issued and the POP3 session remains in the
+             AUTHORIZATION state.
+
+             Note that as the length of the shared secret increases, so
+             does the difficulty of deriving it.  As such, shared
+             secrets should be long strings (considerably longer than
+             the 8-character example shown below).
+
+         Possible Responses:
+             +OK maildrop locked and ready
+             -ERR permission denied
+
+         Examples:
+             S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
+             S: +OK maildrop has 1 message (369 octets)
+
+             In this example, the shared  secret  is  the  string  `tan-
+             staaf'.  Hence, the MD5 algorithm is applied to the string
+
+                <1896.697170952@dbc.mtview.ca.us>tanstaaf
+
+             which produces a digest value of
+
+                c4c9334bac560ecc979e58001b3e22fb
+
+8. Scaling and Operational Considerations
+
+   Since some of the optional features described above were added to the
+   POP3 protocol, experience has accumulated in using them in large-
+   scale commercial post office operations where most of the users are
+   unrelated to each other.  In these situations and others, users and
+   vendors of POP3 clients have discovered that the combination of using
+   the UIDL command and not issuing the DELE command can provide a weak
+   version of the "maildrop as semi-permanent repository" functionality
+   normally associated with IMAP.  Of course the other capabilities of
+
+
+
+Myers & Rose                Standards Track                    [Page 16]
+
+RFC 1939                          POP3                          May 1996
+
+
+   IMAP, such as polling an existing connection for newly arrived
+   messages and supporting multiple folders on the server, are not
+   present in POP3.
+
+   When these facilities are used in this way by casual users, there has
+   been a tendency for already-read messages to accumulate on the server
+   without bound.  This is clearly an undesirable behavior pattern from
+   the standpoint of the server operator.  This situation is aggravated
+   by the fact that the limited capabilities of the POP3 do not permit
+   efficient handling of maildrops which have hundreds or thousands of
+   messages.
+
+   Consequently, it is recommended that operators of large-scale multi-
+   user servers, especially ones in which the user's only access to the
+   maildrop is via POP3, consider such options as:
+
+   *  Imposing a per-user maildrop storage quota or the like.
+
+      A disadvantage to this option is that accumulation of messages may
+      result in the user's inability to receive new ones into the
+      maildrop.  Sites which choose this option should be sure to inform
+      users of impending or current exhaustion of quota, perhaps by
+      inserting an appropriate message into the user's maildrop.
+
+   *  Enforce a site policy regarding mail retention on the server.
+
+      Sites are free to establish local policy regarding the storage and
+      retention of messages on the server, both read and unread.  For
+      example, a site might delete unread messages from the server after
+      60 days and delete read messages after 7 days.  Such message
+      deletions are outside the scope of the POP3 protocol and are not
+      considered a protocol violation.
+
+      Server operators enforcing message deletion policies should take
+      care to make all users aware of the policies in force.
+
+      Clients must not assume that a site policy will automate message
+      deletions, and should continue to explicitly delete messages using
+      the DELE command when appropriate.
+
+      It should be noted that enforcing site message deletion policies
+      may be confusing to the user community, since their POP3 client
+      may contain configuration options to leave mail on the server
+      which will not in fact be supported by the server.
+
+      One special case of a site policy is that messages may only be
+      downloaded once from the server, and are deleted after this has
+      been accomplished.  This could be implemented in POP3 server
+
+
+
+Myers & Rose                Standards Track                    [Page 17]
+
+RFC 1939                          POP3                          May 1996
+
+
+      software by the following mechanism: "following a POP3 login by a
+      client which was ended by a QUIT, delete all messages downloaded
+      during the session with the RETR command".  It is important not to
+      delete messages in the event of abnormal connection termination
+      (ie, if no QUIT was received from the client) because the client
+      may not have successfully received or stored the messages.
+      Servers implementing a download-and-delete policy may also wish to
+      disable or limit the optional TOP command, since it could be used
+      as an alternate mechanism to download entire messages.
+
+9. POP3 Command Summary
+
+      Minimal POP3 Commands:
+
+         USER name               valid in the AUTHORIZATION state
+         PASS string
+         QUIT
+
+         STAT                    valid in the TRANSACTION state
+         LIST [msg]
+         RETR msg
+         DELE msg
+         NOOP
+         RSET
+         QUIT
+
+      Optional POP3 Commands:
+
+         APOP name digest        valid in the AUTHORIZATION state
+
+         TOP msg n               valid in the TRANSACTION state
+         UIDL [msg]
+
+      POP3 Replies:
+
+         +OK
+         -ERR
+
+      Note that with the exception of the STAT, LIST, and UIDL commands,
+      the reply given by the POP3 server to any command is significant
+      only to "+OK" and "-ERR".  Any text occurring after this reply
+      may be ignored by the client.
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                    [Page 18]
+
+RFC 1939                          POP3                          May 1996
+
+
+10. Example POP3 Session
+
+      S: <wait for connection on TCP port 110>
+      C: <open connection>
+      S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+      C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
+      S:    +OK mrose's maildrop has 2 messages (320 octets)
+      C:    STAT
+      S:    +OK 2 320
+      C:    LIST
+      S:    +OK 2 messages (320 octets)
+      S:    1 120
+      S:    2 200
+      S:    .
+      C:    RETR 1
+      S:    +OK 120 octets
+      S:    <the POP3 server sends message 1>
+      S:    .
+      C:    DELE 1
+      S:    +OK message 1 deleted
+      C:    RETR 2
+      S:    +OK 200 octets
+      S:    <the POP3 server sends message 2>
+      S:    .
+      C:    DELE 2
+      S:    +OK message 2 deleted
+      C:    QUIT
+      S:    +OK dewey POP3 server signing off (maildrop empty)
+      C:  <close connection>
+      S:  <wait for next connection>
+
+11. Message Format
+
+   All messages transmitted during a POP3 session are assumed to conform
+   to the standard for the format of Internet text messages [RFC822].
+
+   It is important to note that the octet count for a message on the
+   server host may differ from the octet count assigned to that message
+   due to local conventions for designating end-of-line.  Usually,
+   during the AUTHORIZATION state of the POP3 session, the POP3 server
+   can calculate the size of each message in octets when it opens the
+   maildrop.  For example, if the POP3 server host internally represents
+   end-of-line as a single character, then the POP3 server simply counts
+   each occurrence of this character in a message as two octets.  Note
+   that lines in the message which start with the termination octet need
+   not (and must not) be counted twice, since the POP3 client will
+   remove all byte-stuffed termination characters when it receives a
+   multi-line response.
+
+
+
+Myers & Rose                Standards Track                    [Page 19]
+
+RFC 1939                          POP3                          May 1996
+
+
+12. References
+
+   [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+       821, USC/Information Sciences Institute, August 1982.
+
+   [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
+       Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+       MIT Laboratory for Computer Science, April 1992.
+
+   [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
+       4", RFC 1730, University of Washington, December 1994.
+
+   [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
+       Carnegie Mellon, December 1994.
+
+13. Security Considerations
+
+   It is conjectured that use of the APOP command provides origin
+   identification and replay protection for a POP3 session.
+   Accordingly, a POP3 server which implements both the PASS and APOP
+   commands should not allow both methods of access for a given user;
+   that is, for a given mailbox name, either the USER/PASS command
+   sequence or the APOP command is allowed, but not both.
+
+   Further, note that as the length of the shared secret increases, so
+   does the difficulty of deriving it.
+
+   Servers that answer -ERR to the USER command are giving potential
+   attackers clues about which names are valid.
+
+   Use of the PASS command sends passwords in the clear over the
+   network.
+
+   Use of the RETR and TOP commands sends mail in the clear over the
+   network.
+
+   Otherwise, security issues are not discussed in this memo.
+
+14. Acknowledgements
+
+   The POP family has a long and checkered history.  Although primarily
+   a minor revision to RFC 1460, POP3 is based on the ideas presented in
+   RFCs 918, 937, and 1081.
+
+   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
+   provided significant comments on the APOP command.
+
+
+
+Myers & Rose                Standards Track                    [Page 20]
+
+RFC 1939                          POP3                          May 1996
+
+
+15. Authors' Addresses
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave
+   Pittsburgh, PA 15213
+
+   EMail: jgm+@cmu.edu
+
+
+   Marshall T. Rose
+   Dover Beach Consulting, Inc.
+   420 Whisman Court
+   Mountain View, CA  94043-2186
+
+   EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                    [Page 21]
+
+RFC 1939                          POP3                          May 1996
+
+
+Appendix A. Differences from RFC 1725
+
+   This memo is a revision to RFC 1725, a Draft Standard.  It makes the
+   following changes from that document:
+
+      - clarifies that command keywords are case insensitive.
+
+      - specifies that servers must send "+OK" and "-ERR" in
+        upper case.
+
+      - specifies that the initial greeting is a positive response,
+        instead of any string which should be a positive response.
+
+      - clarifies behavior for unimplemented commands.
+
+      - makes the USER and PASS commands optional.
+
+      - clarified the set of possible responses to the USER command.
+
+      - reverses the order of the examples in the USER and PASS
+        commands, to reduce confusion.
+
+      - clarifies that the PASS command may only be given immediately
+        after a successful USER command.
+
+      - clarified the persistence requirements of UIDs and added some
+        implementation notes.
+
+      - specifies a UID length limitation of one to 70 octets.
+
+      - specifies a status indicator length limitation
+        of 512 octets, including the CRLF.
+
+      - clarifies that LIST with no arguments on an empty mailbox
+        returns success.
+
+      - adds a reference from the LIST command to the Message Format
+        section
+
+      - clarifies the behavior of QUIT upon failure
+
+      - clarifies the security section to not imply the use of the
+        USER command with the APOP command.
+
+      - adds references to RFCs 1730 and 1734
+
+      - clarifies the method by which a UA may enter mail into the
+        transport system.
+
+
+
+Myers & Rose                Standards Track                    [Page 22]
+
+RFC 1939                          POP3                          May 1996
+
+
+      - clarifies that the second argument to the TOP command is a
+        number of lines.
+
+      - changes the suggestion in the Security Considerations section
+        for a server to not accept both PASS and APOP for a given user
+        from a "must" to a "should".
+
+      - adds a section on scaling and operational considerations
+
+Appendix B. Command Index
+
+       APOP .......................................................   15
+       DELE .......................................................    8
+       LIST .......................................................    6
+       NOOP .......................................................    9
+       PASS .......................................................   14
+       QUIT .......................................................    5
+       QUIT .......................................................   10
+       RETR .......................................................    8
+       RSET .......................................................    9
+       STAT .......................................................    6
+       TOP ........................................................   11
+       UIDL .......................................................   12
+       USER .......................................................   13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                    [Page 23]
+