As per Relevance of the word february, we have this rfc below:
Network Working Group M.
Request for Comments: 937 J.
D.
J.
J. K.
Obsoletes: RFC 918
February 1985
POST OFFICE PROTOCOL - VERSION 2
Status of this
This RFC suggests a simple method for workstations to
access mail from a mailbox server. This RFC specifies a
protocol for the ARPA-Internet community, and requests discussion
suggestions for improvement. This memo is a revision of RFC 918.
Distribution of this memo is unlimited
The intent of the Post Office Protocol Version 2 (POP2) is to allow
user's workstation to access mail from a mailbox server. It
expected that mail will be posted from the workstation to the
server via the Simple Mail Transfer Protocol (SMTP). For
information see RFC-821 [1] and RFC-822 [2].
This protocol assumes a reliable data stream such as provided by
or any similar protocol. When TCP is used, the POP2 server
on port 109 [4].
System Model and
While we view the workstation as an Internet host in the sense
it implements IP, we do not expect the workstation to contain
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,
otherwise unavailable as an SMTP server
POP2 is designed for an environment of workstations and servers on
low-delay, high-throughput, local networks (such as Ethernets). POP
may be useful in other environments as well, but if the
is substantially different, a different division of labor between
client and server may be appropriate, and a different
required
Suppose the user's real name is John Smith, the user's machine
called FIDO, and that the mailbox server is called DOG-HOUSE.
Butler, et. al. [Page 1]
RFC 937 February 1985
Post Office
we expect the user's mail to be addressed to JSmith@DOG-HOUSE.
(not JSmith@FIDO.ARPA).
That is, the destination of the mail is the mailbox on the
machine. The POP2 protocol and the workstation are merely
mechanism for viewing the messages in the mailbox
The user is not tied to any particular workstation for accessing
mail. The workstation does not appear as any part of the
address
This is a very simple protocol. This is not a user interface.
expect that there is a program in the workstation that is friendly
the user. This protocol is not "user friendly". One basic rule
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
headers (Date:, From:, To:, Cc:, or Subject:). POP2 simply
whole messages from a mailbox server to a client workstation
The
The POP2 protocol is a sequence of commands and replies. The
draws from many previous protocols of the ARPA-Internet community
The server must be listening for a connection. When a
is opened the server sends a greeting message and waits
commands. When commands are received the server acts on them
responds with replies
The client opens a connection, waits for the greeting, then
the HELO command with the user name and password arguments
establish authorization to access mailboxes. The server
the number of messages in the default mailbox
The client may read the default mailbox associated with the
name or may select another mailbox by using the FOLD command.
server returns the number of messages in the mailbox selected
The client begins a message reading transaction with a
command. The read command may optionally indicate which
number to read, the default is the current message (
when a message is read and set to one when a new folder
selected). The server returns the number of characters in
message
Butler, et. al. [Page 2]
RFC 937 February 1985
Post Office
The client asks for the content of the message to be sent with
RETR command. The server sends the message data
When all the data has been received the client sends
acknowledgment command. This is one of ACKS, ACKD, and NACK
ACKS means "I've received the message successfully and
keep it in the mailbox".
ACKD means "I've received the message successfully and
delete it from the mailbox".
NACK means "I did not receive the message and please keep it
the mailbox".
In the case of ACKS or ACKD the server increments the
message indicator. In the case of NACK the current
indicator stays the same
In all cases the server returns the number of characters in
(now) current message
The client terminates the session with the QUIT command.
server returns an ok
Butler, et. al. [Page 3]
RFC 937 February 1985
Post Office
The Normal
Client
------ ------
Wait for
Open Connection -->
<-- + POP2 Server
Wait for
HELO Fred Secret -->
<-- #13 messages for
Wait for
READ 13 -->
<-- =537 characters in that
Wait for
RETR -->
<-- (send the message data
Wait for
ACKS -->
<-- =0 no more
Wait for
QUIT -->
<-- +
Close connection --> <-- Close
Wait for Connection (go back to start
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
Default
TOPS-20
MAIL.TXT.1 - from login
/usr/spool/mail/
/usr/user/Mail/inbox/*
where "user" is the user value supplied in the HELO command
End of
End of Line is Carriage Return (CR) followed by Line Feed (LF).
This sequence is indicated by "CRLF" in this document. This
of line convention must be used for commands and replies
Message
The reply to the READ command or an acknowledgment command (ACKS
ACKD, NACK) is the length (a character count) of the next
to be transmitted. This includes all the characters in the
transmitted. CRLF counts as two characters. A length of
means the message does not exist or is empty. A request
transmit a message of zero length will result in the
closing the connection. The message is transmitted in
standard internet format described in RFC-822 [2] and NVT-ASCII
This may be different from the storage format and may
computing the message length from the stored message non-trivial
Message
The reply to the HELO and FOLD commands is a count of the
of messages in a the selected mailbox. The READ command has
message number as an optional argument. These numbers
decimal, start at one, and computed with respect to the
mailbox. That is, the first message in a mailbox is
number 1.
All numbers in this memo and protocol are decimal
Butler, et. al. [Page 5]
RFC 937 February 1985
Post Office
In a few cases, there may be a need to have a special character
an argument (user, password, or mailbox) that is not allowed
the syntax. For example, a space in a password. To allow
this, a quoting convention is defined. Unfortunately,
quoting conventions "use up" another otherwise
character. In this protocol the back slash "\" is used as
quote character. To include a space in an argument the
character sequence "back-slash, space" is transmitted. To
a back-slash in an argument the two character
"back-slash, back-slash" is transmitted. This quoting
is used in the command arguments only, it is not used in the
data transmitted in response to a RETR command
Reply
The first character is required to be as specified (i.e.,
"+", "-", "=", "#"). The optional strings that follow can
whatever the implementer thinks is appropriate
Definitions of Commands and
Summary of Commands and
Commands
-------- -------
HELO user password +
FOLD mailbox -
READ [n] #
RETR =
Butler, et. al. [Page 6]
RFC 937 February 1985
Post Office
HELO user
The Hello command identifies the user to the server and
the password authenticating this user. This information
used by the server to control access to the mailboxes.
Hello command is the "HELO" keyword, followed by the
argument, followed by the password argument, followed by CRLF
Possible responses
"#nnn
where nnn is the number of messages in the
mailbox,"
"- error report" and Close the connection
FOLD
The Folder command selects another mailbox or mail folder.
server must check that the user is permitted read access
this mailbox. If the mailbox is empty or does not exist,
number of messages reported is zero. The Folder command is
"FOLD" keyword, followed by the mailbox argument, followed
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
Read command is given without an argument the current
is implied (the current message indicator is incremented
the ACKS or ACKD commands). If an argument is used with
Read command it is the message number to be read, and
command sets the current message indicator to that value.
server returns the count of characters in the message to
transmitted. If there is no message to be read, the count
zero is returned. If the message was previously deleted
the ACKD command, the count of zero is returned. The
command is followed by the RETR command, the READ command,
FOLD command, or the QUIT command. Do not attempt to RETR
Butler, et. al. [Page 7]
RFC 937 February 1985
Post Office
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
The Retrieve command confirms that the client is ready
receive the mail data. It must be followed by
acknowledgment command. The server will close the
if asked to transmit a message of zero characters (i.e.,
transmit a non-existent message). The message is
according to the Internet mail format standard RFC-822 [2]
NVT-ASCII. The Retrieve command is the "RETR" keyword
followed by CRLF
Possible responses
the message
Close the
The Acknowledge and Save command confirms that the client
received and accepted the message. The ACKS command ends
message reading transaction. The message is kept in
mailbox. The current message indicator is incremented.
server returns the count of characters in the now
message to be transmitted. If there is no message to be
or the message is marked deleted, the count of zero
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
message
Butler, et. al. [Page 8]
RFC 937 February 1985
Post Office
The Acknowledge and Delete command confirms that the client
received and accepted the message. The ACKD command ends
message reading transaction. If the user is authorized to
write access to the mailbox, the message is deleted from
mailbox. Actually, the message is only marked for deletion
The actual change is made when the mailbox is released at
end of the session or when the client selects another
with the FOLD command. The messages are not renumbered
the mailbox is released. If the user does not have
access to the mailbox no change is made to the mailbox.
response is the same whether or not the message was
deleted. The current message indicator is incremented.
server returns the count of characters in the now
message to be transmitted. If there is no message to be
or the message is marked deleted, the count of zero
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
message
The Negative Acknowledge command reports that the client
not receive the message. The NACK command ends the
reading transaction. The message is kept in the mailbox.
current message indicator remains the same. The server
the count of characters in the current message. Since
count to be returned is for the message just transmitted it
message must exist and not be marked deleted, and the
must be positive (non-zero). The Negative Acknowledge
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
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
The greeting is sent by the server as soon as the connection
established. The greeting is a plus sign, followed by
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
completion of the operation specified in the command.
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
operation specified in the command. The failure response is
minus sign, optionally followed by text, and ending with
CRLF
=
The length or equal sign response tells the length
characters of the message referenced by the command.
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
in a folder or mailbox referenced by the command. The
response is a number sign, followed by a number,
followed by text, and ending with a CRLF
Butler, et. al. [Page 10]
RFC 937 February 1985
Post Office
In any protocol of this type there have to be timeouts.
side wants to get stuck waiting forever for the other
(particularly is the other side has gone crazy or crashed).
The client expects a reply to a command fairly quickly and
should have a short timeout for this. This timeout is called T1.
For some servers, it may take some processing to compute
number of messages in a mailbox, or the length of a message,
to reformat a stored message for transmission, so this time
has to allow for such processing time. Also care must be
not to timeout waiting for the completion of a RETR reply
a long message is in fact being transfered
The server expects the session to progress with some but
excessive delay between commands and so should have a long
waiting for the next command. This time out is T2.
One model of use of this protocol is that any number
different types of clients can be built with different ways
interacting with the human user and the server, but
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
client implementations, it is reasonable for the server to
a fairly small value for timeout T2.
On the other hand, one could easily have the client be
human user directed with the user making decisions
commands. This would cause arbitrary delays between
commands to the server, and require the value of timeout T2
be quite large
Implementation
Comments on a Server on TOPS-20
On TOPS-20, a mailbox is a single file. New messages are
to the file. There is a separator line between messages
The tricky part of implementing a POP2 server on TOPS-20 is
provide for deleting messages. This only has to be done for
mailboxes (files) for which the user has write access.
problem is to avoid both (1) preventing other users from
or updating the mailbox for long periods, and (2)
deleting a message the user has not seen
Butler, et. al. [Page 11]
RFC 937 February 1985
Post Office
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
messages will be placed in a new instance of the mailbox file
Conduct all POP2 operation on the temporary mailbox
(including deleting messages). When the POP2 session is
or another mailbox is selected, prepend any messages
undeleted in the temporary file to the new instance of
mailbox file
The maximum length of a command line is 512 characters (
the command word and the CRLF).
The maximum length of a reply line is 512 characters (
the success indicator (+, -, =, #) and the CRLF).
The maximum length of a text line is 1000 characters (
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
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
from one session to the next what has happened). For example,
server doesn't know which messages were received since the last
the user used POP2, so it can't send just the "new" messages
Butler, et. al. [Page 12]
RFC 937 February 1985
Post Office
Example 1:
Client
------ ------
Wait for
Open connection -->
<-- + POP2 USC-ISIF.ARPA
HELO POSTEL SECRET -->
<-- #2 messages in your
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
QUIT -->
<-- + OK, bye,
Close connection --> <-- Close
Go back to
Butler, et. al. [Page 13]
RFC 937 February 1985
Post Office
Example 2:
Client
------ ------
Wait for
Open connection -->
<-- + POP2 ISI-VAXA.ARPA server
HELO smith secret -->
<-- #35
FOLD /usr/spool/mail/smith -->
<-- #27
READ 27 -->
<-- =10123 characters in that
RETR -->
<-- [data of message 27]
ACKS -->
<-- =0 no more
QUIT -->
<-- + bye, call again sometime
Close connection --> <-- Close
Go back to
Example 3:
Client
------ ------
Wait for
Open connection -->
<-- + POP2 ISI-VAXA.ARPA server
HELO Jones secret -->
<-- #0
READ -->
<-- Close
Close connection -->
Go back to
Butler, et. al. [Page 14]
RFC 937 February 1985
Post Office
Formal
= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
= A | B | C | ... |
a | b | c | ... |
= ! | " | # | $ | % | & | ' | ( | ) | * |
+ | , | - | / | : | < | = | > | ? | @ |
[ | ] | ^ | _ | ` | { | | | } | ~
= \
= any one of the 128 ASCII
= carriage return, code 10
= line feed, code 13
= space, code 32
=
= | | |
= |
= |
= |
= |
= | | -
= |
= [ [ ] ]
= | .
=
<password> =
=
= |
Butler, et. al. [Page 15]
RFC 937 February 1985
Post Office
= HELO <password>
= FOLD
= READ [ ]
= RETR
= ACKS
= ACKD
= NACK
= QUIT
= + [ ]
= - [ ]
= # [ ]
= + POP2 [ ]
= = [ ]
= | | | |
| | |
= | | | |
Butler, et. al. [Page 16]
RFC 937 February 1985
Post Office
Client State
| ^ + 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
Server State
+<----------------------+ 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
Combined Flow
+----+
|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
Client Decision
| 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
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
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
then send "READ" and go to SIZE state
5. (a) If user wants this message
then send "ACKS" and go to SIZE state
(b) If user wants a this message
then send "ACKD" and go to SIZE state
(c) If user wants a this message
then send "NACK" and go to SIZE state
6. Close the connection
Butler, et. al. [Page 21]
RFC 937 February 1985
Post Office
Server Decision
| 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
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
We would like to acknowledge the helpful comments that we received
the first version of POP described in RFC 918, and the draft of POP
distributed to interested parties
[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
Messages", RFC 822, University of Delaware, August 1982.
[3] Reynolds, J.K., "Post Office Protocol", RFC 918, USC/
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]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
