Post Office Protocol: Version 2
RFC 937
Document | Type |
RFC - Historic
(February 1985; No errata)
Obsoletes RFC 918
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 937 (Historic) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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.
Show full document text