From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc937.txt | 1392 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1392 insertions(+) create mode 100644 doc/rfc/rfc937.txt (limited to 'doc/rfc/rfc937.txt') diff --git a/doc/rfc/rfc937.txt b/doc/rfc/rfc937.txt new file mode 100644 index 0000000..ae154ea --- /dev/null +++ b/doc/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 + + = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 + + = A | B | C | ... | Z + a | b | c | ... | z + + = ! | " | # | $ | % | & | ' | ( | ) | * | + + | , | - | / | : | < | = | > | ? | @ | + [ | ] | ^ | _ | ` | { | | | } | ~ + + = \ + + = any one of the 128 ASCII codes + + = carriage return, code 10 + + = line feed, code 13 + + = space, code 32 + + = + + = | | | + + = | + + = | + + = | + + = | + + = | | - + + = | + + = [ [ ] ] + + = | . + + = + + = + + = + + = | + + +Butler, et. al. [Page 15] + + + +RFC 937 February 1985 +Post Office Protocol + + + = HELO + + = FOLD + + = READ [ ] + + = RETR + + = ACKS + + = ACKD + + = NACK + + = QUIT + + = + [ ] + + = - [ ] + + = # [ ] + + = + POP2 [ ] + + = = [ ] + + = | | | | + | | | + + = | | | | + + + + + + + + + + + + + + + + + + + + +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] + -- cgit v1.2.3