You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by ba...@apache.org on 2006/07/29 15:16:01 UTC
svn commit: r426798 [23/30] - in
/james/server/trunk/src/site/resources/rfclist: ./ basic/ imap4/ ldap/
nntp/ pop3/ smtp/
Added: james/server/trunk/src/site/resources/rfclist/pop3/rfc1725.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/pop3/rfc1725.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/pop3/rfc1725.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/pop3/rfc1725.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,1012 @@
+
+
+
+
+
+Network Working Group J. Myers
+Request for Comments: 1725 Carnegie Mellon
+Obsoletes: 1460 M. Rose
+Category: Standards Track Dover Beach Consulting, Inc.
+ November 1994
+
+
+ Post Office Protocol - Version 3
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Overview
+
+ This memo is a revision to RFC 1460, a Draft Standard. It makes the
+ following changes from that document:
+
+ - removed text regarding "split-UA model", which didn't add
+ anything to the understanding of POP
+
+ - clarified syntax of commands, keywords, and arguments
+
+ - clarified behavior on broken connection
+
+ - explicitly permitted an inactivity autologout timer
+
+ - clarified the requirements of the "exclusive-access lock"
+
+ - removed implementation-specific wording regarding the parsing of
+ the maildrop
+
+ - allowed servers to close the connection after a failed
+ authentication command
+
+ - removed the LAST command
+
+ - fixed typo in example of TOP command
+
+ - clarified that the second argument to the TOP command is non-
+ negative
+
+ - added the optional UIDL command
+
+
+
+
+Myers & Rose [Page 1]
+
+RFC 1725 POP3 November 1994
+
+
+ - added warning regarding length of shared secrets with APOP
+
+ - added additional warnings to the security considerations section
+
+1. Introduction
+
+ On certain types of smaller nodes in the Internet it is often
+ impractical to maintain a message transport system (MTS). For
+ example, a workstation may not have sufficient resources (cycles,
+ disk space) in order to permit a SMTP server [RFC821] and associated
+ local mail delivery system to be kept resident and continuously
+ running. Similarly, it may be expensive (or impossible) to keep a
+ personal computer interconnected to an IP-style network for long
+ amounts of time (the node is lacking the resource known as
+ "connectivity").
+
+ Despite this, it is often very useful to be able to manage mail on
+ these smaller nodes, and they often support a user agent (UA) to aid
+ the tasks of mail handling. To solve this problem, a node which can
+ support an MTS entity offers a maildrop service to these less endowed
+ nodes. The Post Office Protocol - Version 3 (POP3) is intended to
+ permit a workstation to dynamically access a maildrop on a server
+ host in a useful fashion. Usually, this means that the POP3 is used
+ to allow a workstation to retrieve mail that the server is holding
+ for it.
+
+ For the remainder of this memo, the term "client host" refers to a
+ host making use of the POP3 service, while the term "server host"
+ refers to a host which offers the POP3 service.
+
+2. A Short Digression
+
+ This memo does not specify how a client host enters mail into the
+ transport system, although a method consistent with the philosophy of
+ this memo is presented here:
+
+ When the user agent on a client host wishes to enter a message
+ into the transport system, it establishes an SMTP connection to
+ its relay host (this relay host could be, but need not be, the
+ POP3 server host for the client host).
+
+3. Basic Operation
+
+ Initially, the server host starts the POP3 service by listening on
+ TCP port 110. When a client host wishes to make use of the service,
+ it establishes a TCP connection with the server host. When the
+ connection is established, the POP3 server sends a greeting. The
+ client and POP3 server then exchange commands and responses
+
+
+
+Myers & Rose [Page 2]
+
+RFC 1725 POP3 November 1994
+
+
+ (respectively) until the connection is closed or aborted.
+
+ Commands in the POP3 consist of a keyword, possibly followed by one
+ or more arguments. All commands are terminated by a CRLF pair.
+ Keywords and arguments consist of printable ASCII characters.
+ Keywords and arguments are each separated by a single SPACE
+ character. Keywords are three or four characters long. Each argument
+ may be up to 40 characters long.
+
+ Responses in the POP3 consist of a status indicator and a keyword
+ possibly followed by additional information. All responses are
+ terminated by a CRLF pair. There are currently two status
+ indicators: positive ("+OK") and negative ("-ERR").
+
+ Responses to certain commands are multi-line. In these cases, which
+ are clearly indicated below, after sending the first line of the
+ response and a CRLF, any additional lines are sent, each terminated
+ by a CRLF pair. When all lines of the response have been sent, a
+ final line is sent, consisting of a termination octet (decimal code
+ 046, ".") and a CRLF pair. If any line of the multi-line response
+ begins with the termination octet, the line is "byte-stuffed" by
+ pre-pending the termination octet to that line of the response.
+ Hence a multi-line response is terminated with the five octets
+ "CRLF.CRLF". When examining a multi-line response, the client checks
+ to see if the line begins with the termination octet. If so and if
+ octets other than CRLF follow, the the first octet of the line (the
+ 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
+ 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 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
+
+
+
+Myers & Rose [Page 3]
+
+RFC 1725 POP3 November 1994
+
+
+ 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 string terminated
+ by CRLF. An example might be:
+
+ S: +OK POP3 server ready
+
+ Note that this greeting is a POP3 reply. The POP3 server should
+ always give a positive response as the greeting.
+
+ 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. The APOP
+ command is described later in this document.
+
+ 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.
+
+ 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.
+
+ 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 the
+ maildrop cannot be opened for some reason (for example, a lock can
+ not be acquired, the client is denied access to the appropriate
+ maildrop, or the maildrop cannot be parsed), the POP3 server responds
+ with a negative status indicator. (If a lock was acquired but the
+ POP3 server intends to respond with a negative status indicator, the
+ POP3 server must release the lock prior to rejecting the command.)
+ After returning a negative status indicator, the server may close the
+
+
+
+Myers & Rose [Page 4]
+
+RFC 1725 POP3 November 1994
+
+
+ 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 n'th message
+ in a maildrop is assigned a message-number of "n". In POP3 commands
+ and responses, all message-number's and message sizes are expressed
+ in base-10 (i.e., decimal).
+
+ Here are summaries for the three POP3 commands discussed thus far:
+
+ 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
+
+ Possible Responses:
+ +OK name is a valid mailbox
+ -ERR never heard of mailbox name
+
+ Examples:
+ C: USER mrose
+ S: +OK mrose is a real hoopy frood
+ ...
+ C: USER frated
+ S: -ERR sorry, no mailbox for frated here
+
+ PASS string
+
+ Arguments:
+ a server/mailbox-specific password (required)
+
+ Restrictions:
+ may only be given in the AUTHORIZATION state after a
+ successful USER command
+
+ Discussion:
+ 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.
+
+
+
+Myers & Rose [Page 5]
+
+RFC 1725 POP3 November 1994
+
+
+ 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: +OK mrose's maildrop has 2 messages (320 octets)
+ ...
+ C: USER mrose
+ S: +OK mrose is a real hoopy frood
+ C: PASS secret
+ S: -ERR maildrop already locked
+
+ 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.
+
+ Here are the POP3 commands valid in the TRANSACTION state:
+
+ STAT
+
+ Arguments: none
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+
+
+
+
+Myers & Rose [Page 6]
+
+RFC 1725 POP3 November 1994
+
+
+ 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 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
+
+ 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.
+
+
+
+Myers & Rose [Page 7]
+
+RFC 1725 POP3 November 1994
+
+
+ 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.
+
+ 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.
+ 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
+ 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
+
+
+
+Myers & Rose [Page 8]
+
+RFC 1725 POP3 November 1994
+
+
+ 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
+
+ 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
+
+
+
+
+Myers & Rose [Page 9]
+
+RFC 1725 POP3 November 1994
+
+
+ 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
+ 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
+
+
+
+
+Myers & Rose [Page 10]
+
+RFC 1725 POP3 November 1994
+
+
+ Restrictions: none
+
+ Discussion:
+ The POP3 server removes all messages marked as deleted from
+ the maildrop. It then releases any exclusive-access lock
+ on the maildrop and replies as to the status of these
+ operations. The TCP connection is then closed.
+
+ Possible Responses:
+ +OK
+
+ Examples:
+ C: QUIT
+ S: +OK dewey POP3 server signing off (maildrop empty)
+ ...
+ C: QUIT
+ 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
+ (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
+
+
+
+Myers & Rose [Page 11]
+
+RFC 1725 POP3 November 1994
+
+
+ line separating the headers from the body, and then the
+ number of lines 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
+ 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 (optionally) If a message-number is given,
+ it 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.
+
+
+
+Myers & Rose [Page 12]
+
+RFC 1725 POP3 November 1994
+
+
+ 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 characters in the range 0x21 to 0x7E,
+ which uniquely identifies a message within a maildrop and
+ which persists across sessions. 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.
+
+ 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
+
+ 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
+
+ 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.
+
+
+
+Myers & Rose [Page 13]
+
+RFC 1725 POP3 November 1994
+
+
+ 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:
+
+ <pr...@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
+ 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).
+
+
+
+
+
+Myers & Rose [Page 14]
+
+RFC 1725 POP3 November 1994
+
+
+ Possible Responses:
+ +OK maildrop locked and ready
+ -ERR permission denied
+
+ Examples:
+ S: +OK POP3 server ready <18...@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
+
+ <18...@dbc.mtview.ca.us>tanstaaf
+
+ which produces a digest value of
+
+ c4c9334bac560ecc979e58001b3e22fb
+
+8. 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 valid in the UPDATE state
+
+ 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
+
+
+
+
+
+Myers & Rose [Page 15]
+
+RFC 1725 POP3 November 1994
+
+
+ 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.
+
+9. Example POP3 Session
+
+ S: <wait for connection on TCP port 110>
+ C: <open connection>
+ S: +OK POP3 server ready <18...@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>
+
+10. 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
+
+
+
+Myers & Rose [Page 16]
+
+RFC 1725 POP3 November 1994
+
+
+ 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 be counted twice, since the POP3 client will remove all byte-
+ stuffed termination characters when it receives a multi-line
+ response.
+
+11. 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.
+
+12. 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 must not allow both methods of access for a given user; that
+ is, for a given "USER name" either the PASS or 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.
+
+13. 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 [Page 17]
+
+RFC 1725 POP3 November 1994
+
+
+14. 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 [Page 18]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/pop3/rfc1725.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/pop3/rfc1734.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/pop3/rfc1734.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/pop3/rfc1734.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/pop3/rfc1734.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,284 @@
+
+
+
+
+
+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]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/pop3/rfc1734.txt
------------------------------------------------------------------------------
svn:eol-style = native
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org