📄 rfc1725_pop3_upd.txt
字号:
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -