Add files from ESR's dev directory that weren't under version control

svn path=/trunk/; revision=3881

1 files changed, 1392 insertions, 0 deletions

diff --git a/RFC/rfc937.txt b/RFC/rfc937.txt
new file mode 100644
index 00000000..ae154ea8
--- /dev/null
+++ b/RFC/rfc937.txt
@@ -0,0 +1,1392 @@
+
+
+Network Working Group                                          M. Butler
+Request for Comments: 937                                      J. Postel
+                                                                D. Chase
+                                                           J. Goldberger
+                                                          J. K. Reynolds
+Obsoletes: RFC 918                                                   ISI
+                                                           February 1985
+
+
+                    POST OFFICE PROTOCOL - VERSION 2
+
+
+Status of this Memo
+
+   This RFC suggests a simple method for workstations to dynamically
+   access mail from a mailbox server.  This RFC specifies a proposed
+   protocol for the ARPA-Internet community, and requests discussion and
+   suggestions for improvement.  This memo is a revision of RFC 918.
+   Distribution of this memo is unlimited.
+
+Introduction
+
+   The intent of the Post Office Protocol Version 2 (POP2) is to allow a
+   user's workstation to access mail from a mailbox server.  It is
+   expected that mail will be posted from the workstation to the mailbox
+   server via the Simple Mail Transfer Protocol (SMTP).  For further
+   information see RFC-821 [1] and RFC-822 [2].
+
+   This protocol assumes a reliable data stream such as provided by TCP
+   or any similar protocol.  When TCP is used, the POP2 server listens
+   on port 109 [4].
+
+System Model and Philosophy
+
+   While we view the workstation as an Internet host in the sense that
+   it implements IP, we do not expect the workstation to contain the
+   user's mailbox.  We expect the mailbox to be on a server machine.
+
+   We believe it is important for the mailbox to be on an "always up"
+   machine and that a workstation may be frequently powered down, or
+   otherwise unavailable as an SMTP server.
+
+   POP2 is designed for an environment of workstations and servers on a
+   low-delay, high-throughput, local networks (such as Ethernets).  POP2
+   may be useful in other environments as well, but if the environment
+   is substantially different, a different division of labor between the
+   client and server may be appropriate, and a different protocol
+   required.
+
+   Suppose the user's real name is John Smith, the user's machine is
+   called FIDO, and that the mailbox server is called DOG-HOUSE.  Then
+
+
+
+Butler, et. al.                                                 [Page 1]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   we expect the user's mail to be addressed to JSmith@DOG-HOUSE.ARPA
+   (not JSmith@FIDO.ARPA).
+
+   That is, the destination of the mail is the mailbox on the server
+   machine.  The POP2 protocol and the workstation are merely a
+   mechanism for viewing the messages in the mailbox.
+
+   The user is not tied to any particular workstation for accessing his
+   mail.  The workstation does not appear as any part of the mailbox
+   address.
+
+   This is a very simple protocol.  This is not a user interface.  We
+   expect that there is a program in the workstation that is friendly to
+   the user.  This protocol is not "user friendly".  One basic rule of
+   this protocol is "if anything goes wrong close the connection".
+   Another basic rule is to have few options.
+
+   POP2 does not parse messages in any way.  It does not analyze message
+   headers (Date:, From:, To:, Cc:, or Subject:).  POP2 simply transmits
+   whole messages from a mailbox server to a client workstation.
+
+The Protocol
+
+   The POP2 protocol is a sequence of commands and replies.  The design
+   draws from many previous protocols of the ARPA-Internet community.
+
+      The server must be listening for a connection.  When a connection
+      is opened the server sends a greeting message and waits for
+      commands.  When commands are received the server acts on them and
+      responds with replies.
+
+      The client opens a connection, waits for the greeting, then sends
+      the HELO command with the user name and password arguments to
+      establish authorization to access mailboxes.  The server returns
+      the number of messages in the default mailbox.
+
+      The client may read the default mailbox associated with the user
+      name or may select another mailbox by using the FOLD command.  The
+      server returns the number of messages in the mailbox selected.
+
+      The client begins a message reading transaction with a READ
+      command.  The read command may optionally indicate which message
+      number to read, the default is the current message (incremented
+      when a message is read and set to one when a new folder is
+      selected).  The server returns the number of characters in the
+      message.
+
+
+
+
+Butler, et. al.                                                 [Page 2]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+      The client asks for the content of the message to be sent with the
+      RETR command.  The server sends the message data.
+
+      When all the data has been received the client sends an
+      acknowledgment command.  This is one of ACKS, ACKD, and NACK.
+
+         ACKS means "I've received the message successfully and please
+         keep it in the mailbox".
+
+         ACKD means "I've received the message successfully and please
+         delete it from the mailbox".
+
+         NACK means "I did not receive the message and please keep it in
+         the mailbox".
+
+      In the case of ACKS or ACKD the server increments the current
+      message indicator.  In the case of NACK the current message
+      indicator stays the same.
+
+      In all cases the server returns the number of characters in the
+      (now) current message.
+
+      The client terminates the session with the QUIT command.  The
+      server returns an ok.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                 [Page 3]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   The Normal Scenario
+
+           Client                    Server
+           ------                    ------
+                                Wait for Connection
+      Open Connection  -->
+                           <--  + POP2 Server Ready
+                                Wait for Command
+      HELO Fred Secret -->
+                           <--  #13 messages for you
+                                Wait for Command
+      READ 13          -->   
+                           <--  =537 characters in that message
+                                Wait for Command
+      RETR             -->   
+                           <--  (send the message data)
+                                Wait for Command
+      ACKS             -->   
+                           <--  =0 no more messages
+                                Wait for Command
+      QUIT             -->
+                           <--  + OK
+      Close connection --> <--  Close connection
+                                Wait for Connection (go back to start)
+
+Conventions
+
+   Arguments
+
+      These arguments have system specific definitions.
+
+         user - A login account name.
+
+         password - The password for the login account.
+
+         mailbox - A mailbox name (also called a mail folder).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                 [Page 4]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Default Mailboxes
+
+      TOPS-20
+
+         MAIL.TXT.1 - from login directory
+
+      UNIX
+
+         both
+            /usr/spool/mail/user
+         and
+            /usr/user/Mail/inbox/*
+
+            where "user" is the user value supplied in the HELO command.
+
+   End of Line
+
+      End of Line is Carriage Return (CR) followed by Line Feed (LF).
+      This sequence is indicated by "CRLF" in this document.  This end
+      of line convention must be used for commands and replies.
+
+   Message Length
+
+      The reply to the READ command or an acknowledgment command (ACKS,
+      ACKD, NACK) is the length (a character count) of the next message
+      to be transmitted.  This includes all the characters in the data
+      transmitted.  CRLF counts as two characters.  A length of zero
+      means the message does not exist or is empty.  A request to
+      transmit a message of zero length will result in the server
+      closing the connection.  The message is transmitted in the
+      standard internet format described in RFC-822 [2] and NVT-ASCII.
+      This may be different from the storage format and may make
+      computing the message length from the stored message non-trivial.
+
+   Message Numbers
+
+      The reply to the HELO and FOLD commands is a count of the number
+      of messages in a the selected mailbox.  The READ command has a
+      message number as an optional argument.  These numbers are
+      decimal, start at one, and computed with respect to the current
+      mailbox.  That is, the first message in a mailbox is message
+      number 1.
+
+   Numbers
+
+      All numbers in this memo and protocol are decimal.
+
+
+
+
+Butler, et. al.                                                 [Page 5]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Quoting
+
+      In a few cases, there may be a need to have a special character in
+      an argument (user, password, or mailbox) that is not allowed by
+      the syntax.  For example, a space in a password. To allow for
+      this, a quoting convention is defined.  Unfortunately, such
+      quoting conventions "use up" another otherwise uninteresting
+      character.  In this protocol the back slash "\" is used as the
+      quote character.  To include a space in an argument the two
+      character sequence "back-slash, space" is transmitted.  To include
+      a back-slash in an argument the two character sequence
+      "back-slash, back-slash" is transmitted.  This quoting convention
+      is used in the command arguments only, it is not used in the mail
+      data transmitted in response to a RETR command.
+
+   Reply Strings
+
+      The first character is required to be as specified (i.e.,
+      "+", "-", "=", "#").  The optional strings that follow can be
+      whatever the implementer thinks is appropriate.
+
+Definitions of Commands and Replies
+
+   Summary of Commands and Replies
+
+      Commands                          Replies
+      --------                          -------
+      HELO user password                + OK
+      FOLD mailbox                      - Error
+      READ [n]                          #xxx
+      RETR                              =yyy
+      ACKS
+      ACKD
+      NACK
+      QUIT
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                 [Page 6]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Commands
+
+      HELO user password
+
+         The Hello command identifies the user to the server and carries
+         the password authenticating this user.  This information is
+         used by the server to control access to the mailboxes.  The
+         Hello command is the "HELO" keyword, followed by the user
+         argument, followed by the password argument, followed by CRLF.
+
+            Possible responses:
+
+               "#nnn"
+
+                  where nnn is the number of messages in the default
+                  mailbox,"
+
+               "- error report" and Close the connection.
+
+      FOLD mailbox
+
+         The Folder command selects another mailbox or mail folder.  The
+         server must check that the user is permitted read access to
+         this mailbox.  If the mailbox is empty or does not exist, the
+         number of messages reported is zero.  The Folder command is the
+         "FOLD" keyword, followed by the mailbox argument, followed by
+         CRLF.
+
+            Possible responses:
+
+               "#nnn"
+
+                  where nnn is the number of messages in this mailbox.
+
+      READ [nnn]
+
+         The Read command begins a message reading transaction.  If the
+         Read command is given without an argument the current message
+         is  implied (the current message indicator is incremented  by
+         the ACKS or ACKD commands).  If an argument is used with the
+         Read command it is the message number to be read, and this
+         command sets the current message indicator to that value.  The
+         server returns the count of characters in the message to be
+         transmitted.  If there is no message to be read, the count of
+         zero is returned.  If the message was previously deleted with
+         the ACKD command, the count of zero is returned.  The Read
+         command is followed by the RETR command, the READ command, the
+         FOLD command, or the QUIT command.  Do not attempt to RETR a
+
+
+Butler, et. al.                                                 [Page 7]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+         message of zero characters.  The Read command is the "READ"
+         keyword, optionally followed by the message number argument,
+         followed by CRLF.
+
+            Possible responses:
+
+               "=ccc"
+
+                  where ccc is the number of characters in this message.
+
+      RETR
+
+         The Retrieve command confirms that the client is ready to
+         receive the mail data.  It must be followed by an
+         acknowledgment command.  The server will close the connection
+         if asked to transmit a message of zero characters (i.e.,
+         transmit a non-existent message).  The message is transmitted
+         according to the Internet mail format standard RFC-822 [2] in
+         NVT-ASCII.  The Retrieve command is the "RETR" keyword,
+         followed by CRLF.
+
+            Possible responses:
+
+               the message data
+
+               Close the connection
+
+      ACKS
+
+         The Acknowledge and Save command confirms that the client has
+         received and accepted the message.  The ACKS command ends the
+         message reading transaction.  The message is kept in the
+         mailbox.  The current message indicator is incremented.  The
+         server returns the count of characters in the now current
+         message to be transmitted.  If there is no message to be read
+         or the message is marked deleted, the count of zero is
+         returned.  The Acknowledge and Save command is the "ACKS"
+         keyword, followed by CRLF.
+
+            Possible responses:
+
+               "=ccc"
+
+                  where ccc is the number of characters in the next
+                  message.
+
+
+
+
+
+Butler, et. al.                                                 [Page 8]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+      ACKD
+
+         The Acknowledge and Delete command confirms that the client has
+         received and accepted the message.  The ACKD command ends the
+         message reading transaction.  If the user is authorized to have
+         write access to the mailbox, the message is deleted from the
+         mailbox.  Actually, the message is only marked for deletion.
+         The actual change is made  when the mailbox is released at the
+         end of the session or when the client selects another mailbox
+         with the FOLD command.  The messages are not renumbered until
+         the mailbox is released.  If the user does not have write
+         access to the mailbox no change is made to the mailbox.  The
+         response is the same whether or not the message was actually
+         deleted.  The current message indicator is incremented.  The
+         server returns the count of characters in the now current
+         message to be transmitted.  If there is no message to be read
+         or the message is marked deleted, the count of zero is
+         returned.  The Acknowledge and Delete command is the "ACKD"
+         keyword, followed by CRLF.
+
+            Possible responses:
+
+               "=ccc"
+
+                  where ccc is the number of characters in the next
+                  message.
+
+      NACK
+
+         The Negative Acknowledge command reports that the client did
+         not receive the message.  The NACK command ends the message
+         reading transaction.  The message is kept in the mailbox.  The
+         current message indicator remains the same.  The server returns
+         the count of characters in the current message.  Since the
+         count to be returned is for the message just transmitted it the
+         message must exist and not be marked deleted, and the count
+         must be positive (non-zero).  The Negative Acknowledge command
+         is the "NACK" keyword, followed by CRLF.
+
+            Possible responses:
+
+               "=ccc"
+
+                  where ccc is the number of characters in this message.
+
+
+
+
+
+
+Butler, et. al.                                                 [Page 9]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+      QUIT
+
+         The Quit command indicates the client is done with the session.
+         The server sends an OK response and then closes the connection.
+         The Quit command is the "QUIT" keyword, followed by CRLF.
+
+            Possible responses:
+
+               "+ OK" and Close the connection
+
+   Replies
+
+      Greeting
+
+         The greeting is sent by the server as soon as the connection is
+         established.  The greeting is a plus sign, followed by the
+         protocol name ("POP2"), followed by the server host name,
+         optionally followed by text, and ending with a CRLF.
+
+      +
+
+         The success or plus sign response indicates successful
+         completion of the operation specified in the command.  The
+         success response is a plus sign, optionally followed by text,
+         and ending with a CRLF.
+
+      -
+
+         The failure or minus sign response indicates the failure of the
+         operation specified in the command.  The failure response is a
+         minus sign, optionally followed by text, and ending with a
+         CRLF.
+
+      =
+
+         The length or equal sign response tells the length in
+         characters of the message referenced by the command.  The
+         length response is a equal sign, followed by a number,
+         optionally followed by text, and ending with a CRLF.
+
+      #
+
+         The count or number sign response tells the number of messages
+         in a folder or mailbox referenced by the command.  The count
+         response is a number sign, followed by a number, optionally
+         followed by text, and ending with a CRLF.
+
+
+
+
+Butler, et. al.                                                [Page 10]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Timeouts
+
+      In any protocol of this type there have to be timeouts.  Neither
+      side wants to get stuck waiting forever for the other side
+      (particularly is the other side has gone crazy or crashed).
+
+      The client expects a reply to a command fairly quickly and so
+      should have a short timeout for this.  This timeout is called T1.
+
+         For some servers, it may take some processing to compute the
+         number of messages in a mailbox, or the length of a message, or
+         to reformat a stored message for transmission, so this time out
+         has to allow for such processing time.  Also care must be taken
+         not to timeout waiting for the completion of a RETR reply while
+         a long message is in fact being transfered.
+
+      The server expects the session to progress with some but not
+      excessive delay between commands and so should have a long timeout
+      waiting for the next command.  This time out is T2.
+
+         One model of use of this protocol is that any number of
+         different types of clients can be built with different ways of
+         interacting with the human user and the server, but still
+         expecting the client to open the connection to the server,
+         present a sequence of commands, and close the connection,
+         without waiting for intervention by the human user.  With such
+         client implementations, it is reasonable for the server to have
+         a fairly small value for timeout T2.
+
+         On the other hand, one could easily have the client be very
+         human user directed with the user making decisions between
+         commands.  This would cause arbitrary delays between client
+         commands to the server, and require the value of timeout T2 to
+         be quite large.
+
+Implementation Discussion
+
+   Comments on a Server on TOPS-20
+
+      On TOPS-20, a mailbox is a single file.  New messages are appended
+      to the file.  There is a separator line between messages.
+
+      The tricky part of implementing a POP2 server on TOPS-20 is to
+      provide for deleting messages.  This only has to be done for the
+      mailboxes (files) for which the user has write access.  The
+      problem is to avoid both (1) preventing other users from accessing
+      or updating the mailbox for long periods, and (2) accidentally
+      deleting a message the user has not seen.
+
+
+Butler, et. al.                                                [Page 11]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+      One suggestion is as follows:
+
+         When a mailbox is first selected, if the user has write access,
+         rename the mailbox file to some temporary name.  Thus new
+         messages will be placed in a new instance of the mailbox file.
+         Conduct all POP2 operation on the temporary mailbox file
+         (including deleting messages).  When the POP2 session is over
+         or another mailbox is selected, prepend any messages left
+         undeleted in the temporary file to the new instance of the
+         mailbox file.
+
+   Sizes
+
+      The maximum length of a command line is 512 characters (including
+      the command word and the CRLF).
+
+      The maximum length of a reply line is 512 characters (including
+      the success indicator (+, -, =, #) and the CRLF).
+
+      The maximum length of a text line is 1000 characters (including
+      CRLF).
+
+   ISI has developed a POP2 server for TOPS-20 and for Berkeley 4.2
+   Unix, and a POP2 client for an IBM-PC and for Berkeley 4.2 Unix.
+
+Extensions Not Supported
+
+   POP2 does not examine the internal data of messages.  In particular,
+   the server does not parse message headers.
+
+   The server doesn't have any state information (i.e., it doesn't know
+   from one session to the next what has happened).  For example, the
+   server doesn't know which messages were received since the last time
+   the user used POP2, so it can't send just the "new" messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 12]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Examples
+
+   Example 1:
+
+           Client                    Server
+           ------                    ------
+                                Wait for connection
+      Open connection  -->
+                           <--  + POP2 USC-ISIF.ARPA Server
+      HELO POSTEL SECRET -->
+                           <--  #2 messages in your mailbox
+      READ             -->   
+                           <--  =537 characters in message 1
+      RETR             -->   
+                           <--  [data of message 1]
+      ACKD             -->   
+                           <--  =234 characters in message 2
+      RETR             -->   
+                           <--  [data of message 2]
+      ACKD             -->   
+                           <--  =0 no more messages
+      QUIT             -->
+                           <--  + OK, bye, bye
+      Close connection --> <--  Close connection
+                                Go back to start
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 13]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Example 2:
+
+           Client                    Server
+           ------                    ------
+                                Wait for connection
+      Open connection  -->
+                           <--  + POP2 ISI-VAXA.ARPA server here
+      HELO smith secret -->
+                           <--  #35 messages
+      FOLD /usr/spool/mail/smith -->
+                           <--  #27 messages
+      READ  27         -->   
+                           <--  =10123 characters in that message
+      RETR             -->   
+                           <--  [data of message 27]
+      ACKS             -->   
+                           <--  =0 no more messages
+      QUIT             -->
+                           <--  + bye, call again sometime.
+      Close connection --> <--  Close connection
+                                Go back to start
+
+   Example 3:
+
+           Client                    Server
+           ------                    ------
+                                Wait for connection
+      Open connection  -->
+                           <--  + POP2 ISI-VAXA.ARPA server here
+      HELO Jones secret -->
+                           <--  #0 messages
+      READ             -->   
+                           <--  Close connection
+      Close connection -->
+                                Go back to start
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 14]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Formal Syntax
+
+   <digit>    = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
+
+   <letter>   = A | B | C | ... | Z
+                a | b | c | ... | z
+
+   <punct>    = ! | " | # | $ | % | & | ' | ( | ) | * |
+                + | , | - | / | : | < | = | > | ? | @ |
+                [ | ] | ^ | _ | ` | { | | | } | ~
+
+   <quote>    = \
+
+   <any>      = any one of the 128 ASCII codes
+
+   <CR>       = carriage return, code 10
+
+   <LF>       = line feed, code 13
+
+   <SP>       = space, code 32
+
+   <CRLF>     = <CR> <LF>
+
+   <print>    = <letter> | <digit> | <punct> | <quote> <any>
+
+   <char>     = <print> | <SP>
+
+   <word>     = <print> | <print> <word>
+
+   <string>   = <char> | <char> <string>
+
+   <ld>       = <letter> | <digit>
+
+   <ldh>      = <letter> | <digit> | -
+
+   <ldhs>     = <ldh> | <ldh> <ldhs>
+
+   <name>     = <letter> [ [ <ldhs> ] <ld> ]
+
+   <host>     =  <name> | <name> . <host>
+
+   <user>     = <word>
+
+   <password> = <word>
+
+   <mailbox>  = <string>
+
+   <number>   = <digit> | <digit> <number>
+
+
+Butler, et. al.                                                [Page 15]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   <helo>     = HELO <SP> <user> <SP> <password> <CRLF>
+
+   <fold>     = FOLD <SP> <mailbox> <CRLF>
+
+   <read>     = READ [<SP> <number>] <CRLF>
+
+   <retr>     = RETR <CRLF>
+
+   <acks>     = ACKS <CRLF>
+
+   <ackd>     = ACKD <CRLF>
+
+   <nack>     = NACK <CRLF>
+
+   <quit>     = QUIT <CRLF>
+
+   <ok>       = + [<SP> <string>] <CRLF>
+
+   <err>      = - [<SP> <string>] <CRLF>
+
+   <count>    = # <number> [<SP> <string>] <CRLF>
+
+   <greet>    = + <SP> POP2 <SP> <host> [<SP> <string>] <CRLF>
+
+   <length>   = = <number> [<SP> <string>] <CRLF>
+
+   <command>  = <helo> | <fold> | <read> | <retr> |
+                <acks> | <ackd> | <nack> | <quit>
+
+   <reply>    = <ok> | <err> | <count> | <length> | <greet>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 16]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Client State Diagram
+
+   
+                          |                    ^  + BYE  
+                          |  Open              |  -----  
+                          |           Greet    |  Close  
+                          V           -----    |         
+                      +-------+       QUIT    +-------+  
+                      | CALL  |-------------->| EXIT  |  
+                      +-------+               +-------+  
+                          |                       ^      
+                          |  Greet                |      
+                          |  -----                |      
+                          |  HELO                 |      
+              +---->+     |                       |      
+        #NNN  ^     |     |        #NNN           |      
+        ----  |     V     V        ----           |      
+        FOLD  |    +-------+       QUIT           |      
+              +<---| NMBR  |--------------------->+      
+                   +-------+                      ^      
+                    ^     |                       |      
+                    |     |  #NNN                 |      
+                    |     |  ----                 |      
+              =CCC  |     |  READ                 |      
+              ----  |     |                       |      
+              FOLD  |     |        =CCC           |      
+                    |     V        ----           |      
+        =CCC  +--->+-------+       QUIT           |      
+        ----  ^    | SIZE  |--------------------->+      
+        READ  +<---+-------+                             
+                    ^     |                              
+                    |     |  =CCC                        
+              data  |     |  ----                        
+              ----  |     |  RETR                        
+              ack   |     |                              
+                    |     V                              
+                   +-------+                             
+                   | XFER  |                             
+                   +-------+                             
+   
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 17]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Server State Diagram
+
+   
+                       +<----------------------+  Close  
+                       |                       |  -----  
+               Listen  |                       |  Close  
+                       V                       |         
+                   +-------+                  +-------+  
+                   | LSTN  |                  | DONE  |  
+                   +-------+                  +-------+  
+                       |                          ^      
+                       |  Open                    |      
+                       |  -----                   |      
+                       |  Greet                   |      
+                       |                          |      
+                       |           QUIT           |      
+                       V           -----          |      
+                   +-------+       + BYE          |      
+                   | AUTH  |--------------------->+      
+                   +-------+                      ^      
+                       |                          |      
+                       |  HELO                    |      
+                       |  ----                    |      
+                       |  #NNN                    |      
+                       |                          |      
+                       |           QUIT           |      
+                       V           -----          |      
+        FOLD  +--->+-------+       + BYE          |      
+        ----  ^    | MBOX  |--------------------->+      
+        #NNN  +<---+-------+                      ^      
+                    ^     |                       |      
+                    |     |  READ                 |      
+              FOLD  |     |  ----                 |      
+              ----  |     |  =CCC                 |      
+              #NNN  |     |        QUIT           |      
+                    |     V        -----          |      
+        READ  +--->+-------+       + BYE          |      
+        ----  ^    | ITEM  |--------------------->+      
+        =CCC  +<---+-------+                             
+                    ^     |                              
+                    |     |  RETR                        
+              ack   |     |  ----                        
+              ----  |     |  data                        
+              =CCC  |     |                              
+                    |     V                              
+                   +-------+                             
+                   | NEXT  |                             
+                   +-------+                             
+
+
+Butler, et. al.                                                [Page 18]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Combined Flow Diagram
+
+   
+   +----+                                                              
+   |CALL|<------------------------------------------------------------+
+   |LSTN|                                                             ^
+   +----+                                                             |
+    | Greet                                                           |
+    |                                                                 |
+    |  +----------------------------------------------------->+       |
+    |  ^ QUIT                                                 |       |
+    V  |                                                      V       |
+   +----+        +----+                                      +----+   |
+   |CALL| HELO   |NMBR|                                      |EXIT|   |
+   |AUTH|------->|AUTH|                                      |AUTH|   |
+   +----+        +----+                                      +----+   |
+                  | #NNN                                   + Bye |    |
+                  |                                              |    |
+                  |  +------------------------------------>+     |    |
+                  |  ^ QUIT                                |     |    |
+                  V  |                                     V     |    |
+            +--->+----+        +----+                     +----+ |    |
+       FOLD ^    |NMBR| READ   |SIZE|                     |EXIT| |    |
+       ---- |    |MBOX|------->|MBOX|                     |MBOX| |    |
+       #NNN +<---+----+        +----+                     +----+ |    |
+                     ^           | =CCC                 + Bye |  |    |
+                     |           |                            |  |    |
+                FOLD +<--------+ | +------------------->+     |  |    |
+                ----           ^ | ^ QUIT               |     |  |    |
+                #NNN           | V |                    V     |  |    |
+                         +--->+-----+        +----+    +----+ |  |    |
+                    READ ^    |SIZE | RETR   |XFER|    |EXIT| |  |    |
+                    ---- |    | ITEM|------->|ITEM|    |ITEM| |  |    |
+                    =CCC +<---+-----+        +----+    +----+ |  |    |
+                                 ^             | data      |  |  |    |
+                                 |             |           |  |  |    |
+                            =CCC |             V     + Bye |  |  |    |
+                               +----+        +----+        |  |  |    |
+                               |SIZE|    Ack |XFER|        |  |  |    |
+                               |NEXT|<-------|NEXT|        |  |  |    |
+                               +----+        +----+        |  |  |    |
+                                                           |  |  |    |
+                                                           |  |  |    |
+                                                           V  V  V    |
+                                                          +-------+   |
+                                                          | EXIT  |-->+
+                                                          | DONE  |    
+                                                          +-------+    
+
+
+Butler, et. al.                                                [Page 19]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Client Decision Table
+
+   
+          |            STATE                 |
+   -------+----------------------------------|
+   INPUT  | CALL | NMBR | SIZE | XFER | EXIT |
+   -------+----------------------------------|
+   Greet  |  2   |  1   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   #NNN   |  1   |  3   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   =CCC   |  1   |  1   |  4   |  1   |  6   |
+   -------+----------------------------------|
+   data   |  1   |  1   |  1   |  5   |  6   |
+   -------+----------------------------------|
+   + Bye  |  1   |  1   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   Close  |  1   |  1   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   other  |  1   |  1   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   Timeout|  1   |  1   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 20]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Actions:
+
+      1.  This is garbage.  Send "QUIT", and go to EXIT state.
+
+      2.  (a) If the greeting is right then send "HELO"
+              and go to NMBR state,
+          (b) Else send "QUIT" and go to EXIT state.
+
+      3.  (a) If user wants this folder and NNN > 0
+              then send "READ" and go to SIZE state,
+          (b) If user wants a this folder and NNN = 0
+              then send "QUIT" and go to EXIT state,
+          (c) If user wants a different folder
+              then send "FOLD" and go to NMBR state.
+
+      4.  (a) If user wants this message and CCC > 0
+              then send "RETR" and go to XFER state,
+          (b) If user wants a this message and CCC = 0
+              then send "QUIT" and go to EXIT state,
+          (c) If user wants a different message
+              then send "READ" and go to SIZE state.
+
+      5.  (a) If user wants this message kept
+              then send "ACKS" and go to SIZE state,
+          (b) If user wants a this message deleted
+              then send "ACKD" and go to SIZE state,
+          (c) If user wants a this message again
+              then send "NACK" and go to SIZE state.
+
+      6.  Close the connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 21]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Server Decision Table
+
+   
+          |              STATE                       
+   -------+----------------------------------------- 
+   INPUT  | LSTN | AUTH | MBOX | ITEM | NEXT | DONE |
+   -------+-----------------------------------------|
+   Open   |  2   |  1   |  1   |  1   |  1   |  1   |
+   -------+-----------------------------------------|
+   HELO   |  1   |  3   |  1   |  1   |  1   |  1   |
+   -------+-----------------------------------------|
+   FOLD   |  1   |  1   |  5   |  5   |  1   |  1   |
+   -------+-----------------------------------------|
+   READ   |  1   |  1   |  6   |  6   |  1   |  1   |
+   -------+-----------------------------------------|
+   RETR   |  1   |  1   |  1   |  7   |  1   |  1   |
+   -------+-----------------------------------------|
+   ACKS   |  1   |  1   |  1   |  1   |  8   |  1   |
+   -------+-----------------------------------------|
+   ACKD   |  1   |  1   |  1   |  1   |  8   |  1   |
+   -------+-----------------------------------------|
+   NACK   |  1   |  1   |  1   |  1   |  8   |  1   |
+   -------+-----------------------------------------|
+   QUIT   |  1   |  4   |  4   |  4   |  1   |  1   |
+   -------+-----------------------------------------|
+   Close  |  1   |  1   |  1   |  1   |  1   |  9   |
+   -------+-----------------------------------------|
+   other  |  1   |  1   |  1   |  1   |  1   |  1   |
+   -------+-----------------------------------------|
+   Timeout|      |  1   |  1   |  1   |  1   |  1   |
+   -------+-----------------------------------------|
+   
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 22]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Actions:
+
+      1.  This is garbage.  Send "- error", and Close the connection.
+
+      2.  Send the greeting. Go to AUTH state.
+
+      3.  (a) If authorized user then send "#NNN" and go tp MBOX state,
+          (b) Else send "- error" and Close the connection.
+
+      4.  Send "+ Bye" and go to DONE state.
+
+      5.  Send "+NNN" and go to MBOX state.
+
+      6.  Send "=CCC" and go to ITEM state.
+
+      7.  If message exists then send the data and got to NEXT state,
+          Else Close the connection.
+
+      8.  Do what ACKS/ACKD/NACK require and go to ITEM state.
+
+      9.  Close the connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 23]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Acknowledgment
+
+   We would like to acknowledge the helpful comments that we received on
+   the first version of POP described in RFC 918, and the draft of POP2
+   distributed to interested parties.
+
+References
+
+   [1]  Postel, J., "Simple Mail Transfer Protocol", RFC 821,
+   USC/Information Sciences Institute, August 1982.
+
+   [2]  Crocker, D., "Standard for the Format of ARPA-Internet Text
+   Messages", RFC 822, University of Delaware, August 1982.
+
+   [3]  Reynolds, J.K., "Post Office Protocol", RFC 918, USC/Information
+   Sciences Institute, October 1984.
+
+   [4]  Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 923,
+   USC/Information Sciences Institute, October 1984.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 24]
+