< draft-myers-pop-pop3-05.txt   draft-myers-pop-pop3-06.txt >
Network Working Group J. Myers Network Working Group J. Myers
Internet Draft: POP3 Carnegie Mellon Internet Draft: POP3 Carnegie Mellon
Document: draft-myers-pop-pop3-05.txt M. Rose Document: draft-myers-pop-pop3-06.txt M. Rose
Dover Beach Consulting, Inc. Dover Beach Consulting, Inc.
August 1995 August 1995
Post Office Protocol - Version 3 Post Office Protocol - Version 3
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
skipping to change at page 2, line ? skipping to change at page 2, line ?
1id-abstracts.txt listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au. munnari.oz.au.
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as an Internet Standard for the Internet Community. editor as an Internet Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
document will expire before 15 Nov 1995. Distribution of this draft document will expire before 15 Nov 1995. Distribution of this draft
is unlimited. is unlimited.
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
1. Introduction 1. Introduction
On certain types of smaller nodes in the Internet it is often On certain types of smaller nodes in the Internet it is often
impractical to maintain a message transport system (MTS). For impractical to maintain a message transport system (MTS). For
example, a workstation may not have sufficient resources (cycles, example, a workstation may not have sufficient resources (cycles,
disk space) in order to permit a SMTP server [RFC821] and associated disk space) in order to permit a SMTP server [RFC821] and associated
local mail delivery system to be kept resident and continuously local mail delivery system to be kept resident and continuously
running. Similarly, it may be expensive (or impossible) to keep a running. Similarly, it may be expensive (or impossible) to keep a
personal computer interconnected to an IP-style network for long personal computer interconnected to an IP-style network for long
skipping to change at page 3, line 5 skipping to change at page 3, line 5
this memo is presented here: this memo is presented here:
When the user agent on a client host wishes to enter a message When the user agent on a client host wishes to enter a message
into the transport system, it establishes an SMTP connection to into the transport system, it establishes an SMTP connection to
its relay host and sends all mail to it. This relay host could 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 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 course, the relay host must accept mail for delivery to arbitrary
recipient addresses, that functionality is not required of all recipient addresses, that functionality is not required of all
SMTP servers. SMTP servers.
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
3. Basic Operation 3. Basic Operation
Initially, the server host starts the POP3 service by listening on 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, 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 it establishes a TCP connection with the server host. When the
connection is established, the POP3 server sends a greeting. The connection is established, the POP3 server sends a greeting. The
client and POP3 server then exchange commands and responses client and POP3 server then exchange commands and responses
(respectively) until the connection is closed or aborted. (respectively) until the connection is closed or aborted.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
A POP3 session progresses through a number of states during its A POP3 session progresses through a number of states during its
lifetime. Once the TCP connection has been opened and the POP3 lifetime. Once the TCP connection has been opened and the POP3
server has sent the greeting, the session enters the AUTHORIZATION server has sent the greeting, the session enters the AUTHORIZATION
state. In this state, the client must identify itself to the POP3 state. In this state, the client must identify itself to the POP3
server. Once the client has successfully done this, the server server. Once the client has successfully done this, the server
acquires resources associated with the client's maildrop, and the acquires resources associated with the client's maildrop, and the
session enters the TRANSACTION state. In this state, the client session enters the TRANSACTION state. In this state, the client
requests actions on the part of the POP3 server. When the client has requests actions on the part of the POP3 server. When the client has
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
issued the QUIT command, the session enters the UPDATE state. In issued the QUIT command, the session enters the UPDATE state. In
this state, the POP3 server releases any resources acquired during this state, the POP3 server releases any resources acquired during
the TRANSACTION state and says goodbye. The TCP connection is then the TRANSACTION state and says goodbye. The TCP connection is then
closed. closed.
A server MUST respond to an unrecognized, unimplemented, or A server MUST respond to an unrecognized, unimplemented, or
syntactically invalid command by responding with a negative status syntactically invalid command by responding with a negative status
indicator. A server MUST respond to a command issued when the indicator. A server MUST respond to a command issued when the
session is in an incorrect state by responding with a negative status session is in an incorrect state by responding with a negative status
skipping to change at page 5, line 5 skipping to change at page 5, line 5
authentication command that the client should be given access to the authentication command that the client should be given access to the
appropriate maildrop, the POP3 server then acquires an exclusive- appropriate maildrop, the POP3 server then acquires an exclusive-
access lock on the maildrop, as necessary to prevent messages from access lock on the maildrop, as necessary to prevent messages from
being modified or removed before the session enters the UPDATE state. being modified or removed before the session enters the UPDATE state.
If the lock is successfully acquired, the POP3 server responds with a If the lock is successfully acquired, the POP3 server responds with a
positive status indicator. The POP3 session now enters the positive status indicator. The POP3 session now enters the
TRANSACTION state, with no messages marked as deleted. If the the TRANSACTION state, with no messages marked as deleted. If the the
maildrop cannot be opened for some reason (for example, a lock can maildrop cannot be opened for some reason (for example, a lock can
not be acquired, the client is denied access to the appropriate not be acquired, the client is denied access to the appropriate
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
maildrop, or the maildrop cannot be parsed), the POP3 server responds maildrop, or the maildrop cannot be parsed), the POP3 server responds
with a negative status indicator. (If a lock was acquired but the 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 intends to respond with a negative status indicator, the
POP3 server must release the lock prior to rejecting the command.) POP3 server must release the lock prior to rejecting the command.)
After returning a negative status indicator, the server may close the After returning a negative status indicator, the server may close the
connection. If the server does not close the connection, the client connection. If the server does not close the connection, the client
may either issue a new authentication command and start again, or the may either issue a new authentication command and start again, or the
client may issue the QUIT command. client may issue the QUIT command.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
Once the client has successfully identified itself to the POP3 server Once the client has successfully identified itself to the POP3 server
and the POP3 server has locked and opened the appropriate maildrop, and the POP3 server has locked and opened the appropriate maildrop,
the POP3 session is now in the TRANSACTION state. The client may now the POP3 session is now in the TRANSACTION state. The client may now
issue any of the following POP3 commands repeatedly. After each issue any of the following POP3 commands repeatedly. After each
command, the POP3 server issues a response. Eventually, the client command, the POP3 server issues a response. Eventually, the client
issues the QUIT command and the POP3 session enters the UPDATE state. issues the QUIT command and the POP3 session enters the UPDATE state.
Here are the POP3 commands valid in the TRANSACTION state: Here are the POP3 commands valid in the TRANSACTION state:
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
STAT STAT
Arguments: none Arguments: none
Restrictions: Restrictions:
may only be given in the TRANSACTION state may only be given in the TRANSACTION state
Discussion: Discussion:
The POP3 server issues a positive response with a line The POP3 server issues a positive response with a line
skipping to change at page 7, line 5 skipping to change at page 7, line 5
LIST [msg] LIST [msg]
Arguments: Arguments:
a message-number (optional), which, if present, may NOT a message-number (optional), which, if present, may NOT
refer to a message marked as deleted refer to a message marked as deleted
Restrictions: Restrictions:
may only be given in the TRANSACTION state may only be given in the TRANSACTION state
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
Discussion: Discussion:
If an argument was given and the POP3 server issues a If an argument was given and the POP3 server issues a
positive response with a line containing information for positive response with a line containing information for
that message. This line is called a "scan listing" for that message. This line is called a "scan listing" for
that message. that message.
If no argument was given and the POP3 server issues a If no argument was given and the POP3 server issues a
positive response, then the response given is multi-line. positive response, then the response given is multi-line.
After the initial +OK, for each message in the maildrop, After the initial +OK, for each message in the maildrop,
skipping to change at page 8, line 5 skipping to change at page 8, line 5
-ERR no such message -ERR no such message
Examples: Examples:
C: LIST C: LIST
S: +OK 2 messages (320 octets) S: +OK 2 messages (320 octets)
S: 1 120 S: 1 120
S: 2 200 S: 2 200
S: . S: .
... ...
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
C: LIST 2 C: LIST 2
S: +OK 2 200 S: +OK 2 200
... ...
C: LIST 3 C: LIST 3
S: -ERR no such message, only 2 messages in maildrop S: -ERR no such message, only 2 messages in maildrop
RETR msg RETR msg
Arguments: Arguments:
skipping to change at page 9, line 5 skipping to change at page 9, line 5
Restrictions: Restrictions:
may only be given in the TRANSACTION state may only be given in the TRANSACTION state
Discussion: Discussion:
The POP3 server marks the message as deleted. Any future The POP3 server marks the message as deleted. Any future
reference to the message-number associated with the message reference to the message-number associated with the message
in a POP3 command generates an error. The POP3 server does in a POP3 command generates an error. The POP3 server does
not actually delete the message until the POP3 session not actually delete the message until the POP3 session
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
enters the UPDATE state. enters the UPDATE state.
Possible Responses: Possible Responses:
+OK message deleted +OK message deleted
-ERR no such message -ERR no such message
Examples: Examples:
C: DELE 1 C: DELE 1
S: +OK message 1 deleted S: +OK message 1 deleted
skipping to change at page 10, line 5 skipping to change at page 10, line 5
may only be given in the TRANSACTION state may only be given in the TRANSACTION state
Discussion: Discussion:
If any messages have been marked as deleted by the POP3 If any messages have been marked as deleted by the POP3
server, they are unmarked. The POP3 server then replies server, they are unmarked. The POP3 server then replies
with a positive response. with a positive response.
Possible Responses: Possible Responses:
+OK +OK
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
Examples: Examples:
C: RSET C: RSET
S: +OK maildrop has 2 messages (320 octets) S: +OK maildrop has 2 messages (320 octets)
6. The UPDATE State 6. The UPDATE State
When the client issues the QUIT command from the TRANSACTION state, When the client issues the QUIT command from the TRANSACTION state,
the POP3 session enters the UPDATE state. (Note that if the client the POP3 session enters the UPDATE state. (Note that if the client
issues the QUIT command from the AUTHORIZATION state, the POP3 issues the QUIT command from the AUTHORIZATION state, the POP3
skipping to change at page 11, line 5 skipping to change at page 11, line 5
-ERR some deleted messages not removed -ERR some deleted messages not removed
Examples: Examples:
C: QUIT C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty) S: +OK dewey POP3 server signing off (maildrop empty)
... ...
C: QUIT C: QUIT
S: +OK dewey POP3 server signing off (2 messages left) S: +OK dewey POP3 server signing off (2 messages left)
... ...
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
7. Optional POP3 Commands 7. Optional POP3 Commands
The POP3 commands discussed above must be supported by all minimal The POP3 commands discussed above must be supported by all minimal
implementations of POP3 servers. implementations of POP3 servers.
The optional POP3 commands described below permit a POP3 client The optional POP3 commands described below permit a POP3 client
greater freedom in message handling, while preserving a simple POP3 greater freedom in message handling, while preserving a simple POP3
server implementation. server implementation.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
Possible Responses: Possible Responses:
+OK top of message follows +OK top of message follows
-ERR no such message -ERR no such message
Examples: Examples:
C: TOP 1 10 C: TOP 1 10
S: +OK S: +OK
S: <the POP3 server sends the headers of the S: <the POP3 server sends the headers of the
message, a blank line, and the first 10 lines message, a blank line, and the first 10 lines
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
of the body of the message> of the body of the message>
S: . S: .
... ...
C: TOP 100 3 C: TOP 100 3
S: -ERR no such message S: -ERR no such message
UIDL [msg] UIDL [msg]
Arguments: Arguments:
skipping to change at page 12, line 50 skipping to change at page 12, line 50
string, consisting of one to 70 characters in the range 0x21 string, consisting of one to 70 characters in the range 0x21
to 0x7E, which uniquely identifies a message within a to 0x7E, which uniquely identifies a message within a
maildrop and which persists across sessions. This maildrop and which persists across sessions. This
persistence is required even if a session ends without persistence is required even if a session ends without
entering the UPDATE state. The server should never reuse an entering the UPDATE state. The server should never reuse an
unique-id in a given maildrop, for as long as the entity unique-id in a given maildrop, for as long as the entity
using the unique-id exists. using the unique-id exists.
Note that messages marked as deleted are not listed. 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,
this specification is intended to permit unique-ids to be
calculated as a hash of the message. Clients should be able
Internet DRAFT POP3 October 4, 1995
to handle a situation where two identical copies of a
message in a maildrop have the same unique-id.
Possible Responses: Possible Responses:
+OK unique-id listing follows +OK unique-id listing follows
-ERR no such message -ERR no such message
Internet DRAFT POP3 August 4, 1995
Examples: Examples:
C: UIDL C: UIDL
S: +OK S: +OK
S: 1 whqtswO00WBw418f9t5JxYwZ S: 1 whqtswO00WBw418f9t5JxYwZ
S: 2 QhdPYR:00WBw1Ph7x7 S: 2 QhdPYR:00WBw1Ph7x7
S: . S: .
... ...
C: UIDL 2 C: UIDL 2
S: +OK 2 QhdPYR:00WBw1Ph7x7 S: +OK 2 QhdPYR:00WBw1Ph7x7
... ...
skipping to change at page 13, line 47 skipping to change at page 14, line 5
the POP3 server responds with a negative status indicator the POP3 server responds with a negative status indicator
("-ERR") to the USER command, then the client may either ("-ERR") to the USER command, then the client may either
issue a new authentication command or may issue the QUIT issue a new authentication command or may issue the QUIT
command. command.
The server may return a positive response even though no The server may return a positive response even though no
such mailbox exists. The server may return a negative such mailbox exists. The server may return a negative
response if mailbox exists, but does not permit plaintext response if mailbox exists, but does not permit plaintext
password authentication. password authentication.
Internet DRAFT POP3 October 4, 1995
Possible Responses: Possible Responses:
+OK name is a valid mailbox +OK name is a valid mailbox
-ERR never heard of mailbox name -ERR never heard of mailbox name
Internet DRAFT POP3 August 4, 1995
Examples: Examples:
C: USER frated C: USER frated
S: -ERR sorry, no mailbox for frated here S: -ERR sorry, no mailbox for frated here
... ...
C: USER mrose C: USER mrose
S: +OK mrose is a real hoopy frood S: +OK mrose is a real hoopy frood
PASS string PASS string
Arguments: Arguments:
skipping to change at page 15, line 5 skipping to change at page 15, line 5
C: USER mrose C: USER mrose
S: +OK mrose is a real hoopy frood S: +OK mrose is a real hoopy frood
C: PASS secret C: PASS secret
S: -ERR maildrop already locked S: -ERR maildrop already locked
... ...
C: USER mrose C: USER mrose
S: +OK mrose is a real hoopy frood S: +OK mrose is a real hoopy frood
C: PASS secret C: PASS secret
S: +OK mrose's maildrop has 2 messages (320 octets) S: +OK mrose's maildrop has 2 messages (320 octets)
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
APOP name digest APOP name digest
Arguments: Arguments:
a string identifying a mailbox and a MD5 digest string a string identifying a mailbox and a MD5 digest string
(both required) (both required)
Restrictions: Restrictions:
may only be given in the AUTHORIZATION state after the POP3 may only be given in the AUTHORIZATION state after the POP3
greeting or after an unsuccessful USER or PASS command greeting or after an unsuccessful USER or PASS command
skipping to change at page 16, line 5 skipping to change at page 16, line 5
hostname is the fully-qualified domain-name corresponding hostname is the fully-qualified domain-name corresponding
to the host where the POP3 server is running. to the host where the POP3 server is running.
The POP3 client makes note of this timestamp, and then The POP3 client makes note of this timestamp, and then
issues the APOP command. The `name' parameter has issues the APOP command. The `name' parameter has
identical semantics to the `name' parameter of the USER identical semantics to the `name' parameter of the USER
command. The `digest' parameter is calculated by applying command. The `digest' parameter is calculated by applying
the MD5 algorithm [RFC1321] to a string consisting of the the MD5 algorithm [RFC1321] to a string consisting of the
timestamp (including angle-brackets) followed by a shared timestamp (including angle-brackets) followed by a shared
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
secret. This shared secret is a string known only to the secret. This shared secret is a string known only to the
POP3 client and server. Great care should be taken to POP3 client and server. Great care should be taken to
prevent unauthorized disclosure of the secret, as knowledge prevent unauthorized disclosure of the secret, as knowledge
of the secret will allow any entity to successfully of the secret will allow any entity to successfully
masquerade as the named user. The `digest' parameter masquerade as the named user. The `digest' parameter
itself is a 16-octet value which is sent in hexadecimal itself is a 16-octet value which is sent in hexadecimal
format, using lower-case ASCII characters. format, using lower-case ASCII characters.
When the POP3 server receives the APOP command, it verifies When the POP3 server receives the APOP command, it verifies
skipping to change at page 17, line 5 skipping to change at page 17, line 5
Minimal POP3 Commands: Minimal POP3 Commands:
USER name valid in the AUTHORIZATION state USER name valid in the AUTHORIZATION state
PASS string PASS string
QUIT QUIT
STAT valid in the TRANSACTION state STAT valid in the TRANSACTION state
LIST [msg] LIST [msg]
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
RETR msg RETR msg
DELE msg DELE msg
NOOP NOOP
RSET RSET
QUIT valid in the UPDATE state QUIT valid in the UPDATE state
Optional POP3 Commands: Optional POP3 Commands:
skipping to change at page 18, line 5 skipping to change at page 18, line 5
S: +OK 120 octets S: +OK 120 octets
S: <the POP3 server sends message 1> S: <the POP3 server sends message 1>
S: . S: .
C: DELE 1 C: DELE 1
S: +OK message 1 deleted S: +OK message 1 deleted
C: RETR 2 C: RETR 2
S: +OK 200 octets S: +OK 200 octets
S: <the POP3 server sends message 2> S: <the POP3 server sends message 2>
S: . S: .
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
C: DELE 2 C: DELE 2
S: +OK message 2 deleted S: +OK message 2 deleted
C: QUIT C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty) S: +OK dewey POP3 server signing off (maildrop empty)
C: <close connection> C: <close connection>
S: <wait for next connection> S: <wait for next connection>
10. Message Format 10. Message Format
skipping to change at page 19, line 5 skipping to change at page 19, line 5
[RFC1734] Myers, J. "POP3 AUTHentication command", RFC 1734, Carnegie [RFC1734] Myers, J. "POP3 AUTHentication command", RFC 1734, Carnegie
Mellon, December, 1994. Mellon, December, 1994.
12. Security Considerations 12. Security Considerations
It is conjectured that use of the APOP command provides origin It is conjectured that use of the APOP command provides origin
identification and replay protection for a POP3 session. identification and replay protection for a POP3 session.
Accordingly, a POP3 server which implements both the PASS and APOP Accordingly, a POP3 server which implements both the PASS and APOP
commands should not allow both methods of access for a given user; commands should not allow both methods of access for a given user;
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
that is, for a given mailbox name, either the USER/PASS command that is, for a given mailbox name, either the USER/PASS command
sequence or the APOP command is allowed, but not both. sequence or the APOP command is allowed, but not both.
Further, note that as the length of the shared secret increases, so Further, note that as the length of the shared secret increases, so
does the difficulty of deriving it. does the difficulty of deriving it.
Servers that answer -ERR to the USER command are giving potential Servers that answer -ERR to the USER command are giving potential
attackers clues about which names are valid. attackers clues about which names are valid.
skipping to change at page 20, line 5 skipping to change at page 20, line 5
420 Whisman Court 420 Whisman Court
Mountain View, CA 94043-2186 Mountain View, CA 94043-2186
EMail: mrose@dbc.mtview.ca.us EMail: mrose@dbc.mtview.ca.us
Appendix A. Differences from RFC 1725 Appendix A. Differences from RFC 1725
This memo is a revision to RFC 1725, a Draft Standard. It makes the This memo is a revision to RFC 1725, a Draft Standard. It makes the
following changes from that document: following changes from that document:
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
- clarifies that command keywords are case insensitive. - clarifies that command keywords are case insensitive.
- specifies that servers must send "+OK" and "-ERR" in - specifies that servers must send "+OK" and "-ERR" in
upper case. upper case.
- specifies that the initial greeting is a positive response, - specifies that the initial greeting is a positive response,
instead of any string which should be a positive response. instead of any string which should be a positive response.
- clarifies behavior for unimplemented commands. - clarifies behavior for unimplemented commands.
skipping to change at page 20, line 27 skipping to change at page 20, line 27
- makes the USER and PASS commands optional. - makes the USER and PASS commands optional.
- clarified the set of possible responses to the USER command. - clarified the set of possible responses to the USER command.
- reverses the order of the examples in the USER and PASS - reverses the order of the examples in the USER and PASS
commands, to reduce confusion. commands, to reduce confusion.
- clarifies that the PASS command may only be given immediately - clarifies that the PASS command may only be given immediately
after a successful USER command. after a successful USER command.
- clarified the persistence requirements of UIDs. - clarified the persistence requirements of UIDs and added some
implementation notes.
- specifies a UID length limitation of one to 70 octets. - specifies a UID length limitation of one to 70 octets.
- specifies a status indicator length limitation - specifies a status indicator length limitation
of 512 octets, including the CRLF. of 512 octets, including the CRLF.
- clarifies that LIST with no arguments on an empty mailbox - clarifies that LIST with no arguments on an empty mailbox
returns success. returns success.
- adds a reference from the LIST command to the Message Format - adds a reference from the LIST command to the Message Format
skipping to change at page 20, line 54 skipping to change at page 21, line 4
- adds references to RFCs 1730 and 1734 - adds references to RFCs 1730 and 1734
- clarifies the method by which a UA may enter mail into the - clarifies the method by which a UA may enter mail into the
transport system. transport system.
- clarifies that the second argument to the TOP command is a - clarifies that the second argument to the TOP command is a
number of lines. number of lines.
- changes the suggestion in the Security Considerations section - changes the suggestion in the Security Considerations section
for a server to not accept both PASS and APOP for a given user
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
for a server to not accept both PASS and APOP for a given user
from a "must" to a "should". from a "must" to a "should".
Appendix B. Command Index Appendix B. Command Index
APOP ....................................................... 15 APOP ....................................................... 15
DELE ....................................................... 8 DELE ....................................................... 8
LIST ....................................................... 6 LIST ....................................................... 6
NOOP ....................................................... 9 NOOP ....................................................... 9
PASS ....................................................... 14 PASS ....................................................... 14
QUIT ....................................................... 5 QUIT ....................................................... 5
QUIT ....................................................... 10 QUIT ....................................................... 10
RETR ....................................................... 8 RETR ....................................................... 8
RSET ....................................................... 9 RSET ....................................................... 9
STAT ....................................................... 6 STAT ....................................................... 6
TOP ........................................................ 11 TOP ........................................................ 11
UIDL ....................................................... 12 UIDL ....................................................... 12
USER ....................................................... 13 USER ....................................................... 13
Internet DRAFT POP3 August 4, 1995 Internet DRAFT POP3 October 4, 1995
Table of Contents Table of Contents
Status of this Memo ............................................... i Status of this Memo ............................................... i
1. Introduction ................................................... 2 1. Introduction ................................................... 2
2. A Short Digression ............................................. 2 2. A Short Digression ............................................. 2
3. Basic Operation ................................................ 3 3. Basic Operation ................................................ 3
4. The AUTHORIZATION State ........................................ 4 4. The AUTHORIZATION State ........................................ 4
QUIT Command ................................................... 5 QUIT Command ................................................... 5
5. The TRANSACTION State .......................................... 5 5. The TRANSACTION State .......................................... 5
 End of changes. 27 change blocks. 
26 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/