📄 420.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="421.htm">下一篇</a>]
<hr><p align="left"><small>发信人: hellow (收复台湾是我心), 信区: Embedded <br>
标 题: SMTP <br>
发信站: BBS 水木清华站 (Sun Nov 5 09:47:17 2000) <br>
<br>
<br>
RFC 821 <br>
<br>
<br>
<br>
<br>
<br>
SIMPLE MAIL TRANSFER PROTOCOL <br>
<br>
<br>
<br>
Jonathan B. Postel <br>
August 1982 <br>
<br>
<br>
<br>
Information Sciences Institute <br>
University of Southern California <br>
4676 Admiralty Way <br>
Marina del Rey, California 90291 <br>
(213) 822-1511 <br>
<br>
<br>
<br>
RFC 821 August 1982 <br>
Simple Mail Transfer Protocol <br>
TABLE OF CONTENTS <br>
1. INTRODUCTION .................................................. 1 <br>
2. THE SMTP MODEL ................................................ 2 <br>
3. THE SMTP PROCEDURE ............................................ 4 <br>
3.1. Mail ..................................................... 4 <br>
3.2. Forwarding ............................................... 7 <br>
3.3. Verifying and Expanding .................................. 8 <br>
3.4. Sending and Mailing ..................................... 11 <br>
3.5. Opening and Closing ..................................... 13 <br>
3.6. Relaying ................................................ 14 <br>
3.7. Domains ................................................. 17 <br>
3.8. Changing Roles .......................................... 18 <br>
4. THE SMTP SPECIFICATIONS ...................................... 19 <br>
4.1. SMTP Commands ........................................... 19 <br>
4.1.1. Command Semantics ..................................... 19 <br>
4.1.2. Command Syntax ........................................ 27 <br>
4.2. SMTP Replies ............................................ 34 <br>
4.2.1. Reply Codes by Function Group ......................... 35 <br>
4.2.2. Reply Codes in Numeric Order .......................... 36 <br>
4.3. Sequencing of Commands and Replies ...................... 37 <br>
4.4. State Diagrams .......................................... 39 <br>
4.5. Details ................................................. 41 <br>
4.5.1. Minimum Implementation ................................ 41 <br>
4.5.2. Transparency .......................................... 41 <br>
4.5.3. Sizes ................................................. 42 <br>
APPENDIX A: TCP ................................................. 44 <br>
APPENDIX B: NCP ................................................. 45 <br>
APPENDIX C: NITS ................................................ 46 <br>
APPENDIX D: X.25 ................................................ 47 <br>
APPENDIX E: Theory of Reply Codes ............................... 48 <br>
APPENDIX F: Scenarios ........................................... 51 <br>
GLOSSARY ......................................................... 64 <br>
REFERENCES ....................................................... 67 <br>
<br>
<br>
Network Working Group J. Postel <br>
Request for Comments: DRAFT ISI <br>
Replaces: RFC 788, 780, 772 August 1982 <br>
SIMPLE MAIL TRANSFER PROTOCOL <br>
1. INTRODUCTION <br>
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer <br>
mail reliably and efficiently. <br>
SMTP is independent of the particular transmission subsystem and <br>
requires only a reliable ordered data stream channel. Appendices A, <br>
B, C, and D describe the use of SMTP with various transport services. <br>
A Glossary provides the definitions of terms as used in this <br>
document. <br>
An important feature of SMTP is its capability to relay mail across <br>
transport service environments. A transport service provides an <br>
interprocess communication environment (IPCE). An IPCE may cover one <br>
network, several networks, or a subset of a network. It is important <br>
to realize that transport systems (or IPCEs) are not one-to-one with <br>
networks. A process can communicate directly with another process <br>
through any mutually known IPCE. Mail is an application or use of <br>
interprocess communication. Mail can be communicated between <br>
processes in different IPCEs by relaying through a process connected <br>
to two (or more) IPCEs. More specifically, mail can be relayed <br>
between hosts on different transport systems by a host on both <br>
transport systems. <br>
Postel [Page 1] <br>
<br>
<br>
August 1982 RFC 821 <br>
Simple Mail Transfer Protocol <br>
2. THE SMTP MODEL <br>
The SMTP design is based on the following model of communication: as <br>
the result of a user mail request, the sender-SMTP establishes a <br>
two-way transmission channel to a receiver-SMTP. The receiver-SMTP <br>
may be either the ultimate destination or an intermediate. SMTP <br>
commands are generated by the sender-SMTP and sent to the <br>
receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the <br>
sender-SMTP in response to the commands. <br>
Once the transmission channel is established, the SMTP-sender sends a <br>
MAIL command indicating the sender of the mail. If the SMTP-receiver <br>
can accept mail it responds with an OK reply. The SMTP-sender then <br>
sends a RCPT command identifying a recipient of the mail. If the <br>
SMTP-receiver can accept mail for that recipient it responds with an <br>
OK reply; if not, it responds with a reply rejecting that recipient <br>
(but not the whole mail transaction). The SMTP-sender and <br>
SMTP-receiver may negotiate several recipients. When the recipients <br>
have been negotiated the SMTP-sender sends the mail data, terminating <br>
with a special sequence. If the SMTP-receiver successfully processes <br>
the mail data it responds with an OK reply. The dialog is purposely <br>
lock-step, one-at-a-time. <br>
------------------------------------------------------------- <br>
<br>
+----------+ +----------+ <br>
+------+ | | | | <br>
| User |<-->| | SMTP | | <br>
+------+ | Sender- |Commands/Replies| Receiver-| <br>
+------+ | SMTP |<-------------->| SMTP | +------+ <br>
| File |<-->| | and Mail | |<-->| File | <br>
|System| | | | | |System| <br>
+------+ +----------+ +----------+ +------+ <br>
<br>
Sender-SMTP Receiver-SMTP <br>
Model for SMTP Use <br>
Figure 1 <br>
------------------------------------------------------------- <br>
The SMTP provides mechanisms for the transmission of mail; directly <br>
from the sending user's host to the receiving user's host when the <br>
[Page 2] Postel <br>
<br>
<br>
<br>
RFC 821 August 1982 <br>
Simple Mail Transfer Protocol <br>
two host are connected to the same transport service, or via one or <br>
more relay SMTP-servers when the source and destination hosts are not <br>
connected to the same transport service. <br>
To be able to provide the relay capability the SMTP-server must be <br>
supplied with the name of the ultimate destination host as well as <br>
the destination mailbox name. <br>
The argument to the MAIL command is a reverse-path, which specifies <br>
who the mail is from. The argument to the RCPT command is a <br>
forward-path, which specifies who the mail is to. The forward-path <br>
is a source route, while the reverse-path is a return route (which <br>
may be used to return a message to the sender when an error occurs <br>
with a relayed message). <br>
When the same message is sent to multiple recipients the SMTP <br>
encourages the transmission of only one copy of the data for all the <br>
recipients at the same destination host. <br>
The mail commands and replies have a rigid syntax. Replies also have <br>
a numeric code. In the following, examples appear which use actual <br>
commands and replies. The complete lists of commands and replies <br>
appears in Section 4 on specifications. <br>
Commands and replies are not case sensitive. That is, a command or <br>
reply word may be upper case, lower case, or any mixture of upper and <br>
lower case. Note that this is not true of mailbox user names. For <br>
some hosts the user name is case sensitive, and SMTP implementations <br>
must take case to preserve the case of user names as they appear in <br>
mailbox arguments. Host names are not case sensitive. <br>
Commands and replies are composed of characters from the ASCII <br>
character set [1]. When the transport service provides an 8-bit byte <br>
(octet) transmission channel, each 7-bit character is transmitted <br>
right justified in an octet with the high order bit cleared to zero. <br>
When specifying the general form of a command or reply, an argument <br>
(or special symbol) will be denoted by a meta-linguistic variable (or <br>
constant), for example, "<string>" or "<reverse-path>". Here the <br>
angle brackets indicate these are meta-linguistic variables. <br>
However, some arguments use the angle brackets literally. For <br>
example, an actual reverse-path is enclosed in angle brackets, i.e., <br>
"<John.Smith@USC-ISI.ARPA>" is an instance of <reverse-path> (the <br>
angle brackets are actually transmitted in the command or reply). <br>
Postel [Page 3] <br>
<br>
<br>
August 1982 RFC 821 <br>
Simple Mail Transfer Protocol <br>
3. THE SMTP PROCEDURES <br>
This section presents the procedures used in SMTP in several parts. <br>
First comes the basic mail procedure defined as a mail transaction. <br>
Following this are descriptions of forwarding mail, verifying mailbox <br>
names and expanding mailing lists, sending to terminals instead of or <br>
in combination with mailboxes, and the opening and closing exchanges. <br>
At the end of this section are comments on relaying, a note on mail <br>
domains, and a discussion of changing roles. Throughout this section <br>
are examples of partial command and reply sequences, several complete <br>
scenarios are presented in Appendix F. <br>
3.1. MAIL <br>
There are three steps to SMTP mail transactions. The transaction <br>
is started with a MAIL command which gives the sender <br>
identification. A series of one or more RCPT commands follows <br>
giving the receiver information. Then a DATA command gives the <br>
mail data. And finally, the end of mail data indicator confirms <br>
the transaction. <br>
The first step in the procedure is the MAIL command. The <br>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -