rfc937.txt

RFC 相关的技术文档

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]