POP: Post Office Protocol
Simple protocol for workstations to fetch mail from a server
Reynolds, J.K., "Post Office Protocol", RFC 918, DOI 10.17487/RFC0918, October 1984, <https://www.rfc-editor.org/info/rfc918>.
@misc{rfc918,
series = {Request for Comments},
number = 918,
howpublished = {RFC 918},
publisher = {RFC Editor},
doi = {10.17487/RFC0918},
url = {https://www.rfc-editor.org/info/rfc918},
author = {J.K. Reynolds},
title = {{Post Office Protocol}},
pagetotal = 5,
year = 1984,
month = oct,
} RFC text
Contents
Network Working Group J. K. Reynolds
Request for Comments: 918 ISI
October 1984
POST OFFICE PROTOCOL
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.
Introduction
The intent of the Post Office Protocol (POP) 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].
The status of this protocol is experimental, and this protocol is
dependent upon TCP.
The Protocol
The protocol is for the server to 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
USER and then the PASS commands to establish authorization to access
mailboxes. The client begins a mail reading transaction with either
an RDEL (to read and delete all messages from a mailbox) or a RETR
(to simply read all messages from a mailbox). The server opens and
locks the mailbox, and responds with the number of characters in the
mailbox. Then the client asks for the data to be sent by issuing the
RCEV command. The server responds by sending the mail data. When
all the data has been received the client sends the RCVD command. If
the transaction started with the RDEL command the server now deletes
the mail data from the mailbox. In any case, the server closes and
unlocks the mailbox. The client terminates the session with the QUIT
command.
The Normal Scenario
Client Server
------ ------
Wait for Connection
Open Connection -->
<-- +OK
Wait for Command
USER Fred -->
<-- +OK
Wait for Command
PASS password -->
<-- +OK
Wait for Command
RDEL mailbox --> (open and lock mailbox)
<-- #xxx
Wait for Command
RCEV -->
<-- (send a copy of mail)
Wait for Command
RCVD --> (deletes mail from mailbox, unlock
and close mailbox)
<-- +OK
Wait for Command
QUIT -->
<-- +OK
Close connection --> <-- Close connection
Wait for Connection (go back to start)
Definitions of Commands and Replies
Summary of Commands and Replies
Commands Replies
-------- -------
USER name +OK
PASS password -Error
RETR mailbox #xxx
RDEL mailbox
RCEV
RCVD
QUIT
NOOP
RSET
Commands
USER name
This command identifies the user to the server. It must be
followed by the PASS command.
Possible responses: "+OK" or "-ERR"
PASS password
The PASS command carries the password authenticating this user.
Together the USER name and PASS password are used by the server
to control access to the mailboxes.
Possible responses: "+OK" or "-ERR"
RETR mailbox
This command begins a mail reading transaction. The RETR
command is used to read all the messages in a mailbox without
deleting them. It must be followed by the RCEV command.
Possible responses: "#xxx" or "-ERR"
RDEL mailbox
This command begins a mail reading transaction. The RDEL
command is used to read all the messages in a mailbox and
delete them. It must be followed by the RCEV command.
Possible responses: "#xxx" or "-ERR"
RCEV
This command confirms that the client is ready to receive the
mail data. It must be followed by the RCVD command.
Possible responses: "+OK" or (connection aborted)
RCVD
This command confirms that the client has received and accepted
the mail. The RCVD command ends the mail reading transaction.
In the case of the RDEL transaction, it is possible that the
mail is not necessarily deleted. This is indicated by an error
reply.
Possible responses: "+OK" or "-ERR"
QUIT
This command indicates the client is done with the session.
The server sends an OK response and then closes the connection.
Possible responses: "+OK" then Close
NOOP
This is the no operation command. It causes no action on the
part of the server except an OK response.
Possible response: "+OK"
RSET
This command causes the server to abort the current transaction
and return to waiting for a command (one of RDEL, RETR, QUIT,
NOOP, or RSET). When aborting a transaction the server must
take care to properly close and unlock the mailbox.
Possible response: "+OK"
Acknowledgment
I would like to acknowledge the contributions of Jon Postel, Joel
Goldberger, Dale Chase, and Michael Butler in the development of the
Post Office Protocol.
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.
Diagram
+---+ +---+ +---+ +---+ +---+
Open | | +OK | | | | +OK | | | | +OK
----->| S |--+-->| C |------>| S |------>| C |------>| S |---->+
| | ^ | | USER | | | | PASS | | |
+---+ | +---+ +---+ +---+ +---+ |
| | -ERR | -ERR |
| V V |
+<-----------+<----------------+<----------------------+ |
| |
V +---+ +---+ |
+----->| | QUIT | | +OK |
| C |------>| S |----->Close |
+----->| | | | |
^ +---+ +---+ |
| V
+<-------------------------------------------------------------+
| ^
| +---+ +---+ +---+ +---+ +---+ +---+ |
| | |RETR | | #xxx | |RECV | |DATA | |RCVD | |+OK |
+->| C |---->| S |----->| C |---->| S |---->| C |---->| S |--->+
| | | or | | | | | | | | | | ^
| +---+ RDEL+---+ +---+ +---+ +---+ +---+ |
| | -ERR | | | | -ERR |
| V | V | | |
+<-------------+ | Abort | | |
| V V V |
| +<---------------+-------------------+ +----->+
| V
| +---+ +---+
| | | RSET | | +OK
+----->| C |------>| S |----->+
| | | | | |
| +---+ +---+ |
| V
+<----------------------------+
| ^
| +---+ +---+ |
| | | NOOP | | +OK |
+----->| C |------>| S |----->+
| | | |
+---+ +---+
AI ELI5
On this page
§1Purpose and Design
RFC 918 specifies the Post Office Protocol (POP), a simple method for workstations to dynamically access mail from a mailbox server. POP is intended as a companion to SMTP (Simple Mail Transfer Protocol): SMTP sends mail from a workstation to the mail server, while POP retrieves mail from the server back to the workstation.
The protocol is transaction-based: the client authenticates with username and password, selects a mailbox for reading with either RETR (read without deleting) or RDEL (read and delete), requests the mail data, and ends the session. The server locks the mailbox during the transaction to prevent concurrent access.
The protocol is simple: connect, log in, pick a mailbox, download all the mail, and disconnect. The mail can stay on the server or be deleted.
§2Commands and Protocol Flow
The client opens a TCP connection and waits for the server's greeting message. It then authenticates using USER <name> followed by PASS <password>, with the server responding +OK or -ERR to each. The client requests mail retrieval with either RETR <mailbox> (read without deleting) or RDEL <mailbox> (read and delete), and the server responds with #xxx showing the character count.
The client sends RCEV to request transmission of the mail data, the server sends the mail contents, and the client sends RCVD to confirm receipt. For RDEL transactions, RCVD triggers the actual deletion. The client may also send NOOP (no operation) or RSET (reset transaction), and ends with QUIT to close the connection.
The commands are: USER and PASS to log in, RETR or RDEL to select a mailbox, RCEV to ask for the mail, RCVD to confirm you got it, and QUIT to disconnect.
- Open connection
- +OK (greeting)
- USER name
- +OK
- PASS password
- +OK
- RETR mailbox
- #xxx (byte count)
- RCEV
- (mail data)
- RCVD
- +OK
- QUIT
- +OK
§3Simplicity and Limitations
RFC 918 emphasizes simplicity: the protocol uses plain text commands, takes only a few commands to complete a transaction, and requires minimal parsing. The server is stateless between transactions. All mail in a selected mailbox must be retrieved together; there is no way to request individual messages or to examine a message list first.
The mailbox is locked during the transaction to prevent the mail server and client from interfering with each other. However, there is no mechanism to selectively retrieve messages, flag them for deletion, or maintain state between sessions. These limitations motivated improvements in later versions of the protocol.
The protocol is simple but limited: you get everything from a mailbox at once. You cannot pick specific messages or leave mail partially read.