Post Office Protocol: Version 3
RFC 1081

Document Type RFC - Unknown (November 1988; No errata)
Obsoleted by RFC 1225
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1081 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                            M. Rose
Request for Comments: 1081                                           TWG
                                                           November 1988

                    Post Office Protocol - Version 3

Status of this Memo

   This memo suggests a simple method for workstations to dynamically
   access mail from a mailbox server.  This RFC specifies a proposed
   protocol for the Internet community, and requests discussion and
   suggestions for improvements.  Distribution of this memo is
   unlimited.

   This memo is based on RFC 918 (since revised as RFC 937).  Although
   similar in form to the original Post Office Protocol (POP) proposed
   for the Internet community, the protocol discussed in this memo is
   similar in spirit to the ideas investigated by the MZnet project at
   the University of California, Irvine.

   Further, substantial work was done on examining POP in a PC-based
   environment.  This work, which resulted in additional functionality
   in this protocol, was performed by the ACIS Networking Systems Group
   at Stanford University.  The author gratefully acknowledges their
   interest.

Introduction

   On certain types of smaller nodes in the Internet it is often
   impractical to maintain a message transport system (MTS).  For
   example, a workstation may not have sufficient resources (cycles,
   disk space) in order to permit a SMTP server and associated local
   mail delivery system to be kept resident and continuously running.
   Similarly, it may 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 "connectivity").

   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 a server
   host in a useful fashion.  Usually, this means that the POP3 is used
   to allow a workstation to retrieve mail that the server is holding
   for it.

Rose                                                            [Page 1]
RFC 1081                          POP3                     November 1988

   For the remainder of this memo, the term "client host" refers to a
   host making use of the POP3 service, while the term "server host"
   refers to a host which offers the POP3 service.

A Short Digression

   This memo does not specify how a client host enters mail into the
   transport system, although a method consistent with the philosophy of
   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 (this relay host could be, but need not be, the
      POP3 server host for the client host).

   If this method is followed, then the client host appears to the MTS
   as a user agent, and should NOT be regarded as a "trusted" MTS entity
   in any sense whatsoever.  This concept, along with the role of the
   POP3 as a part of a split-UA model is discussed later in this memo.

   Initially, the server host starts the POP3 service by listening on
   TCP port 110.  When a client host wishes to make use of the service,
   it establishes a TCP connection with the server host.  When the
   connection is established, the POP3 server sends a greeting.  The
   client and POP3 server then exchange commands and responses
   (respectively) until the connection is closed or aborted.

   Commands in the POP3 consist of a keyword possibly followed by an
   argument.  All commands are terminated by a CRLF pair.

   Responses in the POP3 consist of a success indicator and a keyword
   possibly followed by additional information.  All responses are
   terminated by a CRLF pair.  There are currently two success
   indicators: positive ("+OK") and negative ("-ERR").

   Responses to certain commands are multi-line.  In these cases, which
   are clearly indicated below, after sending the first line of the
   response and a CRLF, any additional lines are sent, each terminated
   by a CRLF pair.  When all lines of the response have been sent, a
   final line is sent, consisting of a termination octet (decimal code
   046, ".") and a CRLF pair.  If any line of the multi-line response
   begins with the termination octet, the line is "byte-stuffed" by
   pre-pending the termination octet to that line of the response.
   Hence a multi-line response is terminated with the five octets
   "CRLF.CRLF".  When examining a multi-line response, the client checks
   to see if the line begins with the termination octet.  If so and if
   octets other than CRLF follow, the the first octet of the line (the
Show full document text