📄 419.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://202.112.58.200"><font face="黑体"><big><big>Tsinghua</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> 嵌入式系统 (BM: turbolinux jacobw) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="398.htm">上一层</a>][<a href="420.htm">下一篇</a>]
<hr><p align="left"><small>发信人: hellow (收复台湾是我心), 信区: Embedded <br>
标 题: POP3 <br>
发信站: BBS 水木清华站 (Sun Nov 5 09:39:33 2000) <br>
<br>
<br>
Network Working Group J. Myers <br>
Request for Comments: 1939 Carnegie Mellon <br>
STD: 53 M. Rose <br>
Obsoletes: 1725 Dover Beach Consulting, Inc. <br>
Category: Standards Track May 1996 <br>
Post Office Protocol - Version 3 <br>
Status of this Memo <br>
This document specifies an Internet standards track protocol for the <br>
Internet community, and requests discussion and suggestions for <br>
improvements. Please refer to the current edition of the "Internet <br>
Official Protocol Standards" (STD 1) for the standardization state <br>
and status of this protocol. Distribution of this memo is unlimited. <br>
Table of Contents <br>
1. Introduction ................................................ 2 <br>
2. A Short Digression .......................................... 2 <br>
3. Basic Operation ............................................. 3 <br>
4. The AUTHORIZATION State ..................................... 4 <br>
QUIT Command ................................................ 5 <br>
5. The TRANSACTION State ....................................... 5 <br>
STAT Command ................................................ 6 <br>
LIST Command ................................................ 6 <br>
RETR Command ................................................ 8 <br>
DELE Command ................................................ 8 <br>
NOOP Command ................................................ 9 <br>
RSET Command ................................................ 9 <br>
6. The UPDATE State ............................................ 10 <br>
QUIT Command ................................................ 10 <br>
7. Optional POP3 Commands ...................................... 11 <br>
TOP Command ................................................. 11 <br>
UIDL Command ................................................ 12 <br>
USER Command ................................................ 13 <br>
PASS Command ................................................ 14 <br>
APOP Command ................................................ 15 <br>
8. Scaling and Operational Considerations ...................... 16 <br>
9. POP3 Command Summary ........................................ 18 <br>
10. Example POP3 Session ....................................... 19 <br>
11. Message Format ............................................. 19 <br>
12. References ................................................. 20 <br>
13. Security Considerations .................................... 20 <br>
14. Acknowledgements ........................................... 20 <br>
15. Authors' Addresses ......................................... 21 <br>
Appendix A. Differences from RFC 1725 .......................... 22 <br>
Myers & Rose Standards Track [Page 1] <br>
<br>
RFC 1939 POP3 May 1996 <br>
Appendix B. Command Index ...................................... 23 <br>
1. Introduction <br>
On certain types of smaller nodes in the Internet it is often <br>
impractical to maintain a message transport system (MTS). For <br>
example, a workstation may not have sufficient resources (cycles, <br>
disk space) in order to permit a SMTP server [RFC821] and associated <br>
local mail delivery system to be kept resident and continuously <br>
running. Similarly, it may be expensive (or impossible) to keep a <br>
personal computer interconnected to an IP-style network for long <br>
amounts of time (the node is lacking the resource known as <br>
"connectivity"). <br>
Despite this, it is often very useful to be able to manage mail on <br>
these smaller nodes, and they often support a user agent (UA) to aid <br>
the tasks of mail handling. To solve this problem, a node which can <br>
support an MTS entity offers a maildrop service to these less endowed <br>
nodes. The Post Office Protocol - Version 3 (POP3) is intended to <br>
permit a workstation to dynamically access a maildrop on a server <br>
host in a useful fashion. Usually, this means that the POP3 protocol <br>
is used to allow a workstation to retrieve mail that the server is <br>
holding for it. <br>
POP3 is not intended to provide extensive manipulation operations of <br>
mail on the server; normally, mail is downloaded and then deleted. A <br>
more advanced (and complex) protocol, IMAP4, is discussed in <br>
[RFC1730]. <br>
For the remainder of this memo, the term "client host" refers to a <br>
host making use of the POP3 service, while the term "server host" <br>
refers to a host which offers the POP3 service. <br>
2. A Short Digression <br>
This memo does not specify how a client host enters mail into the <br>
transport system, although a method consistent with the philosophy of <br>
this memo is presented here: <br>
When the user agent on a client host wishes to enter a message <br>
into the transport system, it establishes an SMTP connection to <br>
its relay host and sends all mail to it. This relay host could <br>
be, but need not be, the POP3 server host for the client host. Of <br>
course, the relay host must accept mail for delivery to arbitrary <br>
recipient addresses, that functionality is not required of all <br>
SMTP servers. <br>
Myers & Rose Standards Track [Page 2] <br>
<br>
RFC 1939 POP3 May 1996 <br>
3. Basic Operation <br>
Initially, the server host starts the POP3 service by listening on <br>
TCP port 110. When a client host wishes to make use of the service, <br>
it establishes a TCP connection with the server host. When the <br>
connection is established, the POP3 server sends a greeting. The <br>
client and POP3 server then exchange commands and responses <br>
(respectively) until the connection is closed or aborted. <br>
Commands in the POP3 consist of a case-insensitive keyword, possibly <br>
followed by one or more arguments. All commands are terminated by a <br>
CRLF pair. Keywords and arguments consist of printable ASCII <br>
characters. Keywords and arguments are each separated by a single <br>
SPACE character. Keywords are three or four characters long. Each <br>
argument may be up to 40 characters long. <br>
Responses in the POP3 consist of a status indicator and a keyword <br>
possibly followed by additional information. All responses are <br>
terminated by a CRLF pair. Responses may be up to 512 characters <br>
long, including the terminating CRLF. There are currently two status <br>
indicators: positive ("+OK") and negative ("-ERR"). Servers MUST <br>
send the "+OK" and "-ERR" in upper case. <br>
Responses to certain commands are multi-line. In these cases, which <br>
are clearly indicated below, after sending the first line of the <br>
response and a CRLF, any additional lines are sent, each terminated <br>
by a CRLF pair. When all lines of the response have been sent, a <br>
final line is sent, consisting of a termination octet (decimal code <br>
046, ".") and a CRLF pair. If any line of the multi-line response <br>
begins with the termination octet, the line is "byte-stuffed" by <br>
pre-pending the termination octet to that line of the response. <br>
Hence a multi-line response is terminated with the five octets <br>
"CRLF.CRLF". When examining a multi-line response, the client checks <br>
to see if the line begins with the termination octet. If so and if <br>
octets other than CRLF follow, the first octet of the line (the <br>
termination octet) is stripped away. If so and if CRLF immediately <br>
follows the termination character, then the response from the POP <br>
server is ended and the line containing ".CRLF" is not considered <br>
part of the multi-line response. <br>
A POP3 session progresses through a number of states during its <br>
lifetime. Once the TCP connection has been opened and the POP3 <br>
server has sent the greeting, the session enters the AUTHORIZATION <br>
state. In this state, the client must identify itself to the POP3 <br>
server. Once the client has successfully done this, the server <br>
acquires resources associated with the client's maildrop, and the <br>
session enters the TRANSACTION state. In this state, the client <br>
requests actions on the part of the POP3 server. When the client has <br>
Myers & Rose Standards Track [Page 3] <br>
<br>
RFC 1939 POP3 May 1996 <br>
issued the QUIT command, the session enters the UPDATE state. In <br>
this state, the POP3 server releases any resources acquired during <br>
the TRANSACTION state and says goodbye. The TCP connection is then <br>
closed. <br>
A server MUST respond to an unrecognized, unimplemented, or <br>
syntactically invalid command by responding with a negative status <br>
indicator. A server MUST respond to a command issued when the <br>
session is in an incorrect state by responding with a negative status <br>
indicator. There is no general method for a client to distinguish <br>
between a server which does not implement an optional command and a <br>
server which is unwilling or unable to process the command. <br>
A POP3 server MAY have an inactivity autologout timer. Such a timer <br>
MUST be of at least 10 minutes' duration. The receipt of any command <br>
from the client during that interval should suffice to reset the <br>
autologout timer. When the timer expires, the session does NOT enter <br>
the UPDATE state--the server should close the TCP connection without <br>
removing any messages or sending any response to the client. <br>
4. The AUTHORIZATION State <br>
Once the TCP connection has been opened by a POP3 client, the POP3 <br>
server issues a one line greeting. This can be any positive <br>
response. An example might be: <br>
S: +OK POP3 server ready <br>
The POP3 session is now in the AUTHORIZATION state. The client must <br>
now identify and authenticate itself to the POP3 server. Two <br>
possible mechanisms for doing this are described in this document, <br>
the USER and PASS command combination and the APOP command. Both <br>
mechanisms are described later in this document. Additional <br>
authentication mechanisms are described in [RFC1734]. While there is <br>
no single authentication mechanism that is required of all POP3 <br>
servers, a POP3 server must of course support at least one <br>
authentication mechanism. <br>
Once the POP3 server has determined through the use of any <br>
authentication command that the client should be given access to the <br>
appropriate maildrop, the POP3 server then acquires an exclusive- <br>
access lock on the maildrop, as necessary to prevent messages from <br>
being modified or removed before the session enters the UPDATE state. <br>
If the lock is successfully acquired, the POP3 server responds with a <br>
positive status indicator. The POP3 session now enters the <br>
TRANSACTION state, with no messages marked as deleted. If the <br>
maildrop cannot be opened for some reason (for example, a lock can <br>
not be acquired, the client is denied access to the appropriate <br>
Myers & Rose Standards Track [Page 4] <br>
<br>
RFC 1939 POP3 May 1996 <br>
maildrop, or the maildrop cannot be parsed), the POP3 server responds <br>
with a negative status indicator. (If a lock was acquired but the <br>
POP3 server intends to respond with a negative status indicator, the <br>
POP3 server must release the lock prior to rejecting the command.) <br>
After returning a negative status indicator, the server may close the <br>
connection. If the server does not close the connection, the client <br>
may either issue a new authentication command and start again, or the <br>
client may issue the QUIT command. <br>
After the POP3 server has opened the maildrop, it assigns a message- <br>
number to each message, and notes the size of each message in octets. <br>
The first message in the maildrop is assigned a message-number of <br>
"1", the second is assigned "2", and so on, so that the nth message <br>
in a maildrop is assigned a message-number of "n". In POP3 commands <br>
and responses, all message-numbers and message sizes are expressed in <br>
base-10 (i.e., decimal). <br>
Here is the summary for the QUIT command when used in the <br>
AUTHORIZATION state: <br>
QUIT <br>
QUIT <br>
Arguments: none <br>
Restrictions: none <br>
Possible Responses: <br>
+OK <br>
Examples: <br>
C: QUIT <br>
S: +OK dewey POP3 server signing off <br>
5. The TRANSACTION State <br>
Once the client has successfully identified itself to the POP3 server <br>
and the POP3 server has locked and opened the appropriate maildrop, <br>
the POP3 session is now in the TRANSACTION state. The client may now <br>
issue any of the following POP3 commands repeatedly. After each <br>
command, the POP3 server issues a response. Eventually, the client <br>
issues the QUIT command and the POP3 session enters the UPDATE state. <br>
Myers & Rose Standards Track [Page 5] <br>
<br>
RFC 1939 POP3 May 1996 <br>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -