Post Office Protocol - Version 3
RFC 1725

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                           J. Myers
Request for Comments: 1725                               Carnegie Mellon
Obsoletes: 1460                                                  M. Rose
Category: Standards Track                   Dover Beach Consulting, Inc.
                                                           November 1994

                    Post Office Protocol - Version 3

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.

Overview

   This memo is a revision to RFC 1460, a Draft Standard.  It makes the
   following changes from that document:

      - removed text regarding "split-UA model", which didn't add
        anything to the understanding of POP

      - clarified syntax of commands, keywords, and arguments

      - clarified behavior on broken connection

      - explicitly permitted an inactivity autologout timer

      - clarified the requirements of the "exclusive-access lock"

      - removed implementation-specific wording regarding the parsing of
        the maildrop

      - allowed servers to close the connection after a failed
        authentication command

      - removed the LAST command

      - fixed typo in example of TOP command

      - clarified that the second argument to the TOP command is non-
        negative

      - added the optional UIDL command

Myers & Rose                                                    [Page 1]
RFC 1725                          POP3                     November 1994

      - added warning regarding length of shared secrets with APOP

      - added additional warnings to the security considerations section

1. 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 [RFC821] 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.

   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.

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 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).

3. Basic Operation

   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

Myers & Rose                                                    [Page 2]
RFC 1725                          POP3                     November 1994

   (respectively) until the connection is closed or aborted.

   Commands in the POP3 consist of a keyword, possibly followed by one
   or more arguments.  All commands are terminated by a CRLF pair.
   Keywords and arguments consist of printable ASCII characters.
   Keywords and arguments are each separated by a single SPACE
   character.  Keywords are three or four characters long. Each argument
   may be up to 40 characters long.

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

   Responses to certain commands are multi-line.  In these cases, which