Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

HISTORIC
Network Working Group                                          M. ButlerRequest for Comments: 937                                      J. Postel                                                                D. Chase                                                           J. Goldberger                                                          J. K. ReynoldsObsoletes: RFC918                                                   ISI                                                           February 1985POST OFFICE PROTOCOL - VERSION 2Status 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 ofRFC 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 seeRFC-821 [1] andRFC-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.  ThenButler, et. al.                                                 [Page 1]

RFC 937                                                    February 1985Post 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 1985Post 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 1985Post 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 1985Post 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 inRFC-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 1985Post 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      QUITButler, et. al.                                                 [Page 6]

RFC 937                                                    February 1985Post 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 aButler, et. al.                                                 [Page 7]

RFC 937                                                    February 1985Post 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 standardRFC-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 1985Post 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 1985Post 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 1985Post 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 1985Post 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 1985Post Office ProtocolExamples   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 startButler, et. al.                                                [Page 13]

RFC 937                                                    February 1985Post 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 startButler, et. al.                                                [Page 14]

RFC 937                                                    February 1985Post Office ProtocolFormal 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 1985Post 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 1985Post Office ProtocolClient 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 1985Post Office ProtocolServer 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 1985Post Office ProtocolCombined 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 1985Post Office ProtocolClient 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 1985Post 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 1985Post Office ProtocolServer 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 1985Post 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 1985Post Office ProtocolAcknowledgment   We would like to acknowledge the helpful comments that we received on   the first version of POP described inRFC 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]

[8]ページ先頭

©2009-2025 Movatter.jp