|Post Office Protocol - Version 3 (POP3)||RFC 1939 POP3 May 1996|
Table of Contents
Group J. Myers
Request for Comments: 1939 Carnegie Mellon
STD: 53 M. Rose
Obsoletes: 1725 Dover Beach Consulting, Inc.
Category: Standards Track May 1996
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Myers & Rose Standards Track
|1. Introduction||On certain types of smaller nodes in the Internet it
impractical to maintain a message transport system (MTS).
example, a workstation may not have sufficient resources
(cycles, disk space) in order to permit a SMTP server
[RFC821] and associated local mail delivery system to
be kept resident and continuously running. Similarly, it
be expensive (or impossible) to keep a personal computer
interconnected to an IP-style network for long amounts of
time (the node is lacking the resource known as
Despite this, it is often very useful to be able to manage mail on these smaller nodes, and they often support a user agent (UA) to aid the tasks of mail handling. To solve this problem, a node which can support an MTS entity offers a maildrop service to these less endowed nodes.
The Post Office
Protocol - Version 3 (POP3) is intended to
permit a workstation to dynamically access a maildrop on
server host in a useful fashion. Usually, this means that
protocol is used to allow a workstation to retrieve mail
server is holding for it.
|2. A Short Digression||This memo does not specify how a client host enters
mail into the
transport system, although a method consistent with the
this memo is presented here:
When the user agent on a client host wishes to enter a message into the transport system, it establishes an SMTP connection to its relay host and sends all mail to it. This relay host could be, but need not be, the POP3 server host for the client host. Of course, the relay host must accept mail for delivery to arbitrary recipient addresses, that functionality is not required of all SMTP servers.
|3. Basic Operation||Initially, the server host starts the POP3 service by
TCP port 110. When a client host wishes to make use of
it establishes a TCP connection with the server host.
connection is established, the POP3 server sends a
client and POP3 server then exchange commands and responses (respectively) until the connection is closed or aborted.
Commands in the POP3 consist of :
Responses in the POP3 consist of a status indicator
and a keyword
possibly followed by additional information. All
terminated by a CRLF pair. Responses may be up to 512
There are currently two status indicators:
Servers MUST send the "+OK" and
"-ERR" in upper case.
Responses to certain commands are multi-line. In these
are clearly indicated below, after sending the first line
response and a CRLF, any additional lines are sent, each
by a CRLF pair. When all lines of the response have been
A POP3 session progresses through a number of states
lifetime. Once the TCP connection has been opened and the
server has sent the greeting, the session enters the AUTHORIZATION
state. In this state, the client must identify itself to
A server MUST respond to an unrecognized,
syntactically invalid command by responding with a
indicator. A server MUST respond to a command issued when
|4. The AUTHORIZATION State||Once the TCP connection has been opened
by a POP3 client, the POP3
server issues a one line greeting. This can be any
response. An example might be:
S: +OK POP3 server ready
The POP3 session is now in the AUTHORIZATION state. The client must now identify and authenticate itself to the POP3 server. Two possible mechanisms for doing this are described in this document, the USER and PASS command combination and the APOP command. Both mechanisms are described later in this document. Additional authentication mechanisms are described in [RFC1734]. While there is no single authentication mechanism that is required of all POP3 servers, a POP3 server must of course support at least one authentication mechanism.
Once the POP3 server has determined through the use of any authentication command that the client should be given access to the appropriate maildrop, the POP3 server then acquires an exclusive-access lock on the maildrop, as necessary to prevent messages from
being modified or removed before the session enters the UPDATE state.
If the lock is successfully acquired, the POP3 server responds with a positive status indicator. The POP3 session now enters the TRANSACTION state, with no messages marked as deleted. If the maildrop cannot be opened for some reason (for example, a lock can
not be acquired, the client is denied access to the appropriate maildrop, or the maildrop cannot be parsed), the POP3 server responds with a negative status indicator. (If a lock was acquired but the
POP3 server intends to respond with a negative status indicator, the POP3 server must release the lock prior to rejecting the command.)
After returning a negative status indicator, the server may close the connection. If the server does not close the connection, the client may either issue a new authentication command and start again, or the client may issue the QUIT command.
After the POP3 server has opened the maildrop, it assigns a message-number to each message, and notes the size of each message in octets.
The first message in the maildrop is assigned a message-number of "1", the second is assigned "2", and so on, so that the nth message in a maildrop is assigned a message-number of "n". In POP3 commands and responses, all message-numbers and message sizes are expressed in base-10 (i.e., decimal).
Here is the summary for the QUIT command when used in the AUTHORIZATION state:
|5. The TRANSACTION State||Once the client has successfully identified itself to
the POP3 server
and the POP3 server has locked and opened the appropriate
the POP3 session is now in the TRANSACTION state. The
client may now
issue any of the following POP3 commands repeatedly.
command, the POP3 server issues a response. Eventually,
issues the QUIT command and the POP3 session enters the
Here are the POP3 commands valid in the TRANSACTION state:
|6. The UPDATE State||When the client issues the QUIT command from the
the POP3 session enters the UPDATE state. (Note that if
issues the QUIT command from the AUTHORIZATION state, the
session terminates but does NOT enter the UPDATE state.)
If a session terminates for some reason other than a client-issued QUIT command, the POP3 session does NOT enter the UPDATE state and MUST not remove any messages from the maildrop.
|7. Optional POP3 Commands||The POP3 commands discussed above must be supported
by all minimal
implementations of POP3 servers.
The optional POP3 commands described below permit a POP3 client greater freedom in message handling, while preserving a simple POP3 server implementation.
NOTE: This memo STRONGLY encourages implementations to support these commands in lieu of developing augmented drop and scan listings. In short, the philosophy of this memo is to put intelligence in the part of the POP3 client and not the POP3 server.
|8. Scaling and
|Since some of the optional features described above
were added to the
POP3 protocol, experience has accumulated in using them
in large-scale commercial post office operations where most of the
unrelated to each other. In these situations and others, users and vendors of POP3 clients have discovered that the combination of using the UIDL command and not issuing the DELE command can provide a weak
version of the "maildrop as semi-permanent repository" functionality normally associated with IMAP. Of course the other capabilities of IMAP, such as polling an existing connection for newly arrived messages and supporting multiple folders on the server, are not
present in POP3.
When these facilities are used in this way by casual users, there has been a tendency for already-read messages to accumulate on the server without bound. This is clearly an undesirable behavior pattern from
the standpoint of the server operator. This situation is aggravated by the fact that the limited capabilities of the POP3 do not permit efficient handling of maildrops which have hundreds or thousands of messages.
Consequently, it is recommended that operators of large-scale multi-user servers, especially ones in which the user's only access to the maildrop is via POP3, consider such options as:
* Imposing a per-user maildrop storage quota or the like.
A disadvantage to this option is that accumulation of messages may result in the user's inability to receive new ones into the maildrop. Sites which choose this option should be sure to inform users of impending or current exhaustion of quota, perhaps by inserting an appropriate message into the user's maildrop.
* Enforce a site policy regarding mail retention on the server.
Sites are free to establish local policy regarding the storage and retention of messages on the server, both read and unread. For example, a site might delete unread messages from the server after 60 days and delete read messages after 7 days. Such message
deletions are outside the scope of the POP3 protocol and are not considered a protocol violation.
Server operators enforcing message deletion policies should take care to make all users aware of the policies in force.
Clients must not assume that a site policy will automate message deletions, and should continue to explicitly delete messages using the DELE command when appropriate.
It should be noted that enforcing site message deletion policies may be confusing to the user community, since their POP3 client may contain configuration options to leave mail on the server which will not in fact be supported by the server.
One special case of a site policy is that messages may only be downloaded once from the server, and are deleted after this has been accomplished. This could be implemented in POP3 server software by the following mechanism: "following a POP3 login by a client which was ended by a QUIT, delete all messages downloaded during the session with the RETR command". It is important not to delete messages in the event of abnormal connection termination
(ie, if no QUIT was received from the client) because the client may not have successfully received or stored the messages.
Servers implementing a download-and-delete policy may also wish to disable or limit the optional TOP command, since it could be used as an alternate mechanism to download entire messages.
|9. POP3 Command Summary||Minimal POP3 Commands:
USER name valid in the AUTHORIZATION state
STAT valid in the TRANSACTION state
Optional POP3 Commands:
APOP name digest valid in the AUTHORIZATION state
TOP msg n valid in the TRANSACTION state
Note that with the exception of the STAT, LIST, and UIDL commands, the reply given by the POP3 server to any command is significant only to "+OK" and "-ERR". Any text occurring after this reply may be ignored by the client.
|10. Example POP3 Session||S: <wait for connection on TCP port 110>
C: <open connection>
S: +OK POP3 server ready <email@example.com>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK mrose's maildrop has 2 messages (320 octets)
S: +OK 2 320
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends message 1>
C: DELE 1
S: +OK message 1 deleted
C: RETR 2
S: +OK 200 octets
S: <the POP3 server sends message 2>
C: DELE 2
S: +OK message 2 deleted
S: +OK dewey POP3 server signing off (maildrop empty)
C: <close connection>
S: <wait for next connection>
|11. Message Format||All messages transmitted during a POP3 session are
assumed to conform
to the standard for the format of Internet text messages
It is important to note that the octet count for a
message on the
server host may differ from the octet count assigned to
due to local conventions for designating end-of-line.
during the AUTHORIZATION state of the POP3 session, the
can calculate the size of each message in octets when it
maildrop. For example, if the POP3 server host internally represents end-of-line as a single character, then the POP3 server simply counts each occurrence of this character in a message as two octets.
Note that lines in the message which start with the termination octet need not (and must not) be counted twice, since the POP3 client will remove all byte-stuffed termination characters when it receives a
|13. Security Considerations||It is conjectured that use of the APOP command
identification and replay protection for a POP3 session.
Accordingly, a POP3 server which implements both the PASS
commands should not allow both methods of access for a
that is, for a given mailbox name, either the USER/PASS
sequence or the APOP command is allowed, but not both.
Further, note that as the length of the shared secret increases, so does the difficulty of deriving it.
Servers that answer -ERR to the USER command are giving potential attackers clues about which names are valid.
Use of the PASS command sends passwords in the clear over the network.
Use of the RETR and TOP commands sends mail in the clear over the network.
Otherwise, security issues are not discussed in this memo.
|14. Acknowledgements||The POP family has a long and checkered
history. Although primarily
a minor revision to RFC 1460, POP3 is based on the ideas
RFCs 918, 937, and 1081.
In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff provided significant comments on the APOP command.
|15. Authors' Addresses||John G. Myers
5000 Forbes Ave
Pittsburgh, PA 15213
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
|This memo is a revision to RFC 1725, a
Draft Standard. It makes the
following changes from that document:
- clarifies that command keywords are case insensitive.
- specifies that servers must send "+OK" and "-ERR" in upper case.
- specifies that the initial greeting is a positive response, instead of any string which should be a positive response.
- clarifies behavior for unimplemented commands.
- makes the USER and PASS commands optional.
- clarified the set of possible responses to the USER command.
- reverses the order of the examples in the USER and PASS
commands, to reduce confusion.
- clarifies that the PASS command may only be given immediately
after a successful USER command.
- clarified the persistence requirements of UIDs and added some
- specifies a UID length limitation of one to 70 octets.
- specifies a status indicator length limitation
of 512 octets, including the CRLF.
- clarifies that LIST with no arguments on an empty mailbox returns success.
- adds a reference from the LIST command to the Message Format section
- clarifies the behavior of QUIT upon failure
- clarifies the security section to not imply the use of the
USER command with the APOP command.
- adds references to RFCs 1730 and 1734
- clarifies the method by which a UA may enter mail into the transport system.
- clarifies that the second argument to the TOP command is a number of lines.
- changes the suggestion in the Security Considerations section for a server to not accept both PASS and APOP for a given user from a "must" to a "should".
- adds a section on scaling and operational considerations
|Appendix B. Command Index||APOP