Skip to content

John McEleney / mailutils

Go to a project
Toggle navigation
Toggle navigation pinning
Commit 98aaefb7 98aaefb7ae3d117ec50d14a5fe517852e8ae80b5 by Jeff Bailey
Options

Add rfcs to doc directory

1 parent 5f3d0446
Inline Side-by-side
Showing 6 changed files with 2760 additions and 0 deletions
1999-11-21 Jeff Bailey <jbailey@nisa.net>
* doc/rfc*: Add. Standards followed should be included here.
1999-11-23 Jakob 'sparky' Kaivo <jkaivo@elijah.nodomainname.net>
* TODO: Mention Maildir
......
Network Working Group J. Myers
Request for Comments: 1734 Carnegie Mellon
Category: Standards Track December 1994
POP3 AUTHentication command
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.
1. Introduction
This document describes the optional AUTH command, for indicating an
authentication mechanism to the server, performing an authentication
protocol exchange, and optionally negotiating a protection mechanism
for subsequent protocol interactions. The authentication and
protection mechanisms used by the POP3 AUTH command are those used by
IMAP4.
2. The AUTH command
AUTH mechanism
Arguments:
a string identifying an IMAP4 authentication mechanism,
such as defined by [IMAP4-AUTH]. Any use of the string
"imap" used in a server authentication identity in the
definition of an authentication mechanism is replaced with
the string "pop".
Restrictions:
may only be given in the AUTHORIZATION state
Discussion:
The AUTH command indicates an authentication mechanism to
the server. If the server supports the requested
authentication mechanism, it performs an authentication
protocol exchange to authenticate and identify the user.
Optionally, it also negotiates a protection mechanism for
subsequent protocol interactions. If the requested
authentication mechanism is not supported, the server
Myers [Page 1]
RFC 1734 POP3 AUTH December 1994
should reject the AUTH command by sending a negative
response.
The authentication protocol exchange consists of a series
of server challenges and client answers that are specific
to the authentication mechanism. A server challenge,
otherwise known as a ready response, is a line consisting
of a "+" character followed by a single space and a BASE64
encoded string. The client answer consists of a line
containing a BASE64 encoded string. If the client wishes
to cancel an authentication exchange, it should issue a
line with a single "*". If the server receives such an
answer, it must reject the AUTH command by sending a
negative response.
A protection mechanism provides integrity and privacy
protection to the protocol session. If a protection
mechanism is negotiated, it is applied to all subsequent
data sent over the connection. The protection mechanism
takes effect immediately following the CRLF that concludes
the authentication exchange for the client, and the CRLF of
the positive response for the server. Once the protection
mechanism is in effect, the stream of command and response
octets is processed into buffers of ciphertext. Each
buffer is transferred over the connection as a stream of
octets prepended with a four octet field in network byte
order that represents the length of the following data.
The maximum ciphertext buffer length is defined by the
protection mechanism.
The server is not required to support any particular
authentication mechanism, nor are authentication mechanisms
required to support any protection mechanisms. If an AUTH
command fails with a negative response, the session remains
in the AUTHORIZATION state and client may try another
authentication mechanism by issuing another AUTH command,
or may attempt to authenticate by using the USER/PASS or
APOP commands. In other words, the client may request
authentication types in decreasing order of preference,
with the USER/PASS or APOP command as a last resort.
Should the client successfully complete the authentication
exchange, the POP3 server issues a positive response and
the POP3 session enters the TRANSACTION state.
Possible Responses:
+OK maildrop locked and ready
-ERR authentication exchange failed
Myers [Page 2]
RFC 1734 POP3 AUTH December 1994
Examples:
S: +OK POP3 server ready
C: AUTH KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: +OK Kerberos V4 authentication successful
...
C: AUTH FOOBAR
S: -ERR Unrecognized authentication type
Note: the line breaks in the first client answer are
for editorial clarity and are not in real authentica-
tors.
Myers [Page 3]
RFC 1734 POP3 AUTH December 1994
3. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in RFC 822.
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
ATOM_CHAR ::= <any CHAR except atom_specials>
atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" /
<"> / "\"
auth ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64)
CRLF
auth_type ::= 1*ATOM_CHAR
base64 ::= *(4base64_CHAR) [base64_terminal]
base64_char ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
"I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
"Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
"Y" / "Z" /
"a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
"i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
"q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
"y" / "z" /
"0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
"8" / "9" / "+" / "/"
;; Case-sensitive
base64_terminal ::= (2base64_char "==") / (3base64_char "=")
CHAR ::= <any 7-bit US-ASCII character except NUL,
0x01 - 0x7f>
continue_req ::= "+" SPACE base64 CRLF
CR ::= <ASCII CR, carriage return, 0x0C>
CRLF ::= CR LF
CTL ::= <any ASCII control character and DEL,
0x00 - 0x1f, 0x7f>
Myers [Page 4]
RFC 1734 POP3 AUTH December 1994
LF ::= <ASCII LF, line feed, 0x0A>
SPACE ::= <ASCII SP, space, 0x20>
TAB ::= <ASCII HT, tab, 0x09>
4. References
[IMAP4-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
Carnegie Mellon, December 1994.
5. Security Considerations
Security issues are discussed throughout this memo.
6. Author's Address
John G. Myers
Carnegie-Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
EMail: jgm+@cmu.edu
Myers [Page 5]
Network Working Group J. Myers
Request for Comments: 1939 Carnegie Mellon
STD: 53 M. Rose
Obsoletes: 1725 Dover Beach Consulting, Inc.
Category: Standards Track May 1996
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.
Table of Contents
1. Introduction ................................................ 2
2. A Short Digression .......................................... 2
3. Basic Operation ............................................. 3
4. The AUTHORIZATION State ..................................... 4
QUIT Command ................................................ 5
5. The TRANSACTION State ....................................... 5
STAT Command ................................................ 6
LIST Command ................................................ 6
RETR Command ................................................ 8
DELE Command ................................................ 8
NOOP Command ................................................ 9
RSET Command ................................................ 9
6. The UPDATE State ............................................ 10
QUIT Command ................................................ 10
7. Optional POP3 Commands ...................................... 11
TOP Command ................................................. 11
UIDL Command ................................................ 12
USER Command ................................................ 13
PASS Command ................................................ 14
APOP Command ................................................ 15
8. Scaling and Operational Considerations ...................... 16
9. POP3 Command Summary ........................................ 18
10. Example POP3 Session ....................................... 19
11. Message Format ............................................. 19
12. References ................................................. 20
13. Security Considerations .................................... 20
14. Acknowledgements ........................................... 20
15. Authors' Addresses ......................................... 21
Appendix A. Differences from RFC 1725 .......................... 22
Myers & Rose Standards Track [Page 1]
RFC 1939 POP3 May 1996
Appendix B. Command Index ...................................... 23
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 protocol
is used to allow a workstation to retrieve mail that the server is
holding for it.
POP3 is not intended to provide extensive manipulation operations of
mail on the server; normally, mail is downloaded and then deleted. A
more advanced (and complex) protocol, IMAP4, is discussed in
[RFC1730].
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 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.
Myers & Rose Standards Track [Page 2]
RFC 1939 POP3 May 1996
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
(respectively) until the connection is closed or aborted.
Commands in the POP3 consist of a case-insensitive 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. Responses may be up to 512 characters
long, including the terminating CRLF. There are currently two status
indicators: positive ("+OK") and negative ("-ERR"). Servers MUST
send the "+OK" and "-ERR" in upper case.
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 first octet of the line (the
termination octet) is stripped away. If so and if CRLF immediately
follows the termination character, then the response from the POP
server is ended and the line containing ".CRLF" is not considered
part of the multi-line response.
A POP3 session progresses through a number of states during its
lifetime. Once the TCP connection has been opened and the POP3
server has sent the greeting, the session enters the AUTHORIZATION
state. In this state, the client must identify itself to the POP3
server. Once the client has successfully done this, the server
acquires resources associated with the client's maildrop, and the
session enters the TRANSACTION state. In this state, the client
requests actions on the part of the POP3 server. When the client has
Myers & Rose Standards Track [Page 3]
RFC 1939 POP3 May 1996
issued the QUIT command, the session enters the UPDATE state. In
this state, the POP3 server releases any resources acquired during
the TRANSACTION state and says goodbye. The TCP connection is then
closed.
A server MUST respond to an unrecognized, unimplemented, or
syntactically invalid command by responding with a negative status
indicator. A server MUST respond to a command issued when the
session is in an incorrect state by responding with a negative status
indicator. There is no general method for a client to distinguish
between a server which does not implement an optional command and a
server which is unwilling or unable to process the command.
A POP3 server MAY have an inactivity autologout timer. Such a timer
MUST be of at least 10 minutes' duration. The receipt of any command
from the client during that interval should suffice to reset the
autologout timer. When the timer expires, the session does NOT enter
the UPDATE state--the server should close the TCP connection without
removing any messages or sending any response to the client.
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 positive
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
Myers & Rose Standards Track [Page 4]
RFC 1939 POP3 May 1996
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:
QUIT
Arguments: none
Restrictions: none
Possible Responses:
+OK
Examples:
C: QUIT
S: +OK dewey POP3 server signing off
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 maildrop,
the POP3 session is now in the TRANSACTION state. The client may now
issue any of the following POP3 commands repeatedly. After each
command, the POP3 server issues a response. Eventually, the client
issues the QUIT command and the POP3 session enters the UPDATE state.
Myers & Rose Standards Track [Page 5]
RFC 1939 POP3 May 1996
Here are the POP3 commands valid in the TRANSACTION state:
STAT
Arguments: none
Restrictions:
may only be given in the TRANSACTION state
Discussion:
The POP3 server issues a positive response with a line
containing information for the maildrop. This line is
called a "drop listing" for that maildrop.
In order to simplify parsing, all POP3 servers are
required to use a certain format for drop listings. The
positive response consists of "+OK" followed by a single
space, the number of messages in the maildrop, a single
space, and the size of the maildrop in octets. This memo
makes no requirement on what follows the maildrop size.
Minimal implementations should just end that line of the
response with a CRLF pair. More advanced implementations
may include other information.
NOTE: This memo STRONGLY discourages implementations
from supplying additional information in the drop
listing. Other, optional, facilities are discussed
later on which permit the client to parse the messages
in the maildrop.
Note that messages marked as deleted are not counted in
either total.
Possible Responses:
+OK nn mm
Examples:
C: STAT
S: +OK 2 320
LIST [msg]
Arguments:
a message-number (optional), which, if present, may NOT
refer to a message marked as deleted
Myers & Rose Standards Track [Page 6]
RFC 1939 POP3 May 1996
Restrictions:
may only be given in the TRANSACTION state
Discussion:
If an argument was given and the POP3 server issues a
positive response with a line containing information for
that message. This line is called a "scan listing" for
that message.
If no argument was given and the POP3 server issues a
positive response, then the response given is multi-line.
After the initial +OK, for each message in the maildrop,
the POP3 server responds with a line containing
information for that message. This line is also called a
"scan listing" for that message. If there are no
messages in the maildrop, then the POP3 server responds
with no scan listings--it issues a positive response
followed by a line containing a termination octet and a
CRLF pair.
In order to simplify parsing, all POP3 servers are
required to use a certain format for scan listings. A
scan listing consists of the message-number of the
message, followed by a single space and the exact size of
the message in octets. Methods for calculating the exact
size of the message are described in the "Message Format"
section below. This memo makes no requirement on what
follows the message size in the scan listing. Minimal
implementations should just end that line of the response
with a CRLF pair. More advanced implementations may
include other information, as parsed from the message.
NOTE: This memo STRONGLY discourages implementations
from supplying additional information in the scan
listing. Other, optional, facilities are discussed
later on which permit the client to parse the messages
in the maildrop.
Note that messages marked as deleted are not listed.
Possible Responses:
+OK scan listing follows
-ERR no such message
Examples:
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
Myers & Rose Standards Track [Page 7]
RFC 1939 POP3 May 1996
S: 2 200
S: .
...
C: LIST 2
S: +OK 2 200
...
C: LIST 3
S: -ERR no such message, only 2 messages in maildrop
RETR msg
Arguments:
a message-number (required) which may NOT refer to a
message marked as deleted
Restrictions:
may only be given in the TRANSACTION state
Discussion:
If the POP3 server issues a positive response, then the
response given is multi-line. After the initial +OK, the
POP3 server sends the message corresponding to the given
message-number, being careful to byte-stuff the termination
character (as with all multi-line responses).
Possible Responses:
+OK message follows
-ERR no such message
Examples:
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .
DELE msg
Arguments:
a message-number (required) which may NOT refer to a
message marked as deleted
Restrictions:
may only be given in the TRANSACTION state
Myers & Rose Standards Track [Page 8]
RFC 1939 POP3 May 1996
Discussion:
The POP3 server marks the message as deleted. Any future
reference to the message-number associated with the message
in a POP3 command generates an error. The POP3 server does
not actually delete the message until the POP3 session
enters the UPDATE state.
Possible Responses:
+OK message deleted
-ERR no such message
Examples:
C: DELE 1
S: +OK message 1 deleted
...
C: DELE 2
S: -ERR message 2 already deleted
NOOP
Arguments: none
Restrictions:
may only be given in the TRANSACTION state
Discussion:
The POP3 server does nothing, it merely replies with a
positive response.
Possible Responses:
+OK
Examples:
C: NOOP
S: +OK
RSET
Arguments: none
Restrictions:
may only be given in the TRANSACTION state
Discussion:
If any messages have been marked as deleted by the POP3
server, they are unmarked. The POP3 server then replies
Myers & Rose Standards Track [Page 9]
RFC 1939 POP3 May 1996
with a positive response.
Possible Responses:
+OK
Examples:
C: RSET
S: +OK maildrop has 2 messages (320 octets)
6. The UPDATE State
When the client issues the QUIT command from the TRANSACTION state,
the POP3 session enters the UPDATE state. (Note that if the client
issues the QUIT command from the AUTHORIZATION state, the POP3
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.
QUIT
Arguments: none
Restrictions: none
Discussion:
The POP3 server removes all messages marked as deleted
from the maildrop and replies as to the status of this
operation. If there is an error, such as a resource
shortage, encountered while removing messages, the
maildrop may result in having some or none of the messages
marked as deleted be removed. In no case may the server
remove any messages not marked as deleted.
Whether the removal was successful or not, the server
then releases any exclusive-access lock on the maildrop
and closes the TCP connection.
Possible Responses:
+OK
-ERR some deleted messages not removed
Examples:
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
...
C: QUIT
Myers & Rose Standards Track [Page 10]
RFC 1939 POP3 May 1996
S: +OK dewey POP3 server signing off (2 messages left)
...
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.
TOP msg n
Arguments:
a message-number (required) which may NOT refer to to a
message marked as deleted, and a non-negative number
of lines (required)
Restrictions:
may only be given in the TRANSACTION state
Discussion:
If the POP3 server issues a positive response, then the
response given is multi-line. After the initial +OK, the
POP3 server sends the headers of the message, the blank
line separating the headers from the body, and then the
number of lines of the indicated message's body, being
careful to byte-stuff the termination character (as with
all multi-line responses).
Note that if the number of lines requested by the POP3
client is greater than than the number of lines in the
body, then the POP3 server sends the entire message.
Possible Responses:
+OK top of message follows
-ERR no such message
Examples:
C: TOP 1 10
S: +OK
Myers & Rose Standards Track [Page 11]
RFC 1939 POP3 May 1996
S: <the POP3 server sends the headers of the
message, a blank line, and the first 10 lines
of the body of the message>
S: .
...
C: TOP 100 3
S: -ERR no such message
UIDL [msg]
Arguments:
a message-number (optional), which, if present, may NOT
refer to a message marked as deleted
Restrictions:
may only be given in the TRANSACTION state.
Discussion:
If an argument was given and the POP3 server issues a positive
response with a line containing information for that message.
This line is called a "unique-id listing" for that message.
If no argument was given and the POP3 server issues a positive
response, then the response given is multi-line. After the
initial +OK, for each message in the maildrop, the POP3 server
responds with a line containing information for that message.
This line is called a "unique-id listing" for that message.
In order to simplify parsing, all POP3 servers are required to
use a certain format for unique-id listings. A unique-id
listing consists of the message-number of the message,
followed by a single space and the unique-id of the message.
No information follows the unique-id in the unique-id listing.
The unique-id of a message is an arbitrary server-determined
string, consisting of one to 70 characters in the range 0x21
to 0x7E, which uniquely identifies a message within a
maildrop and which persists across sessions. This
persistence is required even if a session ends without
entering the UPDATE state. The server should never reuse an
unique-id in a given maildrop, for as long as the entity
using the unique-id exists.
Note that messages marked as deleted are not listed.
While it is generally preferable for server implementations
to store arbitrarily assigned unique-ids in the maildrop,
Myers & Rose Standards Track [Page 12]
RFC 1939 POP3 May 1996
this specification is intended to permit unique-ids to be
calculated as a hash of the message. Clients should be able
to handle a situation where two identical copies of a
message in a maildrop have the same unique-id.
Possible Responses:
+OK unique-id listing follows
-ERR no such message
Examples:
C: UIDL
S: +OK
S: 1 whqtswO00WBw418f9t5JxYwZ
S: 2 QhdPYR:00WBw1Ph7x7
S: .
...
C: UIDL 2
S: +OK 2 QhdPYR:00WBw1Ph7x7
...
C: UIDL 3
S: -ERR no such message, only 2 messages in maildrop
USER name
Arguments:
a string identifying a mailbox (required), which is of
significance ONLY to the server
Restrictions:
may only be given in the AUTHORIZATION state after the POP3
greeting or after an unsuccessful USER or PASS command
Discussion:
To authenticate using the USER and PASS command
combination, the client must first issue the USER
command. If the POP3 server responds with a positive
status indicator ("+OK"), then the client may issue
either the PASS command to complete the authentication,
or the QUIT command to terminate the POP3 session. If
the POP3 server responds with a negative status indicator
("-ERR") to the USER command, then the client may either
issue a new authentication command or may issue the QUIT
command.
The server may return a positive response even though no
such mailbox exists. The server may return a negative
response if mailbox exists, but does not permit plaintext
Myers & Rose Standards Track [Page 13]
RFC 1939 POP3 May 1996
password authentication.
Possible Responses:
+OK name is a valid mailbox
-ERR never heard of mailbox name
Examples:
C: USER frated
S: -ERR sorry, no mailbox for frated here
...
C: USER mrose
S: +OK mrose is a real hoopy frood
PASS string
Arguments:
a server/mailbox-specific password (required)
Restrictions:
may only be given in the AUTHORIZATION state immediately
after a successful USER command
Discussion:
When the client issues the PASS command, the POP3 server
uses the argument pair from the USER and PASS commands to
determine if the client should be given access to the
appropriate maildrop.
Since the PASS command has exactly one argument, a POP3
server may treat spaces in the argument as part of the
password, instead of as argument separators.
Possible Responses:
+OK maildrop locked and ready
-ERR invalid password
-ERR unable to lock maildrop
Examples:
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: -ERR maildrop already locked
...
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: +OK mrose's maildrop has 2 messages (320 octets)
Myers & Rose Standards Track [Page 14]
RFC 1939 POP3 May 1996
APOP name digest
Arguments:
a string identifying a mailbox and a MD5 digest string
(both required)
Restrictions:
may only be given in the AUTHORIZATION state after the POP3
greeting or after an unsuccessful USER or PASS command
Discussion:
Normally, each POP3 session starts with a USER/PASS
exchange. This results in a server/user-id specific
password being sent in the clear on the network. For
intermittent use of POP3, this may not introduce a sizable
risk. However, many POP3 client implementations connect to
the POP3 server on a regular basis -- to check for new
mail. Further the interval of session initiation may be on
the order of five minutes. Hence, the risk of password
capture is greatly enhanced.
An alternate method of authentication is required which
provides for both origin authentication and replay
protection, but which does not involve sending a password
in the clear over the network. The APOP command provides
this functionality.
A POP3 server which implements the APOP command will
include a timestamp in its banner greeting. The syntax of
the timestamp corresponds to the `msg-id' in [RFC822], and
MUST be different each time the POP3 server issues a banner
greeting. For example, on a UNIX implementation in which a
separate UNIX process is used for each instance of a POP3
server, the syntax of the timestamp might be:
<process-ID.clock@hostname>
where `process-ID' is the decimal value of the process's
PID, clock is the decimal value of the system clock, and
hostname is the fully-qualified domain-name corresponding
to the host where the POP3 server is running.
The POP3 client makes note of this timestamp, and then
issues the APOP command. The `name' parameter has
identical semantics to the `name' parameter of the USER
command. The `digest' parameter is calculated by applying
the MD5 algorithm [RFC1321] to a string consisting of the
timestamp (including angle-brackets) followed by a shared
Myers & Rose Standards Track [Page 15]
RFC 1939 POP3 May 1996
secret. This shared secret is a string known only to the
POP3 client and server. Great care should be taken to
prevent unauthorized disclosure of the secret, as knowledge
of the secret will allow any entity to successfully
masquerade as the named user. The `digest' parameter
itself is a 16-octet value which is sent in hexadecimal
format, using lower-case ASCII characters.
When the POP3 server receives the APOP command, it verifies
the digest provided. If the digest is correct, the POP3
server issues a positive response, and the POP3 session
enters the TRANSACTION state. Otherwise, a negative
response is issued and the POP3 session remains in the
AUTHORIZATION state.
Note that as the length of the shared secret increases, so
does the difficulty of deriving it. As such, shared
secrets should be long strings (considerably longer than
the 8-character example shown below).
Possible Responses:
+OK maildrop locked and ready
-ERR permission denied
Examples:
S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octets)
In this example, the shared secret is the string `tan-
staaf'. Hence, the MD5 algorithm is applied to the string
<1896.697170952@dbc.mtview.ca.us>tanstaaf
which produces a digest value of
c4c9334bac560ecc979e58001b3e22fb
8. Scaling and Operational Considerations
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 users are
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
Myers & Rose Standards Track [Page 16]
RFC 1939 POP3 May 1996
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
Myers & Rose Standards Track [Page 17]
RFC 1939 POP3 May 1996
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
PASS string
QUIT
STAT valid in the TRANSACTION state
LIST [msg]
RETR msg
DELE msg
NOOP
RSET
QUIT
Optional POP3 Commands:
APOP name digest valid in the AUTHORIZATION state
TOP msg n valid in the TRANSACTION state
UIDL [msg]
POP3 Replies:
+OK
-ERR
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.
Myers & Rose Standards Track [Page 18]
RFC 1939 POP3 May 1996
10. Example POP3 Session
S: <wait for connection on TCP port 110>
C: <open connection>
S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK mrose's maildrop has 2 messages (320 octets)
C: STAT
S: +OK 2 320
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends message 1>
S: .
C: DELE 1
S: +OK message 1 deleted
C: RETR 2
S: +OK 200 octets
S: <the POP3 server sends message 2>
S: .
C: DELE 2
S: +OK message 2 deleted
C: QUIT
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 [RFC822].
It is important to note that the octet count for a message on the
server host may differ from the octet count assigned to that message
due to local conventions for designating end-of-line. Usually,
during the AUTHORIZATION state of the POP3 session, the POP3 server
can calculate the size of each message in octets when it opens the
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
multi-line response.
Myers & Rose Standards Track [Page 19]
RFC 1939 POP3 May 1996
12. References
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, USC/Information Sciences Institute, August 1982.
[RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
MIT Laboratory for Computer Science, April 1992.
[RFC1730] Crispin, M., "Internet Message Access Protocol - Version
4", RFC 1730, University of Washington, December 1994.
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
Carnegie Mellon, December 1994.
13. Security Considerations
It is conjectured that use of the APOP command provides origin
identification and replay protection for a POP3 session.
Accordingly, a POP3 server which implements both the PASS and APOP
commands should not allow both methods of access for a given user;
that is, for a given mailbox name, either the USER/PASS command
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 presented in
RFCs 918, 937, and 1081.
In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
provided significant comments on the APOP command.
Myers & Rose Standards Track [Page 20]
RFC 1939 POP3 May 1996
15. Authors' Addresses
John G. Myers
Carnegie-Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
EMail: jgm+@cmu.edu
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
EMail: mrose@dbc.mtview.ca.us
Myers & Rose Standards Track [Page 21]
RFC 1939 POP3 May 1996
Appendix A. Differences from RFC 1725
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
implementation notes.
- 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.
Myers & Rose Standards Track [Page 22]
RFC 1939 POP3 May 1996
- 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 ....................................................... 15
DELE ....................................................... 8
LIST ....................................................... 6
NOOP ....................................................... 9
PASS ....................................................... 14
QUIT ....................................................... 5
QUIT ....................................................... 10
RETR ....................................................... 8
RSET ....................................................... 9
STAT ....................................................... 6
TOP ........................................................ 11
UIDL ....................................................... 12
USER ....................................................... 13
Myers & Rose Standards Track [Page 23]
Network Working Group R. Nelson
Request for Comments: 1957 Crynwr Software
Updates: 1939 June 1996
Category: Informational
Some Observations on Implementations
of the Post Office Protocol (POP3)
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Observations
Sometimes an implementation is mistaken for a standard. POP3 servers
and clients are no exception. The widely-used UCB POP3 server,
popper, which has been further developed by Qualcomm, always has
additional information following the status indicator. So, the
status indicator always has a space following it. Two POP3 clients
have been observed to expect that space, and fail when it has not
been found. The RFC does not require the space, hence this memo.
These clients are the freely copyable Unix "popclient" and the
proprietary "netApp Systems Internet Series". The authors of both of
these have been contacted, and new releases will not expect the
space, but old versions should be supported.
In addition, two popular clients require optional parts of the RFC.
Netscape requires UIDL, and Eudora requires TOP.
The optional APOP authentication command has not achieved wide
penetration yet. Newer versions of the Qualcomm POP server implement
it. Known client implementations of APOP include GNU Emacs VM client
and Eudora Lite and Eudora Pro.
Security Considerations
Security issues are not discussed in this memo.
References
[1] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
Nelson Informational [Page 1]
RFC 1957 Notes on POP3 Implementations June 1996
Author's Address
Russell Nelson
Crynwr Software
521 Pleasant Valley Rd.
Potsdam, NY 13676
Phone: +1.315.268.1925
FAX: +1.315.268.9201
EMail: nelson@crynwr.com
Nelson Informational [Page 2]
This diff could not be displayed because it is too large.
Network Working Group R. Gellens
Request for Comments: 2449 Qualcomm
Updates: 1939 C. Newman
Category: Standards Track Innosoft
L. Lundblade
Qualcomm
November 1998
POP3 Extension Mechanism
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.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
IESG Note
This extension to the POP3 protocol is to be used by a server to
express policy descisions taken by the server administrator. It is
not an endorsement of implementations of further POP3 extensions
generally. It is the general view that the POP3 protocol should stay
simple, and for the simple purpose of downloading email from a mail
server. If more complicated operations are needed, the IMAP protocol
[RFC 2060] should be used. The first paragraph of section 7 should
be read very carefully.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . 3
3. General Command and Response Grammar . . . . . . . . . . . . 3
4. Parameter and Response Lengths . . . . . . . . . . . . . . 4
5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4
6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5
6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6
6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6
6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7
6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8
6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8
6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9
Gellens, et. al. Standards Track [Page 1]
RFC 2449 POP3 Extension Mechanism November 1998
6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10
6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13
6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13
7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14
8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14
8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15
8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15
8.1.2. The IN-USE response code . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
1. Introduction
The Post Office Protocol version 3 [POP3] is very widely used.
However, while it includes some optional commands (and some useful
protocol extensions have been published), it lacks a mechanism for
advertising support for these extensions or for behavior variations.
Currently these optional features and extensions can only be detected
by probing, if at all. This is at best inefficient, and possibly
worse. As a result, some clients have manual configuration options
for POP3 server capabilities.
Because one of the most important characteristics of POP3 is its
simplicity, it is desirable that extensions be few in number (see
section 7). However, some extensions are necessary (such as ones
that provide improved security [POP-AUTH]), while others are very
desirable in certain situations. In addition, a means for
discovering server behavior is needed.
This memo updates RFC 1939 [POP3] to define a mechanism to announce
support for optional commands, extensions, and unconditional server
behavior. Included is an initial set of currently deployed
capabilities which vary between server implementations, and several
new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE
and IMPLEMENTATION). This document also extends POP3 error messages
so that machine parsable codes can be provided to the client. An
initial set of response codes is included. In addition, an [ABNF]
specification of POP3 commands and responses is defined.
Public comments should be sent to the IETF POP3 Extensions mailing
list, <ietf-pop3ext@imc.org>. To subscribe, send a message
containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>.
Gellens, et. al. Standards Track [Page 2]
RFC 2449 POP3 Extension Mechanism November 1998
2. Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
and "MAY" in this document are to be interpreted as described in "Key
words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
3. General Command and Response Grammar
The general form of POP3 commands and responses is described using
[ABNF]:
POP3 commands:
command = keyword *(SP param) CRLF ;255 octets maximum
keyword = 3*4VCHAR
param = 1*VCHAR
POP3 responses:
response = greeting / single-line / capa-resp / multi-line
capa-resp = single-line *capability "." CRLF
capa-tag = 1*cchar
capability = capa-tag *(SP param) CRLF ;512 octets maximum
cchar = %x21-2D / %x2F-7F
;printable ASCII, excluding "."
dot-stuffed = *CHAR CRLF ;must be dot-stuffed
gchar = %x21-3B / %x3D-7F
;printable ASCII, excluding "<"
greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
;512 octets maximum
multi-line = single-line *dot-stuffed "." CRLF
rchar = %x21-2E / %x30-5C / %x5E-7F
;printable ASCII, excluding "/" and "]"
resp-code = "[" resp-level *("/" resp-level) "]"
resp-level = 1*rchar
schar = %x21-5A / %x5C-7F
;printable ASCII, excluding "["
single-line = status [SP text] CRLF ;512 octets maximum
status = "+OK" / "-ERR"
text = *schar / resp-code *CHAR
timestamp = "<" *VCHAR ">"
;MUST conform to RFC-822 msg-id
Gellens, et. al. Standards Track [Page 3]
RFC 2449 POP3 Extension Mechanism November 1998
4. Parameter and Response Lengths
This specification increases the length restrictions on commands and
parameters imposed by RFC 1939.
The maximum length of a command is increased from 47 characters (4
character command, single space, 40 character argument, CRLF) to 255
octets, including the terminating CRLF.
Servers which support the CAPA command MUST support commands up to
255 octets. Servers MUST also support the largest maximum command
length specified by any supported capability.
The maximum length of the first line of a command response (including
the initial greeting) is unchanged at 512 octets (including the
terminating CRLF).
5. The CAPA Command
The POP3 CAPA command returns a list of capabilities supported by the
POP3 server. It is available in both the AUTHORIZATION and
TRANSACTION states.
A capability description MUST document in which states the capability
is announced, and in which states the commands are valid.
Capabilities available in the AUTHORIZATION state MUST be announced
in both states.
If a capability is announced in both states, but the argument might
differ after authentication, this possibility MUST be stated in the
capability description.
(These requirements allow a client to issue only one CAPA command if
it does not use any TRANSACTION-only capabilities, or any
capabilities whose values may differ after authentication.)
If the authentication step negotiates an integrity protection layer,
the client SHOULD reissue the CAPA command after authenticating, to
check for active down-negotiation attacks.
Each capability may enable additional protocol commands, additional
parameters and responses for existing commands, or describe an aspect
of server behavior. These details are specified in the description
of the capability.
Gellens, et. al. Standards Track [Page 4]
RFC 2449 POP3 Extension Mechanism November 1998
Section 3 describes the CAPA response using [ABNF]. When a
capability response describes an optional command, the <capa-tag>
SHOULD be identical to the command keyword. CAPA response tags are
case-insensitive.
CAPA
Arguments:
none
Restrictions:
none
Discussion:
An -ERR response indicates the capability command is not
implemented and the client will have to probe for
capabilities as before.
An +OK response is followed by a list of capabilities, one
per line. Each capability name MAY be followed by a single
space and a space-separated list of parameters. Each
capability line is limited to 512 octets (including the
CRLF). The capability list is terminated by a line
containing a termination octet (".") and a CRLF pair.
Possible Responses:
+OK -ERR
Examples:
C: CAPA
S: +OK Capability list follows
S: TOP
S: USER
S: SASL CRAM-MD5 KERBEROS_V4
S: RESP-CODES
S: LOGIN-DELAY 900
S: PIPELINING
S: EXPIRE 60
S: UIDL
S: IMPLEMENTATION Shlemazle-Plotz-v302
S: .
6. Initial Set of Capabilities
This section defines an initial set of POP3 capabilities. These
include the optional POP3 commands, already published POP3
extensions, and behavior variations between POP3 servers which can
impact clients.
Gellens, et. al. Standards Track [Page 5]
RFC 2449 POP3 Extension Mechanism November 1998
Note that there is no APOP capability, even though APOP is an
optional command in [POP3]. Clients discover server support of APOP
by the presence in the greeting banner of an initial challenge
enclosed in angle brackets ("<>"). Therefore, an APOP capability
would introduce two ways for a server to announce the same thing.
6.1. TOP capability
CAPA tag:
TOP
Arguments:
none
Added commands:
TOP
Standard commands affected:
none
Announced states / possible differences:
both / no
Commands valid in states:
TRANSACTION
Specification reference:
[POP3]
Discussion:
The TOP capability indicates the optional TOP command is
available.
6.2. USER capability
CAPA tag:
USER
Arguments:
none
Added commands:
USER PASS
Standard commands affected:
none
Gellens, et. al. Standards Track [Page 6]
RFC 2449 POP3 Extension Mechanism November 1998
Announced states / possible differences:
both / no
Commands valid in states:
AUTHENTICATION
Specification reference:
[POP3]
Discussion:
The USER capability indicates that the USER and PASS commands
are supported, although they may not be available to all users.
6.3. SASL capability
CAPA tag:
SASL
Arguments:
Supported SASL mechanisms
Added commands:
AUTH
Standard commands affected:
none
Announced states / possible differences:
both / no
Commands valid in states:
AUTHENTICATION
Specification reference:
[POP-AUTH, SASL]
Discussion:
The POP3 AUTH command [POP-AUTH] permits the use of [SASL]
authentication mechanisms with POP3. The SASL capability
indicates that the AUTH command is available and that it supports
an optional base64 encoded second argument for an initial client
response as described in the SASL specification. The argument to
the SASL capability is a space separated list of SASL mechanisms
which are supported.
Gellens, et. al. Standards Track [Page 7]
RFC 2449 POP3 Extension Mechanism November 1998
6.4. RESP-CODES capability
CAPA tag:
RESP-CODES
Arguments:
none
Added commands:
none
Standard commands affected:
none
Announced states / possible differences:
both / no
Commands valid in states:
n/a
Specification reference:
this document
Discussion:
The RESP-CODES capability indicates that any response text issued
by this server which begins with an open square bracket ("[") is
an extended response code (see section 8).
6.5. LOGIN-DELAY capability
CAPA tag:
LOGIN-DELAY
Arguments:
minimum seconds between logins; optionally followed by USER in
AUTHENTICATION state.
Added commands:
none
Standard commands affected:
USER PASS APOP AUTH
Announced states / possible differences:
both / yes
Commands valid in states:
n/a
Gellens, et. al. Standards Track [Page 8]
RFC 2449 POP3 Extension Mechanism November 1998
Specification reference:
this document
Discussion:
POP3 clients often login frequently to check for new mail.
Unfortunately, the process of creating a connection,
authenticating the user, and opening the user's maildrop can be
very resource intensive on the server. A number of deployed POP3
servers try to reduce server load by requiring a delay between
logins. The LOGIN-DELAY capability includes an integer argument
which indicates the number of seconds after an "+OK" response to
a PASS, APOP, or AUTH command before another authentication will
be accepted. Clients which permit the user to configure a mail
check interval SHOULD use this capability to determine the
minimum permissible interval. Servers which advertise LOGIN-
DELAY SHOULD enforce it.
If the minimum login delay period could differ per user (that is,
the LOGIN-DELAY argument might change after authentication), the
server MUST announce in AUTHENTICATION state the largest value
which could be set for any user. This might be the largest value
currently in use for any user (so only one value per server), or
even the largest value which the server permits to be set for any
user. The server SHOULD append the token "USER" to the LOGIN-
DELAY parameter in AUTHENTICATION state, to inform the client
that a more accurate value is available after authentication.
The server SHOULD announce the more accurate value in TRANSACTION
state. (The "USER" token allows the client to decide if a second
CAPA command is needed or not.)
Servers enforce LOGIN-DELAY by rejecting an authentication
command with or without the LOGIN-DELAY error response. See
section 8.1.1 for more information.
6.6. PIPELINING capability
CAPA tag:
PIPELINING
Arguments:
none
Added commands:
none
Standard commands affected:
all
Gellens, et. al. Standards Track [Page 9]
RFC 2449 POP3 Extension Mechanism November 1998
Announced states / possible differences:
both / no
Commands valid in states:
n/a
Specification reference:
this document
Discussion:
The PIPELINING capability indicates the server is capable of
accepting multiple commands at a time; the client does not have
to wait for the response to a command before issuing a subsequent
command. If a server supports PIPELINING, it MUST process each
command in turn. If a client uses PIPELINING, it MUST keep track
of which commands it has outstanding, and match server responses
to commands in order. If either the client or server uses
blocking writes, it MUST not exceed the window size of the
underlying transport layer.
Some POP3 clients have an option to indicate the server supports
"Overlapped POP3 commands." This capability removes the need to
configure this at the client.
This is roughly synonymous with the ESMTP PIPELINING extension
[PIPELINING], however, since SMTP [SMTP] tends to have short
commands and responses, the benefit is in grouping multiple
commands and sending them as a unit. While there are cases of
this in POP (for example, USER and PASS could be batched,
multiple RETR and/or DELE commands could be sent as a group),
because POP has short commands and sometimes lengthy responses,
there is also an advantage is sending new commands while still
receiving the response to an earlier command (for example,
sending RETR and/or DELE commands while processing a UIDL reply).
6.7. EXPIRE capability
CAPA tag:
EXPIRE
Arguments:
server-guaranteed minimum retention days, or NEVER; optionally
followed by USER in AUTHENTICATION state
Added commands:
none
Gellens, et. al. Standards Track [Page 10]
RFC 2449 POP3 Extension Mechanism November 1998
Standard commands affected:
none
Announced states / possible differences:
both / yes
Commands valid in states:
n/a
Specification reference:
this document
Discussion:
While POP3 allows clients to leave messages on the server, RFC
1939 [POP3] warns about the problems that may arise from this,
and allows servers to delete messages based on site policy.
The EXPIRE capability avoids the problems mentioned in RFC 1939,
by allowing the server to inform the client as to the policy in
effect. The argument to the EXPIRE capability indicates the
minimum server retention period, in days, for messages on the
server.
EXPIRE 0 indicates the client is not permitted to leave mail on
the server; when the session enters the UPDATE state the server
MAY assume an implicit DELE for each message which was downloaded
with RETR.
EXPIRE NEVER asserts that the server does not delete messages.
The concept of a "retention period" is intentionally vague.
Servers may start counting days to expiration when a message is
added to a maildrop, when a client becomes aware of the existence
of a message through the LIST or UIDL commands, when a message
has been acted upon in some way (for example, TOP or RETR), or at
some other event. The EXPIRE capability cannot provide a precise
indication as to exactly when any specific message will expire.
The capability is intended to make it easier for clients to
behave in ways which conform to site policy and user wishes. For
example, a client might display a warning for attempts to
configure a "leave mail on server" period which is greater than
or equal to some percentage of the value announced by the server.
If a site uses any automatic deletion policy, it SHOULD use the
EXPIRE capability to announce this.
Gellens, et. al. Standards Track [Page 11]
RFC 2449 POP3 Extension Mechanism November 1998
The EXPIRE capability, with a parameter other than 0 or NEVER, is
intended to let the client know that the server does permit mail
to be left on the server, and to present a value which is the
smallest which might be in force.
Sites which permit users to retain messages indefinitely SHOULD
announce this with the EXPIRE NEVER response.
If the expiration policy differs per user (that is, the EXPIRE
argument might change after authentication), the server MUST
announce in AUTHENTICATION state the smallest value which could
be set for any user. This might be the smallest value currently
in use for any user (so only one value per server), or even the
smallest value which the server permits to be set for any user.
The server SHOULD append the token "USER" to the EXPIRE parameter
in AUTHENTICATION state, to inform the client that a more
accurate value is available after authentication. The server
SHOULD announce the more accurate value in TRANSACTION state.
(The "USER" token allows the client to decide if a second CAPA
command is needed or not.)
A site may have a message expiration policy which treats messages
differently depending on which user actions have been performed,
or based on other factors. For example, a site might delete
unseen messages after 60 days, and completely- or partially-seen
messages after 15 days.
The announced EXPIRE value is the smallest retention period which
is or might be used by any category or condition of the current
site policy, for any user (in AUTHENTICATION state) or the
specific user (in TRANSACTION state). That is, EXPIRE informs
the client of the minimum number of days messages may remain on
the server under any circumstances.
Examples:
EXPIRE 5 USER
EXPIRE 30
EXPIRE NEVER
EXPIRE 0
The first example indicates the server might delete messages
after five days, but the period differs per user, and so a more
accurate value can be obtained by issuing a second CAPA command
in TRANSACTION state. The second example indicates the server
could delete messages after 30 days. In the third example, the
server announces it does not delete messages. The fourth example
specifies that the site does not permit messages to be left on
the server.
Gellens, et. al. Standards Track [Page 12]
RFC 2449 POP3 Extension Mechanism November 1998
6.8. UIDL capability
CAPA tag:
UIDL
Arguments:
none
Added commands:
UIDL
Standard commands affected:
none
Announced states / possible differences:
both / no
Commands valid in states:
TRANSACTION
Specification reference:
[POP3]
Discussion:
The UIDL capability indicates that the optional UIDL command is
supported.
6.9. IMPLEMENTATION capability
CAPA tag:
IMPLEMENTATION
Arguments:
string giving server implementation information
Added commands:
none
Standard commands affected:
none
Announced states / possible differences:
both (optionally TRANSACTION only) / no
Commands valid in states:
n/a
Gellens, et. al. Standards Track [Page 13]
RFC 2449 POP3 Extension Mechanism November 1998
Specification reference:
this document
Discussion:
It is often useful to identify an implementation of a particular
server (for example, when logging). This is commonly done in the
welcome banner, but one must guess if a string is an
implementation ID or not.
The argument to the IMPLEMENTATION capability consists of one or
more tokens which identify the server. (Note that since CAPA
response tag arguments are space-separated, it may be convenient
for the IMPLEMENTATION capability argument to not contain spaces,
so that it is a single token.)
Normally, servers announce IMPLEMENTATION in both states.
However, a server MAY chose to do so only in TRANSACTION state.
A server MAY include the implementation identification both in
the welcome banner and in the IMPLEMENTATION capability.
Clients MUST NOT modify their behavior based on the server
implementation. Instead the server and client should agree on a
private extension.
7. Future Extensions to POP3
Future extensions to POP3 are in general discouraged, as POP3's
usefulness lies in its simplicity. POP3 is intended as a download-
and-delete protocol; mail access capabilities are available in IMAP
[IMAP4]. Extensions which provide support for additional mailboxes,
allow uploading of messages to the server, or which deviate from
POP's download-and-delete model are strongly discouraged and unlikely
to be permitted on the IETF standards track.
Clients MUST NOT require the presence of any extension for basic
functionality, with the exception of the authentication commands
(APOP, AUTH [section 6.3] and USER/PASS).
Section 9 specifies how additional capabilities are defined.
8. Extended POP3 Response Codes
Unextended POP3 is only capable of indicating success or failure to
most commands. Unfortunately, clients often need to know more
information about the cause of a failure in order to gracefully
recover. This is especially important in response to a failed login
Gellens, et. al. Standards Track [Page 14]
RFC 2449 POP3 Extension Mechanism November 1998
(there are widely-deployed clients which attempt to decode the error
text of a PASS command result, to try and distinguish between "unable
to get maildrop lock" and "bad login").
This specification amends the POP3 standard to permit an optional
response code, enclosed in square brackets, at the beginning of the
human readable text portion of an "+OK" or "-ERR" response. Clients
supporting this extension MAY remove any information enclosed in
square brackets prior to displaying human readable text to the user.
Immediately following the open square bracket "[" character is a
response code which is interpreted in a case-insensitive fashion by
the client.
The response code is hierarchical, with a "/" separating levels of
detail about the error. Clients MUST ignore unknown hierarchical
detail about the response code. This is important, as it could be
necessary to provide further detail for response codes in the future.
Section 3 describes response codes using [ABNF].
If a server supports extended response codes, it indicates this by
including the RESP-CODES capability in the CAPA response.
Examples:
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: -ERR [IN-USE] Do you have another POP session running?
8.1. Initial POP3 response codes
This specification defines two POP3 response codes which can be used
to determine the reason for a failed login. Section 9 specifies how
additional response codes are defined.
8.1.1. The LOGIN-DELAY response code
This occurs on an -ERR response to an AUTH, USER (see note), PASS or
APOP command and indicates that the user has logged in recently and
will not be allowed to login again until the login delay period has
expired.
NOTE: Returning the LOGIN-DELAY response code to the USER command
avoids the work of authenticating the user but reveals to the client
that the specified user exists. Unless the server is operating in an
environment where user names are not secret (for example, many
popular email clients advertise the POP server and user name in an
outgoing mail header), or where server access is restricted, or the
server can verify that the connection is to the same user, it is
Gellens, et. al. Standards Track [Page 15]
RFC 2449 POP3 Extension Mechanism November 1998
strongly recommended that the server not issue this response code to
the USER command. The server still saves the cost of opening the
maildrop, which in some environments is the most expensive step.
8.1.2. The IN-USE response code
This occurs on an -ERR response to an AUTH, APOP, or PASS command.
It indicates the authentication was successful, but the user's
maildrop is currently in use (probably by another POP3 client).
9. IANA Considerations
This document requests that IANA maintain two new registries: POP3
capabilities and POP3 response codes.
New POP3 capabilities MUST be defined in a standards track or IESG
approved experimental RFC, and MUST NOT begin with the letter "X".
New POP3 capabilities MUST include the following information:
CAPA tag
Arguments
Added commands
Standard commands affected
Announced states / possible differences
Commands valid in states
Specification reference
Discussion
In addition, new limits for POP3 command and response lengths may
need to be included.
New POP3 response codes MUST be defined in an RFC or other permanent
and readily available reference, in sufficient detail so that
interoperability between independent implementations is possible.
(This is the "Specification Required" policy described in [IANA]).
New POP3 response code specifications MUST include the following
information: the complete response code, for which responses (+OK
or -ERR) and commands it is valid, and a definition of its meaning and
expected client behavior.
Gellens, et. al. Standards Track [Page 16]
RFC 2449 POP3 Extension Mechanism November 1998
10. Security Considerations
A capability list can reveal information about the server's
authentication mechanisms which can be used to determine if certain
attacks will be successful. However, allowing clients to
automatically detect availability of stronger mechanisms and alter
their configurations to use them can improve overall security at a
site.
Section 8.1 discusses the security issues related to use of the
LOGIN-DELAY response code with the USER command.
11. Acknowledgments
This document has been revised in part based on comments and
discussions which took place on and off the IETF POP3 Extensions
mailing list. The help of those who took the time to review this
memo and make suggestions is appreciated, especially that of Alexey
Melnikov, Harald Alvestrand, and Mike Gahrns.
12. References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[IMAP4] Crispin, M., "Internet Message Access Protocol --
Version 4rev1", RFC 2060, December 1996.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PIPELINING] Freed, N., "SMTP Service Extension for Command
Pipelining", RFC 2197, September 1997.
[POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version
3", STD 53, RFC 1939, May 1996.
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
December 1994.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
Gellens, et. al. Standards Track [Page 17]
RFC 2449 POP3 Extension Mechanism November 1998
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
13. Authors' Addresses
Randall Gellens
QUALCOMM Incorporated
6455 Lusk Blvd.
San Diego, CA 92121-2779
USA
Phone: +1 619 651 5115
Fax: +1 619 845 7268
EMail: randy@qualcomm.com
Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790
USA
EMail: chris.newman@innosoft.com
Laurence Lundblade
QUALCOMM Incorporated
6455 Lusk Blvd.
San Diego, Ca, 92121-2779
USA
Phone: +1 619 658 3584
Fax: +1 619 845 7268
EMail: lgl@qualcomm.com
Gellens, et. al. Standards Track [Page 18]
RFC 2449 POP3 Extension Mechanism November 1998
14. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gellens, et. al. Standards Track [Page 19]