Network Working Group J. Klensin, Editor
Request for Comments: 2821 AT&T Laboratories
Obsoletes: 821, 974, 1869 April 2001
Updates: 1123
Category: Standards Track
Network Working Group J. Klensin, Editor
Request for Comments: 2821 AT&T Laboratories
Obsoletes: 821, 974, 1869 April 2001
Updates: 1123
Category: Standards Track
Simple Mail Transfer Protocol
简单邮件传输协议
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following:
本文档是互联网电子邮件传输基本协议的自包含规范。它整合、更新和澄清了以下功能，但不添加新功能或更改现有功能：
- the original SMTP (Simple Mail Transfer Protocol) specification of RFC 821 [30],
- RFC 821[30]的原始SMTP（简单邮件传输协议）规范，
- domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27],
- 来自RFC 1035[22]和RFC 974[27]的邮件传输的域名系统要求和影响，
- the clarifications and applicability statements in RFC 1123 [2], and
- RFC 1123[2]中的澄清和适用性声明，以及
- material drawn from the SMTP Extension mechanisms [19].
- 从SMTP扩展机制中提取的材料[19]。
It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models. Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821.
它淘汰了RFC 821、RFC 974，并更新了RFC 1123（取代了RFC 1123的邮件传输材料）。然而，RFC 821规定了一些到20世纪90年代中期在互联网上没有被大量使用的功能，以及（在附录中）一些额外的传输模型。为了清晰和简洁，此处省略这些部分；需要它们的读者应参考RFC 821。
It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have appeared as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually.
它还包括RFC1123中需要放大的一些额外材料。该材料已通过多种方式识别，主要是通过跟踪各种列表和新闻组上的flaming以及在部署SMTP扩展时出现的异常阅读或解释问题。如果本规范超出了合并范围，并且实际上与早期文档有所不同，则本规范将在技术上和文本上取代这些文档。
Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail submission' protocol, as recommended for POP [3, 26] and IMAP [6]. Additional submission issues are discussed in RFC 2476 [15].
尽管SMTP被设计为邮件传输和传递协议，但本规范还包含对其作为“邮件提交”协议的使用非常重要的信息，如POP[3,26]和IMAP[6]所建议的。RFC 2476[15]中讨论了其他提交问题。
Section 2.3 provides definitions of terms specific to this document. Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively.
第2.3节提供了本文件特定术语的定义。除非为了清楚起见需要使用历史术语，否则本文档使用当前的“客户端”和“服务器”术语分别标识发送和接收SMTP进程。
A companion document [32] discusses message headers, message bodies and formats and structures for them, and their relationship.
附带文档[32]讨论了消息头、消息体及其格式和结构，以及它们之间的关系。
Table of Contents
目录
1. Introduction .................................................. 4
2. The SMTP Model ................................................ 5
2.1 Basic Structure .............................................. 5
2.2 The Extension Model .......................................... 7
2.2.1 Background ................................................. 7
2.2.2 Definition and Registration of Extensions .................. 8
2.3 Terminology .................................................. 9
2.3.1 Mail Objects ............................................... 10
2.3.2 Senders and Receivers ...................................... 10
2.3.3 Mail Agents and Message Stores ............................. 10
2.3.4 Host ....................................................... 11
2.3.5 Domain ..................................................... 11
2.3.6 Buffer and State Table ..................................... 11
2.3.7 Lines ...................................................... 12
2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
2.3.9 Message Content and Mail Data .............................. 13
2.3.10 Mailbox and Address ....................................... 13
2.3.11 Reply ..................................................... 13
2.4 General Syntax Principles and Transaction Model .............. 13
3. The SMTP Procedures: An Overview .............................. 15
3.1 Session Initiation ........................................... 15
3.2 Client Initiation ............................................ 16
3.3 Mail Transactions ............................................ 16
3.4 Forwarding for Address Correction or Updating ................ 19
1. Introduction .................................................. 4
2. The SMTP Model ................................................ 5
2.1 Basic Structure .............................................. 5
2.2 The Extension Model .......................................... 7
2.2.1 Background ................................................. 7
2.2.2 Definition and Registration of Extensions .................. 8
2.3 Terminology .................................................. 9
2.3.1 Mail Objects ............................................... 10
2.3.2 Senders and Receivers ...................................... 10
2.3.3 Mail Agents and Message Stores ............................. 10
2.3.4 Host ....................................................... 11
2.3.5 Domain ..................................................... 11
2.3.6 Buffer and State Table ..................................... 11
2.3.7 Lines ...................................................... 12
2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
2.3.9 Message Content and Mail Data .............................. 13
2.3.10 Mailbox and Address ....................................... 13
2.3.11 Reply ..................................................... 13
2.4 General Syntax Principles and Transaction Model .............. 13
3. The SMTP Procedures: An Overview .............................. 15
3.1 Session Initiation ........................................... 15
3.2 Client Initiation ............................................ 16
3.3 Mail Transactions ............................................ 16
3.4 Forwarding for Address Correction or Updating ................ 19
3.5 Commands for Debugging Addresses ............................. 20
3.5.1 Overview ................................................... 20
3.5.2 VRFY Normal Response ....................................... 22
3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
3.5.4 Semantics and Applications of EXPN ......................... 23
3.6 Domains ...................................................... 23
3.7 Relaying ..................................................... 24
3.8 Mail Gatewaying .............................................. 25
3.8.1 Header Fields in Gatewaying ................................ 26
3.8.2 Received Lines in Gatewaying ............................... 26
3.8.3 Addresses in Gatewaying .................................... 26
3.8.4 Other Header Fields in Gatewaying .......................... 27
3.8.5 Envelopes in Gatewaying .................................... 27
3.9 Terminating Sessions and Connections ......................... 27
3.10 Mailing Lists and Aliases ................................... 28
3.10.1 Alias ..................................................... 28
3.10.2 List ...................................................... 28
4. The SMTP Specifications ....................................... 29
4.1 SMTP Commands ................................................ 29
4.1.1 Command Semantics and Syntax ............................... 29
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ................... 29
4.1.1.2 MAIL (MAIL) .............................................. 31
4.1.1.3 RECIPIENT (RCPT) ......................................... 31
4.1.1.4 DATA (DATA) .............................................. 33
4.1.1.5 RESET (RSET) ............................................. 34
4.1.1.6 VERIFY (VRFY) ............................................ 35
4.1.1.7 EXPAND (EXPN) ............................................ 35
4.1.1.8 HELP (HELP) .............................................. 35
4.1.1.9 NOOP (NOOP) .............................................. 35
4.1.1.10 QUIT (QUIT) ............................................. 36
4.1.2 Command Argument Syntax .................................... 36
4.1.3 Address Literals ........................................... 38
4.1.4 Order of Commands .......................................... 39
4.1.5 Private-use Commands ....................................... 40
4.2 SMTP Replies ................................................ 40
4.2.1 Reply Code Severities and Theory ........................... 42
4.2.2 Reply Codes by Function Groups ............................. 44
4.2.3 Reply Codes in Numeric Order .............................. 45
4.2.4 Reply Code 502 ............................................. 46
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
4.3 Sequencing of Commands and Replies ........................... 47
4.3.1 Sequencing Overview ........................................ 47
4.3.2 Command-Reply Sequences .................................... 48
4.4 Trace Information ............................................ 49
4.5 Additional Implementation Issues ............................. 53
4.5.1 Minimum Implementation ..................................... 53
4.5.2 Transparency ............................................... 53
4.5.3 Sizes and Timeouts ......................................... 54
3.5 Commands for Debugging Addresses ............................. 20
3.5.1 Overview ................................................... 20
3.5.2 VRFY Normal Response ....................................... 22
3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
3.5.4 Semantics and Applications of EXPN ......................... 23
3.6 Domains ...................................................... 23
3.7 Relaying ..................................................... 24
3.8 Mail Gatewaying .............................................. 25
3.8.1 Header Fields in Gatewaying ................................ 26
3.8.2 Received Lines in Gatewaying ............................... 26
3.8.3 Addresses in Gatewaying .................................... 26
3.8.4 Other Header Fields in Gatewaying .......................... 27
3.8.5 Envelopes in Gatewaying .................................... 27
3.9 Terminating Sessions and Connections ......................... 27
3.10 Mailing Lists and Aliases ................................... 28
3.10.1 Alias ..................................................... 28
3.10.2 List ...................................................... 28
4. The SMTP Specifications ....................................... 29
4.1 SMTP Commands ................................................ 29
4.1.1 Command Semantics and Syntax ............................... 29
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ................... 29
4.1.1.2 MAIL (MAIL) .............................................. 31
4.1.1.3 RECIPIENT (RCPT) ......................................... 31
4.1.1.4 DATA (DATA) .............................................. 33
4.1.1.5 RESET (RSET) ............................................. 34
4.1.1.6 VERIFY (VRFY) ............................................ 35
4.1.1.7 EXPAND (EXPN) ............................................ 35
4.1.1.8 HELP (HELP) .............................................. 35
4.1.1.9 NOOP (NOOP) .............................................. 35
4.1.1.10 QUIT (QUIT) ............................................. 36
4.1.2 Command Argument Syntax .................................... 36
4.1.3 Address Literals ........................................... 38
4.1.4 Order of Commands .......................................... 39
4.1.5 Private-use Commands ....................................... 40
4.2 SMTP Replies ................................................ 40
4.2.1 Reply Code Severities and Theory ........................... 42
4.2.2 Reply Codes by Function Groups ............................. 44
4.2.3 Reply Codes in Numeric Order .............................. 45
4.2.4 Reply Code 502 ............................................. 46
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
4.3 Sequencing of Commands and Replies ........................... 47
4.3.1 Sequencing Overview ........................................ 47
4.3.2 Command-Reply Sequences .................................... 48
4.4 Trace Information ............................................ 49
4.5 Additional Implementation Issues ............................. 53
4.5.1 Minimum Implementation ..................................... 53
4.5.2 Transparency ............................................... 53
4.5.3 Sizes and Timeouts ......................................... 54
4.5.3.1 Size limits and minimums ................................. 54
4.5.3.2 Timeouts ................................................. 56
4.5.4 Retry Strategies ........................................... 57
4.5.4.1 Sending Strategy ......................................... 58
4.5.4.2 Receiving Strategy ....................................... 59
4.5.5 Messages with a null reverse-path .......................... 59
5. Address Resolution and Mail Handling .......................... 60
6. Problem Detection and Handling ................................ 62
6.1 Reliable Delivery and Replies by Email ....................... 62
6.2 Loop Detection ............................................... 63
6.3 Compensating for Irregularities .............................. 63
7. Security Considerations ....................................... 64
7.1 Mail Security and Spoofing ................................... 64
7.2 "Blind" Copies ............................................... 65
7.3 VRFY, EXPN, and Security ..................................... 65
7.4 Information Disclosure in Announcements ...................... 66
7.5 Information Disclosure in Trace Fields ....................... 66
7.6 Information Disclosure in Message Forwarding ................. 67
7.7 Scope of Operation of SMTP Servers ........................... 67
8. IANA Considerations ........................................... 67
9. References .................................................... 68
10. Editor's Address ............................................. 70
11. Acknowledgments .............................................. 70
Appendices ....................................................... 71
A. TCP Transport Service ......................................... 71
B. Generating SMTP Commands from RFC 822 Headers ................. 71
C. Source Routes ................................................. 72
D. Scenarios ..................................................... 73
E. Other Gateway Issues .......................................... 76
F. Deprecated Features of RFC 821 ................................ 76
Full Copyright Statement ......................................... 79
4.5.3.1 Size limits and minimums ................................. 54
4.5.3.2 Timeouts ................................................. 56
4.5.4 Retry Strategies ........................................... 57
4.5.4.1 Sending Strategy ......................................... 58
4.5.4.2 Receiving Strategy ....................................... 59
4.5.5 Messages with a null reverse-path .......................... 59
5. Address Resolution and Mail Handling .......................... 60
6. Problem Detection and Handling ................................ 62
6.1 Reliable Delivery and Replies by Email ....................... 62
6.2 Loop Detection ............................................... 63
6.3 Compensating for Irregularities .............................. 63
7. Security Considerations ....................................... 64
7.1 Mail Security and Spoofing ................................... 64
7.2 "Blind" Copies ............................................... 65
7.3 VRFY, EXPN, and Security ..................................... 65
7.4 Information Disclosure in Announcements ...................... 66
7.5 Information Disclosure in Trace Fields ....................... 66
7.6 Information Disclosure in Message Forwarding ................. 67
7.7 Scope of Operation of SMTP Servers ........................... 67
8. IANA Considerations ........................................... 67
9. References .................................................... 68
10. Editor's Address ............................................. 70
11. Acknowledgments .............................................. 70
Appendices ....................................................... 71
A. TCP Transport Service ......................................... 71
B. Generating SMTP Commands from RFC 822 Headers ................. 71
C. Source Routes ................................................. 72
D. Scenarios ..................................................... 73
E. Other Gateway Issues .......................................... 76
F. Deprecated Features of RFC 821 ................................ 76
Full Copyright Statement ......................................... 79
The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.
简单邮件传输协议（SMTP）的目标是可靠和高效地传输邮件。
SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. While this document specifically discusses transport over TCP, other transports are possible. Appendices to RFC 821 describe some of them.
SMTP独立于特定的传输子系统，只需要可靠的有序数据流通道。虽然本文档专门讨论TCP上的传输，但也可以使用其他传输。RFC 821的附录描述了其中一些。
An important feature of SMTP is its capability to transport mail across networks, usually referred to as "SMTP mail relaying" (see section 3.8). A network consists of the mutually-TCP-accessible hosts on the public Internet, the mutually-TCP-accessible hosts on a firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN environment utilizing a non-TCP transport-level protocol. Using
SMTP的一个重要特性是它能够跨网络传输邮件，通常称为“SMTP邮件中继”（参见第3.8节）。网络由公共Internet上的可相互访问的TCP主机、防火墙隔离的TCP/IP Intranet上的可相互访问的TCP主机或使用非TCP传输级别协议的某些其他LAN或WAN环境中的主机组成。使用
SMTP, a process can transfer mail to another process on the same network or to some other network via a relay or gateway process accessible to both networks.
SMTP，一个进程可以通过两个网络都可以访问的中继或网关进程将邮件传输到同一网络上的另一个进程或其他网络。
In this way, a mail message may pass through a number of intermediate relay or gateway hosts on its path from sender to ultimate recipient. The Mail eXchanger mechanisms of the domain name system [22, 27] (and section 5 of this document) are used to identify the appropriate next-hop destination for a message being transported.
通过这种方式，邮件消息可以在其从发件人到最终收件人的路径上通过多个中间中继或网关主机。域名系统[22,27]（和本文件第5节）的邮件交换机制用于识别正在传输的邮件的适当下一跳目的地。
The SMTP design can be pictured as:
SMTP设计图如下所示：
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
When an SMTP client has a message to transmit, it establishes a two-way transmission channel to an SMTP server. The responsibility of an SMTP client is to transfer mail messages to one or more SMTP servers, or report its failure to do so.
当SMTP客户端有消息要传输时，它会建立到SMTP服务器的双向传输通道。SMTP客户端的职责是将邮件消息传输到一个或多个SMTP服务器，或报告其失败。
The means by which a mail message is presented to an SMTP client, and how that client determines the domain name(s) to which mail messages are to be transferred is a local matter, and is not addressed by this document. In some cases, the domain name(s) transferred to, or determined by, an SMTP client will identify the final destination(s) of the mail message. In other cases, common with SMTP clients associated with implementations of the POP [3, 26] or IMAP [6] protocols, or when the SMTP client is inside an isolated transport service environment, the domain name determined will identify an intermediate destination through which all mail messages are to be relayed. SMTP clients that transfer all traffic, regardless of the target domain names associated with the individual messages, or that do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable. Fully-capable SMTP implementations, including the relays used by these less capable
向SMTP客户端显示邮件的方式，以及该客户端如何确定邮件要传输到的域名，是本地问题，本文档不涉及。在某些情况下，传输到SMTP客户端或由SMTP客户端确定的域名将标识邮件的最终目的地。在其他情况下，与POP[3,26]或IMAP[6]协议的实现相关联的SMTP客户端常见，或者当SMTP客户端位于隔离的传输服务环境中时，所确定的域名将标识一个中间目的地，所有邮件消息将通过该目的地进行中继。传输所有通信量的SMTP客户端（无论与单个邮件关联的目标域名是什么），或者不维护用于重试最初无法完成的邮件传输的队列的SMTP客户端，可能符合此规范，但不被视为完全有能力。具有完全功能的SMTP实现，包括这些功能较弱的应用程序使用的中继
ones, and their destinations, are expected to support all of the queuing, retrying, and alternate address functions discussed in this specification.
它们及其目的地应支持本规范中讨论的所有排队、重试和备用地址函数。
The means by which an SMTP client, once it has determined a target domain name, determines the identity of an SMTP server to which a copy of a message is to be transferred, and then performs that transfer, is covered by this document. To effect a mail transfer to an SMTP server, an SMTP client establishes a two-way transmission channel to that SMTP server. An SMTP client determines the address of an appropriate host running an SMTP server by resolving a destination domain name to either an intermediate Mail eXchanger host or a final target host.
SMTP客户端在确定目标域名后，确定要将邮件副本传输到的SMTP服务器的标识，然后执行该传输的方法，将在本文档中介绍。要将邮件传输到SMTP服务器，SMTP客户端将建立到该SMTP服务器的双向传输通道。SMTP客户端通过将目标域名解析为中间邮件交换器主机或最终目标主机来确定运行SMTP服务器的适当主机的地址。
An SMTP server may be either the ultimate destination or an intermediate "relay" (that is, it may assume the role of an SMTP client after receiving the message) or "gateway" (that is, it may transport the message further using some protocol other than SMTP). SMTP commands are generated by the SMTP client and sent to the SMTP server. SMTP replies are sent from the SMTP server to the SMTP client in response to the commands.
SMTP服务器可以是最终目的地，也可以是中间“中继”（也就是说，它可以在收到邮件后担任SMTP客户端的角色）或“网关”（也就是说，它可以使用SMTP以外的其他协议进一步传输邮件）。SMTP命令由SMTP客户端生成并发送到SMTP服务器。SMTP回复从SMTP服务器发送到SMTP客户端以响应命令。
In other words, message transfer can occur in a single connection between the original SMTP-sender and the final SMTP-recipient, or can occur in a series of hops through intermediary systems. In either case, a formal handoff of responsibility for the message occurs: the protocol requires that a server accept responsibility for either delivering a message or properly reporting the failure to do so.
换句话说，邮件传输可以在原始SMTP发件人和最终SMTP收件人之间的单个连接中发生，也可以通过中间系统在一系列跃点中发生。在任何一种情况下，都会发生消息责任的正式移交：协议要求服务器承担传递消息的责任或正确报告未能传递消息的责任。
Once the transmission channel is established and initial handshaking completed, the SMTP client normally initiates a mail transaction. Such a transaction consists of a series of commands to specify the originator and destination of the mail and transmission of the message content (including any headers or other structure) itself. When the same message is sent to multiple recipients, this protocol encourages the transmission of only one copy of the data for all recipients at the same destination (or intermediate relay) host.
一旦建立传输通道并完成初始握手，SMTP客户端通常会启动邮件事务。此类事务由一系列命令组成，用于指定邮件的原始发件人和目的地，以及消息内容（包括任何标题或其他结构）本身的传输。当同一消息发送给多个收件人时，此协议鼓励在同一目标（或中间中继）主机上为所有收件人仅传输一份数据副本。
The server responds to each command with a reply; replies may indicate that the command was accepted, that additional commands are expected, or that a temporary or permanent error condition exists. Commands specifying the sender or recipients may include server-permitted SMTP service extension requests as discussed in section 2.2. The dialog is purposely lock-step, one-at-a-time, although this can be modified by mutually-agreed extension requests such as command pipelining [13].
服务器响应每个命令并给出回复；答复可能表明该命令已被接受，预期会有其他命令，或者存在临时或永久性错误情况。指定发件人或收件人的命令可能包括服务器允许的SMTP服务扩展请求，如第2.2节所述。该对话框有意地一次锁定一个步骤，尽管这可以通过双方同意的扩展请求（如命令管道）进行修改[13]。
Once a given mail message has been transmitted, the client may either request that the connection be shut down or may initiate other mail transactions. In addition, an SMTP client may use a connection to an SMTP server for ancillary services such as verification of email addresses or retrieval of mailing list subscriber addresses.
一旦发送了给定的邮件消息，客户端可以请求关闭连接，也可以启动其他邮件事务。此外，SMTP客户端可以使用到SMTP服务器的连接来提供辅助服务，例如验证电子邮件地址或检索邮件列表订户地址。
As suggested above, this protocol provides mechanisms for the transmission of mail. This transmission normally occurs directly from the sending user's host to the receiving user's host when the two hosts are connected to the same transport service. When they are not connected to the same transport service, transmission occurs via one or more relay SMTP servers. An intermediate host that acts as either an SMTP relay or as a gateway into some other transmission environment is usually selected through the use of the domain name service (DNS) Mail eXchanger mechanism.
如上所述，该协议提供了邮件传输机制。当两台主机连接到同一传输服务时，此传输通常直接从发送用户的主机发送到接收用户的主机。当它们未连接到同一传输服务时，将通过一个或多个中继SMTP服务器进行传输。通常通过使用域名服务（DNS）邮件交换机制选择充当SMTP中继或进入其他传输环境的网关的中间主机。
Usually, intermediate hosts are determined via the DNS MX record, not by explicit "source" routing (see section 5 and appendices C and F.2).
通常，中间主机通过DNS MX记录确定，而不是通过明确的“源”路由确定（见第5节和附录C和F.2）。
In an effort that started in 1990, approximately a decade after RFC 821 was completed, the protocol was modified with a "service extensions" model that permits the client and server to agree to utilize shared functionality beyond the original SMTP requirements. The SMTP extension mechanism defines a means whereby an extended SMTP client and server may recognize each other, and the server can inform the client as to the service extensions that it supports.
在RFC 821完成大约十年后的1990年开始的一项工作中，协议被修改为“服务扩展”模型，允许客户端和服务器同意使用原始SMTP要求之外的共享功能。SMTP扩展机制定义了一种方式，通过这种方式，扩展SMTP客户端和服务器可以相互识别，并且服务器可以通知客户端它支持的服务扩展。
Contemporary SMTP implementations MUST support the basic extension mechanisms. For instance, servers MUST support the EHLO command even if they do not implement any specific extensions and clients SHOULD preferentially utilize EHLO rather than HELO. (However, for compatibility with older conforming implementations, SMTP clients and servers MUST support the original HELO mechanisms as a fallback.) Unless the different characteristics of HELO must be identified for interoperability purposes, this document discusses only EHLO.
现代SMTP实现必须支持基本的扩展机制。例如，服务器必须支持EHLO命令，即使它们没有实现任何特定的扩展，并且客户端应该优先使用EHLO而不是HELO。（但是，为了与旧的一致性实现兼容，SMTP客户端和服务器必须支持原始HELO机制作为备用方案。）除非为了互操作性目的必须确定HELO的不同特征，否则本文档仅讨论EHLO。
SMTP is widely deployed and high-quality implementations have proven to be very robust. However, the Internet community now considers some services to be important that were not anticipated when the protocol was first designed. If support for those services is to be added, it must be done in a way that permits older implementations to continue working acceptably. The extension framework consists of:
SMTP被广泛部署，高质量的实现已被证明非常健壮。然而，互联网社区现在认为一些服务很重要，而这些服务在协议最初设计时是没有预料到的。如果要添加对这些服务的支持，则必须以允许旧的实现继续正常工作的方式进行。扩展框架包括：
- The SMTP command EHLO, superseding the earlier HELO,
- SMTP命令EHLO取代了早期的HELO，
- a registry of SMTP service extensions,
- SMTP服务扩展的注册表，
- additional parameters to the SMTP MAIL and RCPT commands, and
- SMTP邮件和RCPT命令的其他参数，以及
- optional replacements for commands defined in this protocol, such as for DATA in non-ASCII transmissions [33].
- 本协议中定义的命令的可选替代品，如非ASCII传输中的数据[33]。
SMTP's strength comes primarily from its simplicity. Experience with many protocols has shown that protocols with few options tend towards ubiquity, whereas protocols with many options tend towards obscurity.
SMTP的优势主要来自其简单性。许多协议的经验表明，选项少的协议趋向于普遍存在，而选项多的协议趋向于模糊。
Each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs. In many cases, the cost of extending the SMTP service will likely outweigh the benefit.
每一个扩展，无论其好处如何，都必须仔细检查其实现、部署和互操作性成本。在许多情况下，扩展SMTP服务的成本可能会超过好处。
The IANA maintains a registry of SMTP service extensions. A corresponding EHLO keyword value is associated with each extension. Each service extension registered with the IANA must be defined in a formal standards-track or IESG-approved experimental protocol document. The definition must include:
IANA维护SMTP服务扩展的注册表。相应的EHLO关键字值与每个扩展相关联。在IANA注册的每个服务扩展必须在正式的标准跟踪或IESG批准的实验协议文件中定义。定义必须包括：
- the textual name of the SMTP service extension;
- SMTP服务扩展的文本名称；
- the EHLO keyword value associated with the extension;
- 与扩展关联的EHLO关键字值；
- the syntax and possible values of parameters associated with the EHLO keyword value;
- 与EHLO关键字值关联的参数的语法和可能值；
- any additional SMTP verbs associated with the extension (additional verbs will usually be, but are not required to be, the same as the EHLO keyword value);
- 与扩展名关联的任何其他SMTP谓词（其他谓词通常与EHLO关键字值相同，但不要求相同）；
- any new parameters the extension associates with the MAIL or RCPT verbs;
- 扩展名与MAIL或RCPT谓词关联的任何新参数；
- a description of how support for the extension affects the behavior of a server and client SMTP; and,
- 对扩展支持如何影响服务器和客户端SMTP行为的描述；和
- the increment by which the extension is increasing the maximum length of the commands MAIL and/or RCPT, over that specified in this standard.
- 扩展插件将命令MAIL和/或RCPT的最大长度增加到本标准规定长度的增量。
In addition, any EHLO keyword value starting with an upper or lower case "X" refers to a local SMTP service extension used exclusively through bilateral agreement. Keywords beginning with "X" MUST NOT be used in a registered service extension. Conversely, keyword values presented in the EHLO response that do not begin with "X" MUST correspond to a standard, standards-track, or IESG-approved experimental SMTP service extension registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed keyword values that are not described in a registered extension.
此外，任何以大写或小写“X”开头的EHLO关键字值都是指仅通过双边协议使用的本地SMTP服务扩展。以“X”开头的关键字不得在已注册的服务扩展中使用。相反，EHLO响应中显示的不以“X”开头的关键字值必须对应于在IANA注册的标准、标准跟踪或IESG批准的实验性SMTP服务扩展。一致性服务器不得提供未在注册扩展中描述的非“X”前缀关键字值。
Additional verbs and parameter names are bound by the same rules as EHLO keywords; specifically, verbs beginning with "X" are local extensions that may not be registered or standardized. Conversely, verbs not beginning with "X" must always be registered.
其他动词和参数名称与EHLO关键字受相同规则约束；具体来说，以“X”开头的动词是可能未注册或标准化的本地扩展名。相反，不以“X”开头的动词必须始终注册。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described below.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按以下说明进行解释。
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
1. 该词或术语“要求”或“应”必须表示该定义是本规范的绝对要求。
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
2. 该短语或短语“不得”不得表示该定义是对本规范的绝对禁止。
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
3. 这个词或形容词“推荐”是否意味着在特定情况下可能存在忽略特定项目的正当理由，但在选择不同课程之前，必须理解并仔细权衡其全部含义。
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
4. 该短语或短语“不建议”不应意味着在特定情况下，当特定行为可接受或甚至有用时，可能存在有效的理由，但在实施本标签所述的任何行为之前，应理解其全部含义并仔细权衡情况。
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which
5. 这个词，或者形容词“可选”可能意味着一个项目是真正可选的。一个供应商可能会选择包含该项目，因为特定市场需要该项目，或者因为该供应商认为该项目增强了产品，而另一个供应商可能会忽略该项目。不包含特定选项的实现必须准备好与另一个包含该选项的实现进行互操作，尽管功能可能有所减少。同样，一个实现
does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
是否包含特定选项必须准备好与不包含该选项的另一个实现进行互操作（当然，该选项提供的功能除外）
SMTP transports a mail object. A mail object contains an envelope and content.
SMTP传输邮件对象。邮件对象包含信封和内容。
The SMTP envelope is sent as a series of SMTP protocol units (described in section 3). It consists of an originator address (to which error reports should be directed); one or more recipient addresses; and optional protocol extension material. Historically, variations on the recipient address specification command (RCPT TO) could be used to specify alternate delivery modes, such as immediate display; those variations have now been deprecated (see appendix F, section F.6).
SMTP信封作为一系列SMTP协议单元发送（如第3节所述）。它包括发起者地址（错误报告应指向该地址）；一个或多个收件人地址；和《任择议定书》延伸材料。历史上，收件人地址规范命令（RCPT TO）的变体可用于指定替代传递模式，如即时显示；这些变体现已被弃用（见附录F第F.6节）。
The SMTP content is sent in the SMTP DATA protocol unit and has two parts: the headers and the body. If the content conforms to other contemporary standards, the headers form a collection of field/value pairs structured as in the message format specification [32]; the body, if structured, is defined according to MIME [12]. The content is textual in nature, expressed using the US-ASCII repertoire [1]. Although SMTP extensions (such as "8BITMIME" [20]) may relax this restriction for the content body, the content headers are always encoded using the US-ASCII repertoire. A MIME extension [23] defines an algorithm for representing header values outside the US-ASCII repertoire, while still encoding them using the US-ASCII repertoire.
SMTP内容在SMTP数据协议单元中发送，包含两部分：标题和正文。如果内容符合其他当代标准，则标题将形成一组字段/值对，其结构与消息格式规范[32]中的结构相同；主体（如果是结构化的）是根据MIME[12]定义的。内容本质上是文本，使用US-ASCII指令表[1]表示。尽管SMTP扩展（如“8BITMIME”[20]）可能会放宽对内容正文的限制，但内容头始终使用US-ASCII指令表进行编码。MIME扩展[23]定义了一种算法，用于表示US-ASCII指令表之外的头值，同时仍使用US-ASCII指令表对其进行编码。
In RFC 821, the two hosts participating in an SMTP transaction were described as the "SMTP-sender" and "SMTP-receiver". This document has been changed to reflect current industry terminology and hence refers to them as the "SMTP client" (or sometimes just "the client") and "SMTP server" (or just "the server"), respectively. Since a given host may act both as server and client in a relay situation, "receiver" and "sender" terminology is still used where needed for clarity.
在RFC 821中，参与SMTP事务的两台主机被描述为“SMTP发送方”和“SMTP接收方”。本文档已更改，以反映当前的行业术语，因此将其分别称为“SMTP客户端”（或有时仅称为“客户端”）和“SMTP服务器”（或仅称为“服务器”）。由于给定的主机在中继情况下可能同时充当服务器和客户端，因此为了清晰起见，在需要时仍然使用“接收方”和“发送方”术语。
Additional mail system terminology became common after RFC 821 was published and, where convenient, is used in this specification. In particular, SMTP servers and clients provide a mail transport service and therefore act as "Mail Transfer Agents" (MTAs). "Mail User Agents" (MUAs or UAs) are normally thought of as the sources and
RFC 821发布后，额外的邮件系统术语变得很常见，并在方便的情况下用于本规范。特别是，SMTP服务器和客户端提供邮件传输服务，因此充当“邮件传输代理”（MTA）。“邮件用户代理”（MUA或UAs）通常被认为是源和
targets of mail. At the source, an MUA might collect mail to be transmitted from a user and hand it off to an MTA; the final ("delivery") MTA would be thought of as handing the mail off to an MUA (or at least transferring responsibility to it, e.g., by depositing the message in a "message store"). However, while these terms are used with at least the appearance of great precision in other environments, the implied boundaries between MUAs and MTAs often do not accurately match common, and conforming, practices with Internet mail. Hence, the reader should be cautious about inferring the strong relationships and responsibilities that might be implied if these terms were used elsewhere.
邮件的目标。从源头上讲，MUA可能会收集用户发送的邮件并将其转交给MTA；最终（“交付”）MTA将被视为将邮件交给MUA（或至少将责任转移给MUA，例如，将邮件存放在“邮件存储”中）。然而，尽管这些术语在其他环境中至少看起来非常精确，但MUA和MTA之间的隐含边界通常无法准确匹配Internet邮件的常见一致做法。因此，读者在推断这些术语在其他地方使用时可能隐含的强烈关系和责任时应谨慎。
For the purposes of this specification, a host is a computer system attached to the Internet (or, in some cases, to a private TCP/IP network) and supporting the SMTP protocol. Hosts are known by names (see "domain"); identifying them by numerical address is discouraged.
在本规范中，主机是连接到Internet（或在某些情况下连接到专用TCP/IP网络）并支持SMTP协议的计算机系统。主机名称已知（见“域”）；不鼓励通过数字地址识别它们。
A domain (or domain name) consists of one or more dot-separated components. These components ("labels" in DNS terminology [22]) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set [1]. Domain names are used as names of hosts and of other entities in the domain name hierarchy. For example, a domain may refer to an alias (label of a CNAME RR) or the label of Mail eXchanger records to be used to deliver mail instead of representing a host name. See [22] and section 5 of this specification.
域（或域名）由一个或多个点分隔的组件组成。出于SMTP目的，这些组件（“DNS术语[22]中的标签”）被限制为由从ASCII字符集[1]中提取的字母、数字和连字符序列组成。域名用作域名层次结构中主机和其他实体的名称。例如，域可能引用别名（CNAME RR的标签）或用于传递邮件的邮件交换器记录的标签，而不是表示主机名。参见本规范第[22]节和第5节。
The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.
如本文档和[22]所述，域名是完整的、完全限定的名称（通常称为“FQDN”）。非FQDN形式的域名只不过是本地别名。本地别名不得出现在任何SMTP事务中。
SMTP sessions are stateful, with both parties carefully maintaining a common view of the current state. In this document we model this state by a virtual "buffer" and a "state table" on the server which may be used by the client to, for example, "clear the buffer" or "reset the state table," causing the information in the buffer to be discarded and the state to be returned to some previous state.
SMTP会话是有状态的，双方小心地维护当前状态的共同视图。在本文档中，我们通过服务器上的虚拟“缓冲区”和“状态表”对该状态进行建模，客户机可以使用该虚拟“缓冲区”和“状态表”来“清除缓冲区”或“重置状态表”，从而丢弃缓冲区中的信息，并将状态返回到以前的某个状态。
SMTP commands and, unless altered by a service extension, message data, are transmitted in "lines". Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A). This termination sequence is denoted as <CRLF> in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see section 4.5.3).
SMTP命令和消息数据（除非由服务扩展更改）以“行”方式传输。行由零个或多个数据字符组成，以序列ASCII字符“CR”（十六进制值0D）结尾，后跟ASCII字符“LF”（十六进制值0A）。该终止顺序在本文件中表示为<CRLF>。一致性实现不得识别或生成任何其他字符或字符序列作为行终止符。服务器可对线路长度施加限制（见第4.5.3节）。
In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence.
此外，文本中出现的“裸”、“CR”或“LF”字符（即没有其他字符）在邮件实现和使用邮件系统作为工具的应用程序中造成问题的历史由来已久。SMTP客户端实现不得传输这些字符，除非它们用作行终止符，然后必须（如上所述）仅作为<CRLF>序列传输它们。
This specification makes a distinction among four types of SMTP systems, based on the role those systems play in transmitting electronic mail. An "originating" system (sometimes called an SMTP originator) introduces mail into the Internet or, more generally, into a transport service environment. A "delivery" SMTP system is one that receives mail from a transport service environment and passes it to a mail user agent or deposits it in a message store which a mail user agent is expected to subsequently access. A "relay" SMTP system (usually referred to just as a "relay") receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery.
本规范根据四种SMTP系统在传输电子邮件中所起的作用，对它们进行了区分。“原始”系统（有时称为SMTP原始发件人）将邮件引入Internet，或者更一般地说，引入传输服务环境。“传递”SMTP系统是一种从传输服务环境接收邮件并将其传递给邮件用户代理或将其存放在邮件用户代理预期随后访问的邮件存储中的系统。“中继”SMTP系统（通常称为“中继”）从SMTP客户端接收邮件，并将其传输到另一个SMTP服务器，以进行进一步中继或传递，而无需修改邮件数据（添加跟踪信息除外）。
A "gateway" SMTP system (usually referred to just as a "gateway") receives mail from a client system in one transport environment and transmits it to a server system in another transport environment. Differences in protocols or message semantics between the transport environments on either side of a gateway may require that the gateway system perform transformations to the message that are not permitted to SMTP relay systems. For the purposes of this specification, firewalls that rewrite addresses should be considered as gateways, even if SMTP is used on both sides of them (see [11]).
“网关”SMTP系统（通常称为“网关”）从一个传输环境中的客户端系统接收邮件，并将其传输到另一个传输环境中的服务器系统。网关两侧传输环境之间的协议或消息语义差异可能要求网关系统对SMTP中继系统不允许的消息执行转换。就本规范而言，重写地址的防火墙应被视为网关，即使它们的两侧都使用SMTP（请参见[11]）。
The terms "message content" and "mail data" are used interchangeably in this document to describe the material transmitted after the DATA command is accepted and before the end of data indication is transmitted. Message content includes message headers and the possibly-structured message body. The MIME specification [12] provides the standard mechanisms for structured message bodies.
在本文件中，术语“消息内容”和“邮件数据”可互换使用，用于描述在接受数据命令后和传输数据结束指示之前传输的材料。消息内容包括消息头和可能结构化的消息体。MIME规范[12]为结构化消息体提供了标准机制。
As used in this specification, an "address" is a character string that identifies a user to whom mail will be sent or a location into which mail will be deposited. The term "mailbox" refers to that depository. The two terms are typically used interchangeably unless the distinction between the location in which mail is placed (the mailbox) and a reference to it (the address) is important. An address normally consists of user and domain specifications. The standard mailbox naming convention is defined to be "local-part@domain": contemporary usage permits a much broader set of applications than simple "user names". Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
在本规范中，“地址”是一个字符串，用于标识邮件将发送到的用户或邮件将存放到的位置。“邮箱”一词是指该保管机构。这两个术语通常可以互换使用，除非邮件放置位置（邮箱）和对其的引用（地址）之间的区别很重要。地址通常由用户和域规范组成。标准邮箱命名约定定义为“本地”-part@domain：与简单的“用户名”相比，现代用法允许更广泛的应用程序集。因此，由于中间主机试图通过修改它们来优化传输时长期存在问题，因此必须仅由地址的域部分中指定的主机来解释和分配本地部分的语义。
An SMTP reply is an acknowledgment (positive or negative) sent from receiver to sender via the transmission channel in response to a command. The general form of a reply is a numeric completion code (indicating failure or success) usually followed by a text string. The codes are for use by programs and the text is usually intended for human users. Recent work [34] has specified further structuring of the reply strings, including the use of supplemental and more specific completion codes.
SMTP回复是接收方通过传输通道向发送方发送的确认（肯定或否定），以响应命令。回复的一般形式是数字完成码（表示失败或成功），通常后跟文本字符串。代码供程序使用，文本通常供人类用户使用。最近的工作[34]规定了回复字符串的进一步结构，包括使用补充和更具体的完成代码。
SMTP commands and replies have a rigid syntax. All commands begin with a command verb. All Replies begin with a three digit numeric code. In some commands and replies, arguments MUST follow the verb or reply code. Some commands do not accept arguments (after the verb), and some reply codes are followed, sometimes optionally, by free form text. In both cases, where text appears, it is separated from the verb or reply code by a space character. Complete definitions of commands and replies appear in section 4.
SMTP命令和回复具有严格的语法。所有命令都以命令动词开头。所有回复都以三位数字代码开头。在某些命令和回复中，参数必须跟在动词或回复代码后面。有些命令不接受参数（在动词之后），有些回复代码后面是自由格式的文本，有时是可选的。在这两种情况下，出现文本时，文本与动词或回复代码之间用空格字符分隔。命令和回复的完整定义见第4节。
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part (SMTP Extensions may explicitly specify case-sensitive elements). That is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning. This is NOT true of a mailbox local-part. The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. Mailbox domains are not case sensitive. In particular, for some hosts the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.
动词和参数值（例如，RCPT命令中的“TO:”或“TO:”以及扩展名关键字）不区分大小写，本规范中唯一的例外是邮箱本地部分（SMTP扩展可能明确指定区分大小写的元素）。也就是说，命令动词、参数值（邮箱本地部分除外）和自由格式文本可以用大写、小写或大写和小写的任意组合进行编码，而不会影响其含义。对于邮箱本地部分，情况并非如此。邮箱的本地部分必须视为区分大小写。因此，SMTP实现必须注意保留邮箱本地部分的情况。邮箱域不区分大小写。特别是，对于某些主机，用户“smith”与用户“smith”不同。但是，利用邮箱本地部分的大小写敏感性会妨碍互操作性，因此不鼓励这样做。
A few SMTP servers, in violation of this specification (and RFC 821) require that command verbs be encoded by clients in upper case. Implementations MAY wish to employ this encoding to accommodate those servers.
少数SMTP服务器违反了此规范（和RFC 821），要求客户端以大写形式对命令谓词进行编码。实现可能希望使用这种编码来适应这些服务器。
The argument field consists of a variable length character string ending with the end of the line, i.e., with the character sequence <CRLF>. The receiver will take no action until this sequence is received.
参数字段由以行尾结尾的可变长度字符串组成，即以字符序列<CRLF>结尾。在接收到该序列之前，接收器不会采取任何行动。
The syntax for each command is shown with the discussion of that command. Common elements and parameters are shown in section 4.1.2.
每个命令的语法将在讨论该命令时显示。通用元件和参数见第4.1.2节。
Commands and replies are composed of characters from the ASCII character set [1]. When the transport service provides an 8-bit byte (octet) transmission channel, each 7-bit character is transmitted right justified in an octet with the high order bit cleared to zero. More specifically, the unextended SMTP service provides seven bit transport only. An originating SMTP client which has not successfully negotiated an appropriate extension with a particular server MUST NOT transmit messages with information in the high-order bit of octets. If such messages are transmitted in violation of this rule, receiving SMTP servers MAY clear the high-order bit or reject the message as invalid. In general, a relay SMTP SHOULD assume that the message content it has received is valid and, assuming that the envelope permits doing so, relay it without inspecting that content. Of course, if the content is mislabeled and the data path cannot accept the actual content, this may result in ultimate delivery of a severely garbled message to the recipient. Delivery SMTP systems MAY reject ("bounce") such messages rather than deliver them. No sending SMTP system is permitted to send envelope commands in any character
命令和回复由ASCII字符集[1]中的字符组成。当传输服务提供8位字节（八位字节）传输通道时，每个7位字符在八位字节中以右对齐方式传输，高阶位清除为零。更具体地说，未扩展的SMTP服务仅提供七位传输。未成功与特定服务器协商适当扩展的原始SMTP客户端不得传输包含八位字节高位信息的邮件。如果此类邮件的传输违反了此规则，则接收SMTP服务器可能会清除高阶位或将邮件视为无效而拒绝。通常，SMTP中继应该假定它接收到的邮件内容是有效的，并且假定信封允许这样做，则在不检查该内容的情况下中继它。当然，如果内容被错误标记，并且数据路径无法接受实际内容，这可能会导致最终向收件人发送严重混乱的消息。传递SMTP系统可能拒绝（“反弹”）此类邮件，而不是传递它们。发送SMTP系统不允许发送任何字符的信封命令
set other than US-ASCII; receiving systems SHOULD reject such commands, normally using "500 syntax error - invalid character" replies.
除US-ASCII之外的其他设置；接收系统应拒绝此类命令，通常使用“500语法错误-无效字符”回复。
Eight-bit message content transmission MAY be requested of the server by a client using extended SMTP facilities, notably the "8BITMIME" extension [20]. 8BITMIME SHOULD be supported by SMTP servers. However, it MUST not be construed as authorization to transmit unrestricted eight bit material. 8BITMIME MUST NOT be requested by senders for material with the high bit on that is not in MIME format with an appropriate content-transfer encoding; servers MAY reject such messages.
客户端可以使用扩展的SMTP设施（尤其是“8BITMIME”扩展）向服务器请求八位消息内容传输[20]。SMTP服务器应支持8BITMIME。但是，不得将其解释为授权传输不受限制的八位材料。8BITMIME不得由发送者请求具有高位的材料，该材料不是具有适当内容传输编码的MIME格式；服务器可能会拒绝此类消息。
The metalinguistic notation used in this document corresponds to the "Augmented BNF" used in other Internet mail system documents. The reader who is not familiar with that syntax should consult the ABNF specification [8]. Metalanguage terms used in running text are surrounded by pointed brackets (e.g., <CRLF>) for clarity.
本文档中使用的元语言符号对应于其他Internet邮件系统文档中使用的“增强BNF”。不熟悉该语法的读者应参考ABNF规范[8]。为清晰起见，运行文本中使用的元语言术语被尖括号（例如，<CRLF>）包围。
This section contains descriptions of the procedures used in SMTP: session initiation, the mail transaction, forwarding mail, verifying mailbox names and expanding mailing lists, and the opening and closing exchanges. Comments on relaying, a note on mail domains, and a discussion of changing roles are included at the end of this section. Several complete scenarios are presented in appendix D.
本节介绍SMTP中使用的过程：会话启动、邮件事务、转发邮件、验证邮箱名称和扩展邮件列表，以及打开和关闭交换。关于中继的评论，关于邮件域的说明，以及关于角色变化的讨论都包含在本节末尾。附录D中给出了几个完整的场景。
An SMTP session is initiated when a client opens a connection to a server and the server responds with an opening message.
当客户端打开与服务器的连接，服务器以打开消息作出响应时，SMTP会话将启动。
SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems. Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns. While some systems also identify their contact point for mail problems, this is not a substitute for maintaining the required "postmaster" address (see section 4.5.1).
SMTP服务器实现可能包括在220代码后的连接回复中标识其软件和版本信息，这一做法允许更有效地隔离和修复任何问题。实施可能会为SMTP服务器做出规定，以便在软件和版本公告引起安全问题时禁用该软件和版本公告。虽然一些系统也会识别邮件问题的联系点，但这并不能代替维护所需的“邮政局长”地址（见第4.5.1节）。
The SMTP protocol allows a server to formally reject a transaction while still allowing the initial connection as follows: a 554 response MAY be given in the initial connection opening message instead of the 220. A server taking this approach MUST still wait for the client to send a QUIT (see section 4.1.1.10) before closing the connection and SHOULD respond to any intervening commands with
SMTP协议允许服务器正式拒绝事务，同时仍允许初始连接，如下所示：初始连接打开消息中可能会给出554响应，而不是220响应。采用这种方法的服务器在关闭连接之前必须等待客户端发送QUIT（请参阅第4.1.1.10节），并应使用
"503 bad sequence of commands". Since an attempt to make an SMTP connection to such a system is probably in error, a server returning a 554 response on connection opening SHOULD provide enough information in the reply text to facilitate debugging of the sending system.
“503错误的命令顺序”。由于尝试与此类系统建立SMTP连接可能出错，因此在打开连接时返回554响应的服务器应在回复文本中提供足够的信息，以便于调试发送系统。
Once the server has sent the welcoming message and the client has received it, the client normally sends the EHLO command to the server, indicating the client's identity. In addition to opening the session, use of EHLO indicates that the client is able to process service extensions and requests that the server provide a list of the extensions it supports. Older SMTP systems which are unable to support service extensions and contemporary clients which do not require service extensions in the mail session being initiated, MAY use HELO instead of EHLO. Servers MUST NOT return the extended EHLO-style response to a HELO command. For a particular connection attempt, if the server returns a "command not recognized" response to EHLO, the client SHOULD be able to fall back and send HELO.
一旦服务器发送了欢迎消息并且客户端接收到它，客户端通常会向服务器发送EHLO命令，指示客户端的身份。除了打开会话外，使用EHLO还表明客户端能够处理服务扩展和请求，服务器提供其支持的扩展列表。无法支持服务扩展的旧SMTP系统和在启动的邮件会话中不需要服务扩展的当代客户端可以使用HELO而不是EHLO。服务器不得向HELO命令返回扩展EHLO样式的响应。对于特定的连接尝试，如果服务器向EHLO返回“command not recognized”（命令未识别）响应，则客户端应该能够回退并发送HELO。
In the EHLO command the host sending the command identifies itself; the command may be interpreted as saying "Hello, I am <domain>" (and, in the case of EHLO, "and I support service extension requests").
在EHLO命令中，发送命令的主机标识自己；该命令可以解释为说“你好，我是<domain>”（对于EHLO，“我支持服务扩展请求”）。
There are three steps to SMTP mail transactions. The transaction starts with a MAIL command which gives the sender identification. (In general, the MAIL command may be sent only when no mail transaction is in progress; see section 4.1.4.) A series of one or more RCPT commands follows giving the receiver information. Then a DATA command initiates transfer of the mail data and is terminated by the "end of mail" data indicator, which also confirms the transaction.
SMTP邮件事务处理分为三个步骤。事务以一个MAIL命令开始，该命令提供发送者标识。（通常，只有在没有进行邮件交易时，才可以发送邮件命令；请参见第4.1.4节。）随后，一系列一个或多个RCPT命令会提供接收方信息。然后，数据命令启动邮件数据的传输，并由“邮件结束”数据指示符终止，该指示符还确认事务。
The first step in the procedure is the MAIL command.
该过程的第一步是MAIL命令。
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. The <reverse-path> portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors (see section 4.2 for a discussion of error reporting). If accepted, the SMTP server returns a 250 OK reply. If the mailbox specification is not acceptable for some reason, the server MUST return a reply indicating whether the
此命令告知SMTP收件人新邮件事务正在启动，并重置其所有状态表和缓冲区，包括任何收件人或邮件数据。第一个或唯一参数的<reverse path>部分包含源邮箱（在“<”和“>”括号之间），可用于报告错误（有关错误报告的讨论，请参阅第4.2节）。如果接受，SMTP服务器将返回250 OK回复。如果邮箱规范由于某种原因不可接受，服务器必须返回一个回复，指示
failure is permanent (i.e., will occur again if the client tries to send the same address again) or temporary (i.e., the address might be accepted if the client tries again later). Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies.
失败是永久性的（即，如果客户端再次尝试发送相同的地址，则会再次发生）或临时性的（即，如果客户端稍后再次尝试，则可能会接受该地址）。尽管本要求的范围很明显，但在某些情况下，只有检查一条或多条正向路径（在RCPT命令中）才能确定反向路径的可接受性。在这些情况下，服务器可以合理地接受反向路径（回复250），然后在接收和检查正向路径后报告问题。通常，失败会产生550或553个回复。
Historically, the <reverse-path> can contain more than just a mailbox, however, contemporary systems SHOULD NOT use source routing (see appendix C).
从历史上看，<reverse path>可以包含不止一个邮箱，但是，当代系统不应该使用源路由（参见附录C）。
The optional <mail-parameters> are associated with negotiated SMTP service extensions (see section 2.2).
可选的<mail parameters>与协商的SMTP服务扩展相关联（参见第2.2节）。
The second step in the procedure is the RCPT command.
该过程的第二步是RCPT命令。
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
The first or only argument to this command includes a forward-path (normally a mailbox and domain, always surrounded by "<" and ">" brackets) identifying one recipient. If accepted, the SMTP server returns a 250 OK reply and stores the forward-path. If the recipient is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as "no such user - " and the mailbox name (other circumstances and reply codes are possible). This step of the procedure can be repeated any number of times.
此命令的第一个或唯一参数包括标识一个收件人的转发路径（通常是邮箱和域，始终用“<”和“>”括号括起来）。如果接受，SMTP服务器将返回250 OK回复并存储转发路径。如果已知收件人不是可交付地址，SMTP服务器将返回550个回复，通常带有“无此类用户”等字符串和邮箱名称（可能存在其他情况和回复代码）。此步骤可重复任意次数。
The <forward-path> can contain more than just a mailbox. Historically, the <forward-path> can be a source routing list of hosts and the destination mailbox, however, contemporary SMTP clients SHOULD NOT utilize source routes (see appendix C). Servers MUST be prepared to encounter a list of source routes in the forward path, but SHOULD ignore the routes or MAY decline to support the relaying they imply. Similarly, servers MAY decline to accept mail that is destined for other hosts or systems. These restrictions make a server useless as a relay for clients that do not support full SMTP functionality. Consequently, restricted-capability clients MUST NOT assume that any SMTP server on the Internet can be used as their mail processing (relaying) site. If a RCPT command appears without a previous MAIL command, the server MUST return a 503 "Bad sequence of commands" response. The optional <rcpt-parameters> are associated with negotiated SMTP service extensions (see section 2.2).
<forward path>可以包含多个邮箱。历史上，<forward path>可以是主机和目标邮箱的源路由列表，但是，当代SMTP客户端不应使用源路由（请参见附录C）。服务器必须准备好在转发路径中遇到源路由列表，但应忽略这些路由，或者可能拒绝支持它们所暗示的中继。类似地，服务器可能拒绝接受发送给其他主机或系统的邮件。这些限制使服务器无法作为不支持完整SMTP功能的客户端的中继。因此，受限功能客户端不得假定Internet上的任何SMTP服务器都可以用作其邮件处理（中继）站点。如果显示RCPT命令时没有先前的邮件命令，服务器必须返回503“错误命令序列”响应。可选的<rcpt参数>与协商的SMTP服务扩展相关联（请参阅第2.2节）。
The third step in the procedure is the DATA command (or some alternative specified in a service extension).
过程中的第三步是DATA命令（或服务扩展中指定的某些替代命令）。
DATA <CRLF>
数据<CRLF>
If accepted, the SMTP server returns a 354 Intermediate reply and considers all succeeding lines up to but not including the end of mail data indicator to be the message text. When the end of text is successfully received and stored the SMTP-receiver sends a 250 OK reply.
如果接受，SMTP服务器将返回354中间回复，并将所有后续行（包括但不包括邮件结束数据指示符）视为邮件文本。成功接收并存储文本结尾后，SMTP接收器将发送250 OK回复。
Since the mail data is sent on the transmission channel, the end of mail data must be indicated so that the command and reply dialog can be resumed. SMTP indicates the end of the mail data by sending a line containing only a "." (period or full stop). A transparency procedure is used to prevent this from interfering with the user's text (see section 4.5.2).
由于邮件数据是在传输通道上发送的，因此必须指示邮件数据的结束，以便可以恢复命令和回复对话框。SMTP通过发送仅包含“.”（句点或句号）的行来指示邮件数据的结束。透明度程序用于防止干扰用户文本（见第4.5.2节）。
The end of mail data indicator also confirms the mail transaction and tells the SMTP server to now process the stored recipients and mail data. If accepted, the SMTP server returns a 250 OK reply. The DATA command can fail at only two points in the protocol exchange:
邮件结束数据指示器还确认邮件事务，并通知SMTP服务器立即处理存储的收件人和邮件数据。如果接受，SMTP服务器将返回250 OK回复。数据命令只能在协议交换中的两点失败：
- If there was no MAIL, or no RCPT, command, or all such commands were rejected, the server MAY return a "command out of sequence" (503) or "no valid recipients" (554) reply in response to the DATA command. If one of those replies (or any other 5yz reply) is received, the client MUST NOT send the message data; more generally, message data MUST NOT be sent unless a 354 reply is received.
- 如果没有邮件，或者没有RCPT、命令，或者所有这些命令都被拒绝，服务器可以返回“顺序错误的命令”（503）或“没有有效的收件人”（554）回复数据命令。如果收到其中一个回复（或任何其他5yz回复），则客户端不得发送消息数据；更一般地说，除非收到354回复，否则不得发送消息数据。
- If the verb is initially accepted and the 354 reply issued, the DATA command should fail only if the mail transaction was incomplete (for example, no recipients), or if resources were unavailable (including, of course, the server unexpectedly becoming unavailable), or if the server determines that the message should be rejected for policy or other reasons.
- 如果最初接受动词并发出354回复，则仅当邮件事务不完整（例如，没有收件人）或资源不可用（当然包括服务器意外变为不可用）时，数据命令才会失败，或者如果服务器确定由于策略或其他原因应拒绝该消息。
However, in practice, some servers do not perform recipient verification until after the message text is received. These servers SHOULD treat a failure for one or more recipients as a "subsequent failure" and return a mail message as discussed in section 6. Using a "550 mailbox not found" (or equivalent) reply code after the data are accepted makes it difficult or impossible for the client to determine which recipients failed.
但是，在实践中，一些服务器在收到消息文本之前不会执行收件人验证。这些服务器应将一个或多个收件人的故障视为“后续故障”，并返回邮件消息，如第6节所述。在接受数据后使用“550邮箱未找到”（或等效）回复代码会使客户端难以或无法确定哪些收件人失败。
When RFC 822 format [7, 32] is being used, the mail data include the memo header items such as Date, Subject, To, Cc, From. Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME [12] message header or message body. In particular,
当使用RFC 822格式[7，32]时，邮件数据包括备忘录标题项，如日期、主题、收件人、抄送、发件人。服务器SMTP系统不应基于RFC 822或MIME[12]邮件头或邮件正文中的感知缺陷拒绝邮件。特别地，
they MUST NOT reject messages in which the numbers of Resent-fields do not match or Resent-to appears without Resent-from and/or Resent-date.
如果在没有“重新发送自”和/或“重新发送日期”的情况下，重新发送字段数不匹配或“重新发送至”出现，则他们不得拒绝这些消息。
Mail transaction commands MUST be used in the order discussed above.
邮件事务命令必须按上述顺序使用。
Forwarding support is most often required to consolidate and simplify addresses within, or relative to, some enterprise and less frequently to establish addresses to link a person's prior address with current one. Silent forwarding of messages (without server notification to the sender), for security or non-disclosure purposes, is common in the contemporary Internet.
转发支持通常用于合并和简化某些企业内或相对于某些企业的地址，而用于建立地址以将个人以前的地址与当前地址链接的频率较低。出于安全或保密目的，消息的静默转发（不向发送者发送服务器通知）在当代互联网中很常见。
In both the enterprise and the "new address" cases, information hiding (and sometimes security) considerations argue against exposure of the "final" address through the SMTP protocol as a side-effect of the forwarding activity. This may be especially important when the final address may not even be reachable by the sender. Consequently, the "forwarding" mechanisms described in section 3.2 of RFC 821, and especially the 251 (corrected destination) and 551 reply codes from RCPT must be evaluated carefully by implementers and, when they are available, by those configuring systems.
在企业和“新地址”两种情况下，信息隐藏（有时是安全性）考虑反对通过SMTP协议暴露“最终”地址作为转发活动的副作用。当发件人甚至无法访问最终地址时，这一点可能尤为重要。因此，RFC 821第3.2节中描述的“转发”机制，尤其是来自RCPT的251（纠正的目的地）和551应答码，必须由实施者仔细评估，并且在可用时，由配置系统仔细评估。
In particular:
特别地：
* Servers MAY forward messages when they are aware of an address change. When they do so, they MAY either provide address-updating information with a 251 code, or may forward "silently" and return a 250 code. But, if a 251 code is used, they MUST NOT assume that the client will actually update address information or even return that information to the user.
* 服务器在知道地址更改时可以转发消息。当它们这样做时，它们可以提供带有251代码的地址更新信息，或者可以“静默”转发并返回250代码。但是，如果使用251代码，他们不能假设客户机将实际更新地址信息，甚至不能将该信息返回给用户。
Alternately,
或者，
* Servers MAY reject or bounce messages when they are not deliverable when addressed. When they do so, they MAY either provide address-updating information with a 551 code, or may reject the message as undeliverable with a 550 code and no address-specific information. But, if a 551 code is used, they MUST NOT assume that the client will actually update address information or even return that information to the user.
* 当邮件在寻址时无法交付时，服务器可能会拒绝或跳出邮件。当他们这样做时，他们可能会提供带有551代码的地址更新信息，或者可能会拒绝带有550代码且没有地址特定信息的无法送达的消息。但是，如果使用551代码，他们不能假设客户机将实际更新地址信息，甚至不能将该信息返回给用户。
SMTP server implementations that support the 251 and/or 551 reply codes are strongly encouraged to provide configuration mechanisms so that sites which conclude that they would undesirably disclose information can disable or restrict their use.
强烈建议支持251和/或551回复代码的SMTP服务器实现提供配置机制，以便得出结论认为会不必要地泄露信息的站点可以禁用或限制其使用。
SMTP provides commands to verify a user name or obtain the content of a mailing list. This is done with the VRFY and EXPN commands, which have character string arguments. Implementations SHOULD support VRFY and EXPN (however, see section 3.5.2 and 7.3).
SMTP提供用于验证用户名或获取邮件列表内容的命令。这是通过具有字符串参数的VRFY和EXPN命令完成的。实施应支持VRFY和EXPN（但请参见第3.5.2和7.3节）。
For the VRFY command, the string is a user name or a user name and domain (see below). If a normal (i.e., 250) response is returned, the response MAY include the full name of the user and MUST include the mailbox of the user. It MUST be in either of the following forms:
对于VRFY命令，字符串是用户名或用户名和域（见下文）。如果返回正常（即250）响应，则响应可能包括用户的全名，并且必须包括用户的邮箱。必须采用以下任一形式：
User Name <local-part@domain>
local-part@domain
User Name <local-part@domain>
local-part@domain
When a name that is the argument to VRFY could identify more than one mailbox, the server MAY either note the ambiguity or identify the alternatives. In other words, any of the following are legitimate response to VRFY:
当作为VRFY参数的名称可以标识多个邮箱时，服务器可能会注意到歧义或标识替代项。换句话说，以下任何一项都是对VRFY的合法回应：
553 User ambiguous
553用户不明确
or
或
553- Ambiguous; Possibilities are
553-Joe Smith <jsmith@foo.com>
553-Harry Smith <hsmith@foo.com>
553 Melvin Smith <dweep@foo.com>
553- Ambiguous; Possibilities are
553-Joe Smith <jsmith@foo.com>
553-Harry Smith <hsmith@foo.com>
553 Melvin Smith <dweep@foo.com>
or
或
553-Ambiguous; Possibilities
553- <jsmith@foo.com>
553- <hsmith@foo.com>
553 <dweep@foo.com>
553-Ambiguous; Possibilities
553- <jsmith@foo.com>
553- <hsmith@foo.com>
553 <dweep@foo.com>
Under normal circumstances, a client receiving a 553 reply would be expected to expose the result to the user. Use of exactly the forms given, and the "user ambiguous" or "ambiguous" keywords, possibly supplemented by extended reply codes such as those described in [34], will facilitate automated translation into other languages as needed. Of course, a client that was highly automated or that was operating in another language than English, might choose to try to translate the response, to return some other indication to the user than the
在正常情况下，接收553回复的客户端将向用户公开结果。准确地使用给定的表格，以及“用户不明确”或“不明确”关键字（可能由[34]中所述的扩展回复代码补充），将有助于根据需要自动翻译成其他语言。当然，高度自动化的客户机或使用英语以外的其他语言操作的客户机可能会选择尝试翻译响应，向用户返回除
literal text of the reply, or to take some automated action such as consulting a directory service for additional information before reporting to the user.
回复的文本，或者在向用户报告之前，采取一些自动操作，例如咨询目录服务以获取更多信息。
For the EXPN command, the string identifies a mailing list, and the successful (i.e., 250) multiline response MAY include the full name of the users and MUST give the mailboxes on the mailing list.
对于EXPN命令，字符串标识邮件列表，成功的（即250）多行响应可能包括用户的全名，并且必须给出邮件列表上的邮箱。
In some hosts the distinction between a mailing list and an alias for a single mailbox is a bit fuzzy, since a common data structure may hold both types of entries, and it is possible to have mailing lists containing only one mailbox. If a request is made to apply VRFY to a mailing list, a positive response MAY be given if a message so addressed would be delivered to everyone on the list, otherwise an error SHOULD be reported (e.g., "550 That is a mailing list, not a user" or "252 Unable to verify members of mailing list"). If a request is made to expand a user name, the server MAY return a positive response consisting of a list containing one name, or an error MAY be reported (e.g., "550 That is a user name, not a mailing list").
在某些主机中，单个邮箱的邮件列表和别名之间的区别有点模糊，因为公共数据结构可能包含这两种类型的条目，并且邮件列表可能只包含一个邮箱。如果请求将VRFY应用于邮件列表，则如果如此寻址的邮件将发送给列表上的每个人，则可能会给出肯定的响应，否则应报告错误（例如，“550是邮件列表，而不是用户”或“252无法验证邮件列表的成员”）。如果请求扩展用户名，服务器可能会返回由包含一个名称的列表组成的肯定响应，或者可能会报告错误（例如，“550是用户名，不是邮件列表”）。
In the case of a successful multiline reply (normal for EXPN) exactly one mailbox is to be specified on each line of the reply. The case of an ambiguous request is discussed above.
如果多行回复成功（EXPN为正常），则在回复的每一行上只指定一个邮箱。上面讨论了请求不明确的情况。
"User name" is a fuzzy term and has been used deliberately. An implementation of the VRFY or EXPN commands MUST include at least recognition of local mailboxes as "user names". However, since current Internet practice often results in a single host handling mail for multiple domains, hosts, especially hosts that provide this functionality, SHOULD accept the "local-part@domain" form as a "user name"; hosts MAY also choose to recognize other strings as "user names".
“用户名”是一个模糊的术语，被有意使用。VRFY或EXPN命令的实现必须至少包括将本地邮箱识别为“用户名”。但是，由于当前的Internet实践通常导致单个主机处理多个域的邮件，因此主机，尤其是提供此功能的主机，应该接受“本地-part@domain“表单”作为“用户名”；主机还可以选择将其他字符串识别为“用户名”。
The case of expanding a mailbox list requires a multiline reply, such as:
扩展邮箱列表需要多行回复，例如：
C: EXPN Example-People
S: 250-Jon Postel <Postel@isi.edu>
S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
C: EXPN Example-People
S: 250-Jon Postel <Postel@isi.edu>
S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
or
或
C: EXPN Executive-Washroom-List
S: 550 Access Denied to You.
C: EXPN Executive-Washroom-List
S: 550 Access Denied to You.
The character string arguments of the VRFY and EXPN commands cannot be further restricted due to the variety of implementations of the user name and mailbox list concepts. On some systems it may be appropriate for the argument of the EXPN command to be a file name for a file containing a mailing list, but again there are a variety of file naming conventions in the Internet. Similarly, historical variations in what is returned by these commands are such that the response SHOULD be interpreted very carefully, if at all, and SHOULD generally only be used for diagnostic purposes.
由于用户名和邮箱列表概念的各种实现，VRFY和EXPN命令的字符串参数不能进一步限制。在某些系统上，EXPN命令的参数可能适合作为包含邮件列表的文件的文件名，但在Internet上也有各种文件命名约定。类似地，这些命令返回的内容的历史变化是这样的，因此响应应该非常仔细地解释（如果有的话），并且通常仅用于诊断目的。
When normal (2yz or 551) responses are returned from a VRFY or EXPN request, the reply normally includes the mailbox name, i.e., "<local-part@domain>", where "domain" is a fully qualified domain name, MUST appear in the syntax. In circumstances exceptional enough to justify violating the intent of this specification, free-form text MAY be returned. In order to facilitate parsing by both computers and people, addresses SHOULD appear in pointed brackets. When addresses, rather than free-form debugging information, are returned, EXPN and VRFY MUST return only valid domain addresses that are usable in SMTP RCPT commands. Consequently, if an address implies delivery to a program or other system, the mailbox name used to reach that target MUST be given. Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN.
当从VRFY或EXPN请求返回正常（2yz或551）响应时，响应通常包括邮箱名称，即“<local”-part@domain>，其中“domain”是完全限定的域名，必须出现在语法中。在足以证明违反本规范意图的特殊情况下，可返回自由格式文本。为了便于计算机和人员进行解析，地址应显示在尖括号中。当返回地址而不是自由形式的调试信息时，EXPN和VRFY必须只返回SMTP RCPT命令中可用的有效域地址。因此，如果地址意味着传递到程序或其他系统，则必须给出用于到达该目标的邮箱名称。VRFY或EXPN不能返回路径（显式源路由）。
Server implementations SHOULD support both VRFY and EXPN. For security reasons, implementations MAY provide local installations a way to disable either or both of these commands through configuration options or the equivalent. When these commands are supported, they are not required to work across relays when relaying is supported. Since they were both optional in RFC 821, they MUST be listed as service extensions in an EHLO response, if they are supported.
服务器实现应同时支持VRFY和EXPN。出于安全原因，实现可能会为本地安装提供一种通过配置选项或等效选项禁用其中一个或两个命令的方法。当支持这些命令时，当支持中继时，它们不需要跨继电器工作。因为它们在RFC 821中都是可选的，所以如果支持，它们必须在EHLO响应中作为服务扩展列出。
A server MUST NOT return a 250 code in response to a VRFY or EXPN command unless it has actually verified the address. In particular, a server MUST NOT return 250 if all it has done is to verify that the syntax given is valid. In that case, 502 (Command not implemented) or 500 (Syntax error, command unrecognized) SHOULD be returned. As stated elsewhere, implementation (in the sense of actually validating addresses and returning information) of VRFY and EXPN are strongly recommended. Hence, implementations that return 500 or 502 for VRFY are not in full compliance with this specification.
服务器不得返回250代码以响应VRFY或EXPN命令，除非它实际验证了地址。特别是，如果服务器所做的只是验证给定的语法是否有效，那么它就不能返回250。在这种情况下，应返回502（未实现命令）或500（语法错误，无法识别命令）。如其他地方所述，强烈建议实施VRFY和EXPN（在实际验证地址和返回信息的意义上）。因此，为VRFY返回500或502的实现不完全符合本规范。
There may be circumstances where an address appears to be valid but cannot reasonably be verified in real time, particularly when a server is acting as a mail exchanger for another server or domain. "Apparent validity" in this case would normally involve at least syntax checking and might involve verification that any domains specified were ones to which the host expected to be able to relay mail. In these situations, reply code 252 SHOULD be returned. These cases parallel the discussion of RCPT verification discussed in section 2.1. Similarly, the discussion in section 3.4 applies to the use of reply codes 251 and 551 with VRFY (and EXPN) to indicate addresses that are recognized but that would be forwarded or bounced were mail received for them. Implementations generally SHOULD be more aggressive about address verification in the case of VRFY than in the case of RCPT, even if it takes a little longer to do so.
在某些情况下，地址看似有效，但无法合理地实时验证，特别是当服务器充当另一服务器或域的邮件交换器时。这种情况下的“明显有效性”通常至少涉及语法检查，可能涉及验证指定的任何域是否是主机希望能够向其转发邮件的域。在这些情况下，应返回回复代码252。这些案例与第2.1节中讨论的RCPT验证平行。同样，第3.4节中的讨论也适用于使用带有VRFY（和EXPN）的回复代码251和551来表示已识别但在收到邮件时将被转发或退回的地址。在VRFY的情况下，实现通常应该比在RCPT的情况下更积极地进行地址验证，即使这样做需要更长的时间。
EXPN is often very useful in debugging and understanding problems with mailing lists and multiple-target-address aliases. Some systems have attempted to use source expansion of mailing lists as a means of eliminating duplicates. The propagation of aliasing systems with mail on the Internet, for hosts (typically with MX and CNAME DNS records), for mailboxes (various types of local host aliases), and in various proxying arrangements, has made it nearly impossible for these strategies to work consistently, and mail systems SHOULD NOT attempt them.
EXPN在调试和理解邮件列表和多个目标地址别名的问题时通常非常有用。一些系统试图使用邮件列表的源扩展来消除重复项。互联网上邮件、主机（通常带有MX和CNAME DNS记录）、邮箱（各种类型的本地主机别名）以及各种代理安排中的别名系统的传播，使得这些策略几乎不可能始终如一地工作，邮件系统不应尝试这些策略。
Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs:
在SMTP中使用域名时，仅允许解析、完全限定的域名（FQDN）。换句话说，可以解析为MX RRs或RRs（如第5节所述）的名称是允许的，其目标可以依次解析为MX或RRs的CNAME RRs也是允许的。不得使用本地昵称或非限定名称。需要FQDN的规则有两个例外：
- The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
- EHLO命令中给出的域名必须是主主机名（解析为a RR的域名），如果主机没有名称，则必须是第4.1.1.1节中描述的地址文字。
- The reserved mailbox name "postmaster" may be used in a RCPT command without domain qualification (see section 4.1.1.3) and MUST be accepted if so used.
- 保留邮箱名称“postmaster”可在RCPT命令中使用，无需域限定（见第4.1.1.3节），如果使用，则必须接受。
In general, the availability of Mail eXchanger records in the domain name system [22, 27] makes the use of explicit source routes in the Internet mail system unnecessary. Many historical problems with their interpretation have made their use undesirable. SMTP clients SHOULD NOT generate explicit source routes except under unusual circumstances. SMTP servers MAY decline to act as mail relays or to accept addresses that specify source routes. When route information is encountered, SMTP servers are also permitted to ignore the route information and simply send to the final destination specified as the last element in the route and SHOULD do so. There has been an invalid practice of using names that do not appear in the DNS as destination names, with the senders counting on the intermediate hosts specified in source routing to resolve any problems. If source routes are stripped, this practice will cause failures. This is one of several reasons why SMTP clients MUST NOT generate invalid source routes or depend on serial resolution of names.
一般来说，域名系统[22,27]中邮件交换记录的可用性使得在Internet邮件系统中不需要使用显式源路由。对它们的解释有许多历史问题，因此使用它们是不可取的。SMTP客户端不应生成显式源路由，除非在异常情况下。SMTP服务器可能拒绝充当邮件中继或接受指定源路由的地址。当遇到路由信息时，也允许SMTP服务器忽略路由信息，只发送到指定为路由中最后一个元素的最终目的地，并且应该这样做。使用DNS中未出现的名称作为目标名称的做法是无效的，发送方依靠源路由中指定的中间主机来解决任何问题。如果源路由被剥离，这种做法将导致失败。这是SMTP客户端不能生成无效源路由或依赖名称的串行解析的几个原因之一。
When source routes are not used, the process described in RFC 821 for constructing a reverse-path from the forward-path is not applicable and the reverse-path at the time of delivery will simply be the address that appeared in the MAIL command.
当不使用源路由时，RFC 821中描述的用于从正向路径构造反向路径的过程不适用，并且递送时的反向路径将只是出现在MAIL命令中的地址。
A relay SMTP server is usually the target of a DNS MX record that designates it, rather than the final delivery system. The relay server may accept or reject the task of relaying the mail in the same way it accepts or rejects mail for a local user. If it accepts the task, it then becomes an SMTP client, establishes a transmission channel to the next SMTP server specified in the DNS (according to the rules in section 5), and sends it the mail. If it declines to relay mail to a particular address for policy reasons, a 550 response SHOULD be returned.
中继SMTP服务器通常是指定它的DNS MX记录的目标，而不是最终传递系统。中继服务器可以接受或拒绝转发邮件的任务，其方式与为本地用户接受或拒绝邮件的方式相同。如果它接受任务，则它将成为SMTP客户端，建立到DNS中指定的下一个SMTP服务器的传输通道（根据第5节中的规则），并向其发送邮件。如果出于政策原因拒绝将邮件转发到特定地址，则应返回550回复。
Many mail-sending clients exist, especially in conjunction with facilities that receive mail via POP3 or IMAP, that have limited capability to support some of the requirements of this specification, such as the ability to queue messages for subsequent delivery attempts. For these clients, it is common practice to make private arrangements to send all messages to a single server for processing and subsequent distribution. SMTP, as specified here, is not ideally suited for this role, and work is underway on standardized mail submission protocols that might eventually supercede the current practices. In any event, because these arrangements are private and fall outside the scope of this specification, they are not described here.
存在许多邮件发送客户端，特别是与通过POP3或IMAP接收邮件的设施结合使用时，这些客户端的能力有限，无法支持本规范的某些要求，例如将邮件排队等待后续的传递尝试。对于这些客户机，通常的做法是进行私人安排，将所有消息发送到单个服务器进行处理和后续分发。此处指定的SMTP并不适合此角色，目前正在开发标准化的邮件提交协议，该协议可能最终取代当前的做法。在任何情况下，由于这些安排是私有的，不在本规范的范围内，因此此处不进行描述。
It is important to note that MX records can point to SMTP servers which act as gateways into other environments, not just SMTP relays and final delivery systems; see sections 3.8 and 5.
需要注意的是，MX记录可以指向SMTP服务器，这些服务器充当到其他环境的网关，而不仅仅是SMTP中继和最终交付系统；见第3.8节和第5节。
If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path). Formats specified for non-delivery reports by other standards (see, for example, [24, 25]) SHOULD be used if possible.
如果SMTP服务器已接受转发邮件的任务，但后来发现目标不正确或邮件因其他原因无法送达，则必须构造“无法送达邮件”通知消息，并将其发送给无法送达邮件的发起人（如反向路径所示）。如果可能，应使用其他标准（例如，参见[24,25]）为未交付报告指定的格式。
This notification message must be from the SMTP server at the relay host or the host that first determines that delivery cannot be accomplished. Of course, SMTP servers MUST NOT send notification messages about problems transporting notification messages. One way to prevent loops in error reporting is to specify a null reverse-path in the MAIL command of a notification message. When such a message is transmitted the reverse-path MUST be set to null (see section 4.5.5 for additional discussion). A MAIL command with a null reverse-path appears as follows:
此通知消息必须来自中继主机上的SMTP服务器或首先确定无法完成传递的主机。当然，SMTP服务器不得发送有关传输通知消息时出现问题的通知消息。防止错误报告中出现循环的一种方法是在通知消息的MAIL命令中指定空反向路径。当传输此类消息时，反向路径必须设置为null（更多讨论见第4.5.5节）。具有空反向路径的邮件命令如下所示：
MAIL FROM:<>
MAIL FROM:<>
As discussed in section 2.4.1, a relay SMTP has no need to inspect or act upon the headers or body of the message data and MUST NOT do so except to add its own "Received:" header (section 4.4) and, optionally, to attempt to detect looping in the mail system (see section 6.2).
如第2.4.1节所述，中继SMTP无需检查或处理邮件数据的标题或正文，除非添加自己的“已接收：”标题（第4.4节），或者尝试检测邮件系统中的循环（见第6.2节），否则不得进行检查或处理。
While the relay function discussed above operates within the Internet SMTP transport service environment, MX records or various forms of explicit routing may require that an intermediate SMTP server perform a translation function between one transport service and another. As discussed in section 2.3.8, when such a system is at the boundary between two transport service environments, we refer to it as a "gateway" or "gateway SMTP".
虽然上面讨论的中继功能在Internet SMTP传输服务环境中运行，但MX记录或各种形式的显式路由可能需要中间SMTP服务器在一个传输服务和另一个传输服务之间执行转换功能。如第2.3.8节所述，当此类系统位于两个传输服务环境之间的边界时，我们将其称为“网关”或“网关SMTP”。
Gatewaying mail between different mail environments, such as different mail formats and protocols, is complex and does not easily yield to standardization. However, some general requirements may be given for a gateway between the Internet and another mail environment.
不同邮件环境（如不同的邮件格式和协议）之间的邮件网关化非常复杂，不容易实现标准化。但是，对于Internet和其他邮件环境之间的网关，可能会给出一些一般要求。
Header fields MAY be rewritten when necessary as messages are gatewayed across mail environment boundaries. This may involve inspecting the message body or interpreting the local-part of the destination address in spite of the prohibitions in section 2.4.1.
必要时可以重写标题字段，因为邮件通过网关跨越邮件环境边界。尽管有第2.4.1节的禁止，这可能涉及检查消息正文或解释目的地址的本地部分。
Other mail systems gatewayed to the Internet often use a subset of RFC 822 headers or provide similar functionality with a different syntax, but some of these mail systems do not have an equivalent to the SMTP envelope. Therefore, when a message leaves the Internet environment, it may be necessary to fold the SMTP envelope information into the message header. A possible solution would be to create new header fields to carry the envelope information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would require changes in mail programs in foreign environments and might risk disclosure of private information (see section 7.2).
通过网关连接到Internet的其他邮件系统通常使用RFC 822邮件头的子集，或提供具有不同语法的类似功能，但其中一些邮件系统没有与SMTP信封等效的功能。因此，当邮件离开Internet环境时，可能需要将SMTP信封信息折叠到邮件头中。一个可能的解决方案是创建新的头字段来携带信封信息（例如，“X-SMTP-MAIL:”和“X-SMTP-RCPT:”）；但是，这需要在国外环境中更改邮件程序，并且可能会有泄露私人信息的风险（参见第7.2节）。
When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header.
在将消息转发到Internet环境中或从Internet环境中转发出去时，网关必须预先发送Received:行，但不得以任何方式更改标头中已存在的Received:行。
"Received:" fields of messages originating from other environments may not conform exactly to this specification. However, the most important use of Received: lines is for debugging mail faults, and this debugging can be severely hampered by well-meaning gateways that try to "fix" a Received: line. As another consequence of trace fields arising in non-SMTP environments, receiving systems MUST NOT reject mail based on the format of a trace field and SHOULD be extremely robust in the light of unexpected information or formats in those fields.
“Received:”来自其他环境的消息字段可能不完全符合本规范。然而，Received:行最重要的用途是用于调试邮件故障，而这种调试可能会受到试图“修复”Received:行的善意网关的严重阻碍。非SMTP环境中出现的跟踪字段的另一个后果是，接收系统不得基于跟踪字段的格式拒绝邮件，并且在这些字段中出现意外信息或格式时，接收系统应非常健壮。
The gateway SHOULD indicate the environment and protocol in the "via" clauses of Received field(s) that it supplies.
网关应在其提供的接收字段的“via”条款中指明环境和协议。
From the Internet side, the gateway SHOULD accept all valid address formats in SMTP commands and in RFC 822 headers, and all valid RFC 822 messages. Addresses and headers generated by gateways MUST conform to applicable Internet standards (including this one and RFC 822). Gateways are, of course, subject to the same rules for handling source routes as those described for other SMTP systems in section 3.3.
从Internet端，网关应接受SMTP命令和RFC 822标头中的所有有效地址格式，以及所有有效的RFC 822消息。网关生成的地址和报头必须符合适用的互联网标准（包括本标准和RFC 822）。当然，网关处理源路由的规则与第3.3节中为其他SMTP系统描述的规则相同。
The gateway MUST ensure that all header fields of a message that it forwards into the Internet mail environment meet the requirements for Internet mail. In particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC 822 syntax, MUST reference only fully-qualified domain names, and MUST be effective and useful for sending replies. The translation algorithm used to convert mail from the Internet protocols to another environment's protocol SHOULD ensure that error messages from the foreign mail environment are delivered to the return path from the SMTP envelope, not to the sender listed in the "From:" field (or other fields) of the RFC 822 message.
网关必须确保转发到Internet邮件环境的邮件的所有头字段都满足Internet邮件的要求。特别是，“From:”、“To:”、“Cc:”等字段中的所有地址必须进行转换（如有必要）以满足RFC 822语法，必须仅引用完全限定的域名，并且必须对发送回复有效且有用。用于将邮件从Internet协议转换为其他环境的协议的转换算法应确保来自外部邮件环境的错误消息从SMTP信封传递到返回路径，而不是传递到RFC 822消息的“发件人：”字段（或其他字段）中列出的发件人。
Similarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path in accordance with an error message return address, if supplied by the foreign environment. If the foreign environment has no equivalent concept, the gateway must select and use a best approximation, with the message originator's address as the default of last resort.
类似地，当将消息从另一个环境转发到Internet时，网关应根据错误消息返回地址（如果由外部环境提供）设置信封返回路径。如果外部环境没有等效概念，网关必须选择并使用最佳近似值，并将消息发起人的地址作为默认的最后手段。
An SMTP connection is terminated when the client sends a QUIT command. The server responds with a positive reply code, after which it closes the connection.
当客户端发送QUIT命令时，SMTP连接终止。服务器以肯定应答代码进行响应，然后关闭连接。
An SMTP server MUST NOT intentionally close the connection except:
SMTP服务器不得故意关闭连接，除非：
- After receiving a QUIT command and responding with a 221 reply.
- 在收到QUIT命令并以221回复进行响应之后。
- After detecting the need to shut down the SMTP service and returning a 421 response code. This response code can be issued after the server receives any command or, if necessary, asynchronously from command receipt (on the assumption that the client will receive it after the next command is issued).
- 检测到需要关闭SMTP服务并返回421响应代码后。此响应代码可以在服务器接收到任何命令后发出，或者在必要时从命令接收异步发出（假设客户机将在下一个命令发出后接收）。
In particular, a server that closes connections in response to commands that are not understood is in violation of this specification. Servers are expected to be tolerant of unknown commands, issuing a 500 reply and awaiting further instructions from the client.
特别是，响应不理解的命令而关闭连接的服务器违反了本规范。服务器应能容忍未知命令，发出500个回复，并等待客户端的进一步指示。
An SMTP server which is forcibly shut down via external means SHOULD attempt to send a line containing a 421 response code to the SMTP client before exiting. The SMTP client will normally read the 421 response code after sending its next command.
通过外部方式强制关闭的SMTP服务器应在退出之前尝试向SMTP客户端发送包含421响应代码的行。SMTP客户端通常会在发送下一个命令后读取421响应代码。
SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly.
SMTP客户端由于不在其控制范围内的情况（违反本规范的意图，但有时不可避免）而遇到连接关闭、重置或其他通信故障，为保持邮件系统的健壮性，将邮件事务视为已收到451响应，并采取相应措施。
An SMTP-capable host SHOULD support both the alias and the list models of address expansion for multiple delivery. When a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to be the address of a person or other entity who administers the list. However, in this case, the message header [32] MUST be left unchanged; in particular, the "From" field of the message header is unaffected.
支持SMTP的主机应同时支持别名和地址扩展列表模式，以便进行多次传递。当邮件发送或转发到扩展列表表单的每个地址时，信封中的返回地址（“邮件发件人：”）必须更改为管理列表的个人或其他实体的地址。然而，在这种情况下，消息头[32]必须保持不变；特别是，消息头的“From”字段不受影响。
An important mail facility is a mechanism for multi-destination delivery of a single message, by transforming (or "expanding" or "exploding") a pseudo-mailbox address into a list of destination mailbox addresses. When a message is sent to such a pseudo-mailbox (sometimes called an "exploder"), copies are forwarded or redistributed to each mailbox in the expanded list. Servers SHOULD simply utilize the addresses on the list; application of heuristics or other matching rules to eliminate some addresses, such as that of the originator, is strongly discouraged. We classify such a pseudo-mailbox as an "alias" or a "list", depending upon the expansion rules.
一种重要的邮件功能是通过将伪邮箱地址转换（或“扩展”或“分解”）为目标邮箱地址列表来实现单个邮件的多目标传递的机制。将邮件发送到此类伪邮箱（有时称为“爆炸器”）时，副本将转发或重新分发到扩展列表中的每个邮箱。服务器应该只使用列表上的地址；强烈反对使用启发式或其他匹配规则来消除某些地址，如发起者的地址。我们根据扩展规则将此类伪邮箱分类为“别名”或“列表”。
To expand an alias, the recipient mailer simply replaces the pseudo-mailbox address in the envelope with each of the expanded addresses in turn; the rest of the envelope and the message body are left unchanged. The message is then delivered or forwarded to each expanded address.
要扩展别名，收件人邮件程序只需依次用每个扩展地址替换信封中的伪邮箱地址；信封的其余部分和消息正文保持不变。然后将消息传递或转发到每个扩展地址。
A mailing list may be said to operate by "redistribution" rather than by "forwarding". To expand a list, the recipient mailer replaces the pseudo-mailbox address in the envelope with all of the expanded
邮件列表可以说是通过“再分配”而不是“转发”来运行的。要展开列表，收件人邮件程序将信封中的伪邮箱地址替换为所有展开的
addresses. The return address in the envelope is changed so that all error messages generated by the final deliveries will be returned to a list administrator, not to the message originator, who generally has no control over the contents of the list and will typically find error messages annoying.
地址。信封中的返回地址已更改，因此最终交付生成的所有错误消息将返回给列表管理员，而不是消息发起人，后者通常无法控制列表的内容，并且通常会发现错误消息令人讨厌。
The SMTP commands define the mail transfer or the mail system function requested by the user. SMTP commands are character strings terminated by <CRLF>. The commands themselves are alphabetic characters terminated by <SP> if parameters follow and <CRLF> otherwise. (In the interest of improved interoperability, SMTP receivers are encouraged to tolerate trailing white space before the terminating <CRLF>.) The syntax of the local part of a mailbox must conform to receiver site conventions and the syntax specified in section 4.1.2. The SMTP commands are discussed below. The SMTP replies are discussed in section 4.2.
SMTP命令定义用户请求的邮件传输或邮件系统功能。SMTP命令是以<CRLF>结尾的字符串。命令本身是字母字符，如果参数在后面，则以<SP>结尾，否则以<CRLF>结尾。（为了提高互操作性，鼓励SMTP接收方在终止<CRLF>之前容忍尾随空格）邮箱本地部分的语法必须符合接收方站点约定和第4.1.2节中指定的语法。下面讨论SMTP命令。SMTP回复将在第4.2节中讨论。
A mail transaction involves several data objects which are communicated as arguments to different commands. The reverse-path is the argument of the MAIL command, the forward-path is the argument of the RCPT command, and the mail data is the argument of the DATA command. These arguments or data objects must be transmitted and held pending the confirmation communicated by the end of mail data indication which finalizes the transaction. The model for this is that distinct buffers are provided to hold the types of data objects, that is, there is a reverse-path buffer, a forward-path buffer, and a mail data buffer. Specific commands cause information to be appended to a specific buffer, or cause one or more buffers to be cleared.
邮件事务涉及多个数据对象，这些数据对象作为参数传递给不同的命令。反向路径是MAIL命令的参数，正向路径是RCPT命令的参数，邮件数据是data命令的参数。这些参数或数据对象必须传输并保留，以等待邮件结束数据指示所传达的确认，从而完成交易。其模型是提供不同的缓冲区来保存数据对象的类型，即有反向路径缓冲区、正向路径缓冲区和邮件数据缓冲区。特定命令导致将信息附加到特定缓冲区，或导致清除一个或多个缓冲区。
Several commands (RSET, DATA, QUIT) are specified as not permitting parameters. In the absence of specific extensions offered by the server and accepted by the client, clients MUST NOT send such parameters and servers SHOULD reject commands containing them as having invalid syntax.
有几个命令（RSET、DATA、QUIT）被指定为不允许使用参数。如果没有服务器提供并被客户端接受的特定扩展，客户端不得发送此类参数，服务器应拒绝包含这些参数的命令，因为它们具有无效语法。
These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is
这些命令用于向SMTP服务器标识SMTP客户端。参数字段包含SMTP客户端的完全限定域名（如果有）。在SMTP客户端系统没有有意义的域名的情况下（例如，当其地址被动态分配且没有反向映射记录时）
available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. y The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command.
可用），客户机应发送一个地址文本（见第4.1.3节），可选地后跟有助于识别客户机系统的信息。y SMTP服务器在连接问候语回复和对此命令的响应中向SMTP客户端标识自己。
A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If the SMTP server supports the SMTP service extensions it will give a successful response, a failure response, or an error response. If the SMTP server, in violation of this specification, does not support any SMTP service extensions it will generate an error response. Older client SMTP systems MAY, as discussed above, use HELO (as specified in RFC 821) instead of EHLO, and servers MUST support the HELO command and reply properly to it. In any event, a client MUST issue HELO or EHLO before starting a mail transaction.
客户端SMTP应通过发出EHLO命令启动SMTP会话。如果SMTP服务器支持SMTP服务扩展，它将给出成功响应、失败响应或错误响应。如果SMTP服务器违反此规范，不支持任何SMTP服务扩展，它将生成错误响应。如上所述，较旧的客户端SMTP系统可能使用HELO（如RFC 821中所述）而不是EHLO，服务器必须支持HELO命令并正确响应它。在任何情况下，客户机都必须在启动邮件事务之前发出HELO或EHLO。
These commands, and a "250 OK" reply to one of them, confirm that both the SMTP client and the SMTP server are in the initial state, that is, there is no transaction in progress and all state tables and buffers are cleared.
这些命令以及对其中一个命令的“250 OK”回复确认SMTP客户端和SMTP服务器都处于初始状态，即没有正在进行的事务，并且所有状态表和缓冲区都已清除。
Syntax:
语法：
ehlo = "EHLO" SP Domain CRLF helo = "HELO" SP Domain CRLF
ehlo=“ehlo”SP域CRLF helo=“helo”SP域CRLF
Normally, the response to EHLO will be a multiline reply. Each line of the response contains a keyword and, optionally, one or more parameters. Following the normal syntax for multiline replies, these keyworks follow the code (250) and a hyphen for all but the last line, and the code and a space for the last line. The syntax for a positive response, using the ABNF notation and terminal symbols of [8], is:
通常，对EHLO的响应将是多行回复。响应的每一行都包含一个关键字和一个或多个参数（可选）。按照多行回复的正常语法，这些关键字遵循代码（250）和连字符（最后一行除外），以及代码和空格（最后一行）。使用[8]中的ABNF符号和终端符号，肯定响应的语法为：
ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
/ ( "250-" domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
/ ( "250-" domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF
ehlo-line = ehlo-keyword *( SP ehlo-param )
ehlo行=ehlo关键字*（SP ehlo参数）
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; additional syntax of ehlo-params depends on
; ehlo-keyword
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; additional syntax of ehlo-params depends on
; ehlo-keyword
ehlo-param = 1*(%d33-127)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 inclusive)
ehlo-param = 1*(%d33-127)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 inclusive)
Although EHLO keywords may be specified in upper, lower, or mixed case, they MUST always be recognized and processed in a case-insensitive manner. This is simply an extension of practices specified in RFC 821 and section 2.4.1.
尽管可以用大写、小写或混合大写指定EHLO关键字，但必须始终以不区分大小写的方式识别和处理它们。这只是RFC 821和第2.4.1节中规定的实践的扩展。
This command is used to initiate a mail transaction in which the mail data is delivered to an SMTP server which may, in turn, deliver it to one or more mailboxes or pass it on to another system (possibly using SMTP). The argument field contains a reverse-path and may contain optional parameters. In general, the MAIL command may be sent only when no mail transaction is in progress, see section 4.1.4.
此命令用于启动邮件事务，在该事务中，邮件数据被传递到SMTP服务器，而SMTP服务器可以将其传递到一个或多个邮箱，或将其传递到另一个系统（可能使用SMTP）。参数字段包含反向路径，并且可能包含可选参数。通常，只有在没有邮件事务进行时，才能发送邮件命令，请参见第4.1.4节。
The reverse-path consists of the sender mailbox. Historically, that mailbox might optionally have been preceded by a list of hosts, but that behavior is now deprecated (see appendix C). In some types of reporting messages for which a reply is likely to cause a mail loop (for example, mail delivery and nondelivery notifications), the reverse-path may be null (see section 3.7).
反向路径由发件人邮箱组成。从历史上看，该邮箱前面可能会有一个主机列表，但这种行为现在已被弃用（请参见附录C）。在回复可能导致邮件循环的某些类型的报告邮件中（例如，邮件传递和非传递通知），反向路径可能为空（请参见第3.7节）。
This command clears the reverse-path buffer, the forward-path buffer, and the mail data buffer; and inserts the reverse-path information from this command into the reverse-path buffer.
此命令清除反向路径缓冲区、正向路径缓冲区和邮件数据缓冲区；并将此命令中的反向路径信息插入反向路径缓冲区。
If service extensions were negotiated, the MAIL command may also carry parameters associated with a particular service extension.
如果服务扩展已协商，则MAIL命令还可能携带与特定服务扩展相关联的参数。
Syntax:
语法：
"MAIL FROM:" ("<>" / Reverse-Path)
[SP Mail-parameters] CRLF
"MAIL FROM:" ("<>" / Reverse-Path)
[SP Mail-parameters] CRLF
This command is used to identify an individual recipient of the mail data; multiple recipients are specified by multiple use of this command. The argument field contains a forward-path and may contain optional parameters.
此命令用于标识邮件数据的单个收件人；多次使用此命令可指定多个收件人。参数字段包含正向路径，并且可能包含可选参数。
The forward-path normally consists of the required destination mailbox. Sending systems SHOULD not generate the optional list of hosts known as a source route. Receiving systems MUST recognize
转发路径通常由所需的目标邮箱组成。发送系统不应生成称为源路由的可选主机列表。接收系统必须识别
source route syntax but SHOULD strip off the source route specification and utilize the domain name associated with the mailbox as if the source route had not been provided.
源路由语法，但应去掉源路由规范，并使用与邮箱关联的域名，就像未提供源路由一样。
Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST NOT be copied into the reverse-path. When mail reaches its ultimate destination (the forward-path contains only a destination mailbox), the SMTP server inserts it into the destination mailbox in accordance with its host mail conventions.
类似地，中继主机应剥离或忽略源路由，并且不得将名称复制到反向路径中。当邮件到达其最终目标时（转发路径仅包含目标邮箱），SMTP服务器将根据其主机邮件约定将其插入目标邮箱。
For example, mail received at relay host xyz.com with envelope commands
例如，通过信封命令在中继主机xyz.com上接收邮件
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
will normally be sent directly on to host d.bar.org with envelope commands
通常会使用信封命令直接发送到主机d.bar.org
MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org>
MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org>
As provided in appendix C, xyz.com MAY also choose to relay the message to hosta.int, using the envelope commands
如附录C所述，xyz.com还可以选择使用信封命令将消息中继到hosta.int
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
or to jkl.org, using the envelope commands
或者使用envelope命令访问jkl.org
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org>
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org>
Of course, since hosts are not required to relay mail at all, xyz.com may also reject the message entirely when the RCPT command is received, using a 550 code (since this is a "policy reason").
当然，由于主机根本不需要中继邮件，xyz.com也可以在收到RCPT命令时使用550代码完全拒绝邮件（因为这是“策略原因”）。
If service extensions were negotiated, the RCPT command may also carry parameters associated with a particular service extension offered by the server. The client MUST NOT transmit parameters other than those associated with a service extension offered by the server in its EHLO response.
如果协商了服务扩展，RCPT命令还可能携带与服务器提供的特定服务扩展相关联的参数。客户端不得传输与服务器在其EHLO响应中提供的服务扩展相关联的参数以外的参数。
Syntax:
"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
[SP Rcpt-parameters] CRLF
Syntax:
"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
[SP Rcpt-parameters] CRLF
The receiver normally sends a 354 response to DATA, and then treats the lines (strings ending in <CRLF> sequences, as described in section 2.3.7) following the command as mail data from the sender. This command causes the mail data to be appended to the mail data buffer. The mail data may contain any of the 128 ASCII character codes, although experience has indicated that use of control characters other than SP, HT, CR, and LF may cause problems and SHOULD be avoided when possible.
接收方通常向数据发送354响应，然后将命令后的行（以<CRLF>序列结尾的字符串，如第2.3.7节所述）视为来自发送方的邮件数据。此命令将邮件数据附加到邮件数据缓冲区。邮件数据可能包含128个ASCII字符代码中的任何一个，但经验表明，使用SP、HT、CR和LF以外的控制字符可能会导致问题，应尽可能避免使用。
The mail data is terminated by a line containing only a period, that is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This is the end of mail data indication. Note that the first <CRLF> of this terminating sequence is also the <CRLF> that ends the final line of the data (message text) or, if there was no data, ends the DATA command itself. An extra <CRLF> MUST NOT be added, as that would cause an empty line to be added to the message. The only exception to this rule would arise if the message body were passed to the originating SMTP-sender with a final "line" that did not end in <CRLF>; in that case, the originating SMTP system MUST either reject the message as invalid or add <CRLF> in order to have the receiving SMTP server recognize the "end of data" condition.
邮件数据以仅包含句点的行终止，即字符序列“<CRLF><CRLF>”（参见第4.5.2节）。这是邮件结束数据指示。请注意，此终止序列的第一个<CRLF>也是结束数据最后一行（消息文本）的<CRLF>，或者，如果没有数据，则结束数据命令本身。不得添加额外的<CRLF>，因为这将导致在消息中添加空行。此规则的唯一例外情况是，如果邮件正文被传递给原始SMTP发件人，最后一行不是以<CRLF>结尾；在这种情况下，原始SMTP系统必须将邮件视为无效而拒绝或添加<CRLF>，以便接收SMTP服务器识别“数据结束”情况。
The custom of accepting lines ending only in <LF>, as a concession to non-conforming behavior on the part of some UNIX systems, has proven to cause more interoperability problems than it solves, and SMTP server systems MUST NOT do this, even in the name of improved robustness. In particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of mail data indication.
接受仅以<LF>结尾的行的习惯，作为对某些UNIX系统的不一致行为的让步，已被证明会导致比它所解决的更多的互操作性问题，SMTP服务器系统不能这样做，即使是以提高健壮性的名义。特别是，序列“<LF><LF>”（裸行馈送，无回车）不得视为等同于<CRLF><CRLF>，作为邮件结束数据指示。
Receipt of the end of mail data indication requires the server to process the stored mail transaction information. This processing consumes the information in the reverse-path buffer, the forward-path buffer, and the mail data buffer, and on the completion of this command these buffers are cleared. If the processing is successful, the receiver MUST send an OK reply. If the processing fails the receiver MUST send a failure reply. The SMTP model does not allow for partial failures at this point: either the message is accepted by the server for delivery and a positive response is returned or it is not accepted and a failure reply is returned. In sending a positive completion reply to the end of data indication, the receiver takes full responsibility for the message (see section 6.1). Errors that are diagnosed subsequently MUST be reported in a mail message, as discussed in section 4.4.
接收邮件结束数据指示需要服务器处理存储的邮件事务信息。此处理消耗反向路径缓冲区、正向路径缓冲区和邮件数据缓冲区中的信息，并且在完成此命令后，这些缓冲区将被清除。如果处理成功，接收方必须发送一个OK回复。如果处理失败，接收方必须发送失败回复。SMTP模型此时不允许部分失败：服务器接受邮件进行传递并返回肯定响应，或者不接受邮件并返回失败响应。在向数据结束指示发送肯定完成回复时，接收方对该消息承担全部责任（见第6.1节）。如第4.4节所述，随后诊断的错误必须在邮件中报告。
When the SMTP server accepts a message either for relaying or for final delivery, it inserts a trace record (also referred to interchangeably as a "time stamp line" or "Received" line) at the top of the mail data. This trace record indicates the identity of the host that sent the message, the identity of the host that received the message (and is inserting this time stamp), and the date and time the message was received. Relayed messages will have multiple time stamp lines. Details for formation of these lines, including their syntax, is specified in section 4.4.
当SMTP服务器接受用于中继或最终传递的邮件时，它会在邮件数据的顶部插入跟踪记录（也称为“时间戳行”或“已接收”行）。此跟踪记录指示发送消息的主机的标识、接收消息的主机的标识（并插入此时间戳）以及接收消息的日期和时间。中继消息将具有多个时间戳行。第4.4节规定了这些行的构成细节，包括它们的语法。
Additional discussion about the operation of the DATA command appears in section 3.3.
关于数据命令操作的更多讨论见第3.3节。
Syntax: "DATA" CRLF
语法：“数据”CRLF
This command specifies that the current mail transaction will be aborted. Any stored sender, recipients, and mail data MUST be discarded, and all buffers and state tables cleared. The receiver MUST send a "250 OK" reply to a RSET command with no arguments. A reset command may be issued by the client at any time. It is effectively equivalent to a NOOP (i.e., if has no effect) if issued immediately after EHLO, before EHLO is issued in the session, after an end-of-data indicator has been sent and acknowledged, or immediately before a QUIT. An SMTP server MUST NOT close the connection as the result of receiving a RSET; that action is reserved for QUIT (see section 4.1.1.10).
此命令指定将中止当前邮件事务。必须丢弃所有存储的发件人、收件人和邮件数据，并清除所有缓冲区和状态表。接收器必须向RSET命令发送“250 OK”回复，且不带任何参数。客户机可随时发出重置命令。如果在EHLO之后立即发布，在会话中发布EHLO之前，在发送并确认数据结束指示符之后，或者在退出之前，它实际上相当于NOOP（即，如果没有效果）。SMTP服务器不得因收到RSET而关闭连接；该操作保留用于退出（见第4.1.1.10节）。
Since EHLO implies some additional processing and response by the server, RSET will normally be more efficient than reissuing that command, even though the formal semantics are the same.
由于EHLO意味着服务器进行一些额外的处理和响应，因此RSET通常比重新发出该命令更有效，即使形式语义相同。
There are circumstances, contrary to the intent of this specification, in which an SMTP server may receive an indication that the underlying TCP connection has been closed or reset. To preserve the robustness of the mail system, SMTP servers SHOULD be prepared for this condition and SHOULD treat it as if a QUIT had been received before the connection disappeared.
与本规范的意图相反，在某些情况下，SMTP服务器可能会收到底层TCP连接已关闭或重置的指示。为保持邮件系统的健壮性，SMTP服务器应为此情况做好准备，并应将其视为在连接消失之前已收到退出。
Syntax: "RSET" CRLF
语法：“RSET”CRLF
This command asks the receiver to confirm that the argument identifies a user or mailbox. If it is a user name, information is returned as specified in section 3.5.
此命令要求接收方确认参数标识用户或邮箱。如果是用户名，则按照第3.5节的规定返回信息。
This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer.
此命令对反向路径缓冲区、正向路径缓冲区或邮件数据缓冲区没有影响。
Syntax: "VRFY" SP String CRLF
语法：“VRFY”SP字符串CRLF
This command asks the receiver to confirm that the argument identifies a mailing list, and if so, to return the membership of that list. If the command is successful, a reply is returned containing information as described in section 3.5. This reply will have multiple lines except in the trivial case of a one-member list.
此命令要求接收方确认参数标识邮件列表，如果是，则返回该列表的成员身份。如果命令成功，将返回包含第3.5节所述信息的回复。这个回复将有多行，除了一个成员列表的简单情况。
This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer and may be issued at any time.
此命令对反向路径缓冲区、正向路径缓冲区或邮件数据缓冲区没有影响，可以随时发出。
Syntax: "EXPN" SP String CRLF
语法：“EXPN”SP字符串CRLF
This command causes the server to send helpful information to the client. The command MAY take an argument (e.g., any command name) and return more specific information as a response.
此命令使服务器向客户端发送有用的信息。该命令可以接受一个参数（例如，任何命令名），并返回更具体的信息作为响应。
This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer and may be issued at any time.
此命令对反向路径缓冲区、正向路径缓冲区或邮件数据缓冲区没有影响，可以随时发出。
SMTP servers SHOULD support HELP without arguments and MAY support it with arguments.
SMTP服务器应支持不带参数的帮助，并可能支持带参数的帮助。
Syntax: "HELP" [ SP String ] CRLF
语法：“HELP”[SP String]CRLF
This command does not affect any parameters or previously entered commands. It specifies no action other than that the receiver send an OK reply.
此命令不影响任何参数或以前输入的命令。它只指定接收方发送OK回复，而不指定其他操作。
This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer and may be issued at any time. If a parameter string is specified, servers SHOULD ignore it.
此命令对反向路径缓冲区、正向路径缓冲区或邮件数据缓冲区没有影响，可以随时发出。如果指定了参数字符串，服务器应该忽略它。
Syntax: "NOOP" [ SP String ] CRLF
语法：“NOOP”[SP String]CRLF
This command specifies that the receiver MUST send an OK reply, and then close the transmission channel.
此命令指定接收器必须发送OK应答，然后关闭传输通道。
The receiver MUST NOT intentionally close the transmission channel until it receives and replies to a QUIT command (even if there was an error). The sender MUST NOT intentionally close the transmission channel until it sends a QUIT command and SHOULD wait until it receives the reply (even if there was an error response to a previous command). If the connection is closed prematurely due to violations of the above or system or network failure, the server MUST cancel any pending transaction, but not undo any previously completed transaction, and generally MUST act as if the command or transaction in progress had received a temporary error (i.e., a 4yz response).
在接收并回复退出命令（即使出现错误）之前，接收器不得故意关闭传输通道。发送方在发送QUIT命令之前不得故意关闭传输通道，并应等待收到回复（即使之前的命令有错误响应）。如果由于违反上述规定或系统或网络故障而过早关闭连接，则服务器必须取消任何挂起的事务，但不能撤消任何以前完成的事务，并且通常必须像正在进行的命令或事务收到临时错误（即4yz响应）一样操作。
The QUIT command may be issued at any time.
可以随时发出QUIT命令。
Syntax: "QUIT" CRLF
语法：“退出”CRLF
The syntax of the argument fields of the above commands (using the syntax specified in [8] where applicable) is given below. Some of the productions given below are used only in conjunction with source routes as described in appendix C. Terminals not defined in this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax [8 (section 6)] or in the message format syntax [32].
下面给出了上述命令的参数字段的语法（在适用的情况下使用[8]中指定的语法）。以下给出的一些产品仅与附录C中所述的源路由一起使用。本文件中未定义的终端，如ALPHA、DIGIT、SP、CR、LF、CRLF，如“核心”语法[8（第6节）]或消息格式语法[32]中所定义。
Reverse-path = Path
Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," A-d-l )
; Note that this form, the so-called "source route",
; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
; ignored.
At-domain = "@" domain
Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param)
Reverse-path = Path
Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," A-d-l )
; Note that this form, the so-called "source route",
; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
; ignored.
At-domain = "@" domain
Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param)
esmtp-param = esmtp-keyword ["=" esmtp-value]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value = 1*(%d33-60 / %d62-127)
; any CHAR excluding "=", SP, and control characters
Keyword = Ldh-str
Argument = Atom
Domain = (sub-domain 1*("." sub-domain)) / address-literal
sub-domain = Let-dig [Ldh-str]
esmtp-param = esmtp-keyword ["=" esmtp-value]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value = 1*(%d33-60 / %d62-127)
; any CHAR excluding "=", SP, and control characters
Keyword = Ldh-str
Argument = Atom
Domain = (sub-domain 1*("." sub-domain)) / address-literal
sub-domain = Let-dig [Ldh-str]
address-literal = "[" IPv4-address-literal / IPv6-address-literal / General-address-literal "]" ; See section 4.1.3
address literal=“[“IPv4地址文字/IPv6地址文字/通用地址文字”]；见第4.1.3节
Mailbox = Local-part "@" Domain
邮箱=本地部分“@”域
Local-part = Dot-string / Quoted-string ; MAY be case-sensitive
局部部分=点字符串/带引号的字符串；可能区分大小写
Dot-string = Atom *("." Atom)
点字符串=原子*（“”原子）
Atom = 1*atext
Atom = 1*atext
Quoted-string = DQUOTE *qcontent DQUOTE
Quoted string=DQUOTE*qcontent DQUOTE
String = Atom / Quoted-string
String = Atom / Quoted-string
While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case-sensitive. For any purposes that require generating or comparing Local-parts (e.g., to specific mailbox names), all quoted forms MUST be treated as equivalent and the sending system SHOULD transmit the form that uses the minimum quoting possible.
虽然上面对本地部分的定义相对宽松，但为了实现最大的互操作性，希望接收邮件的主机应避免在本地部分需要（或使用）带引号的字符串表单或本地部分区分大小写的情况下定义邮箱。对于需要生成或比较本地部分（例如，与特定邮箱名称）的任何目的，必须将所有引用的表单视为等效表单，发送系统应传输使用尽可能最小引用的表单。
Systems MUST NOT define mailboxes in such a way as to require the use in SMTP of non-ASCII characters (octets with the high order bit set to one) or ASCII "control characters" (decimal value 0-31 and 127). These characters MUST NOT be used in MAIL or RCPT commands or other commands that require mailbox names.
系统定义邮箱的方式不得要求在SMTP中使用非ASCII字符（高阶位设置为1的八位字节）或ASCII“控制字符”（十进制值0-31和127）。这些字符不得用于MAIL或RCPT命令或需要邮箱名称的其他命令中。
Note that the backslash, "\", is a quote character, which is used to indicate that the next character is to be used literally (instead of its normal interpretation). For example, "Joe\,Smith" indicates a single nine character user field with the comma being the fourth character of the field.
请注意，反斜杠“\”是一个引号字符，用于指示下一个字符将按字面意思使用（而不是其正常解释）。例如，“Joe\，Smith”表示一个九个字符的用户字段，逗号是该字段的第四个字符。
To promote interoperability and consistent with long-standing guidance about conservative use of the DNS in naming and applications (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]), characters outside the set of alphas, digits, and hyphen MUST NOT appear in domain name labels for SMTP clients or servers. In particular, the underscore character is not permitted. SMTP servers that receive a command in which invalid character codes have been employed, and for which there are no other reasons for rejection, MUST reject that command with a 501 response.
为了促进互操作性，并与有关在命名和应用程序中保守使用DNS的长期指导一致（例如，请参阅基本DNS文档RFC1035[22]第2.3.1节），SMTP客户端或服务器的域名标签中不得出现字母、数字和连字符集之外的字符。特别是，不允许使用下划线字符。如果SMTP服务器接收的命令中使用了无效字符代码，并且没有其他拒绝原因，则必须以501响应拒绝该命令。
Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2], which indicates an (IPv4) Internet Address in sequence-of-octets form. For IPv6 and other forms of addressing that might eventually be standardized, the form consists of a standardized "tag" that identifies the address syntax, a colon, and the address itself, in a format specified as part of the IPv6 standards [17].
有时，域名系统不知道某个主机，通信（尤其是报告和修复错误的通信）被阻止。为了绕过这个障碍，允许使用一种特殊的文本形式的地址作为域名的替代。对于IPv4地址，这种形式使用四个小的十进制整数，用点分隔，并用括号括起来，如[123.255.37.2]，它以八位字节形式表示（IPv4）互联网地址。对于IPv6和其他可能最终标准化的寻址形式，该形式由一个标准化的“标记”组成，该标记以IPv6标准规定的格式标识地址语法、冒号和地址本身[17]。
Specifically:
明确地：
IPv4-address-literal = Snum 3("." Snum)
IPv6-address-literal = "IPv6:" IPv6-addr
General-address-literal = Standardized-tag ":" 1*dcontent
Standardized-tag = Ldh-str
; MUST be specified in a standards-track RFC
; and registered with IANA
IPv4-address-literal = Snum 3("." Snum)
IPv6-address-literal = "IPv6:" IPv6-addr
General-address-literal = Standardized-tag ":" 1*dcontent
Standardized-tag = Ldh-str
; MUST be specified in a standards-track RFC
; and registered with IANA
Snum = 1*3DIGIT ; representing a decimal integer
; value in the range 0 through 255
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
Snum = 1*3DIGIT ; representing a decimal integer
; value in the range 0 through 255
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
IPv6-hex = 1*4HEXDIG
IPv6-full = IPv6-hex 7(":" IPv6-hex)
IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
IPv6-hex)]
; The "::" represents at least 2 16-bit groups of zeros
; No more than 6 groups in addition to the "::" may be
; present
IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
IPv6-hex = 1*4HEXDIG
IPv6-full = IPv6-hex 7(":" IPv6-hex)
IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
IPv6-hex)]
; The "::" represents at least 2 16-bit groups of zeros
; No more than 6 groups in addition to the "::" may be
; present
IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
[IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
; The "::" represents at least 2 16-bit groups of zeros
; No more than 4 groups in addition to the "::" and
; IPv4-address-literal may be present
[IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
; The "::" represents at least 2 16-bit groups of zeros
; No more than 4 groups in addition to the "::" and
; IPv4-address-literal may be present
There are restrictions on the order in which these commands may be used.
这些命令的使用顺序有限制。
A session that will contain mail transactions MUST first be initialized by the use of the EHLO command. An SMTP server SHOULD accept commands for non-mail transactions (e.g., VRFY or EXPN) without this initialization.
必须首先使用EHLO命令初始化包含邮件事务的会话。SMTP服务器应在不进行此初始化的情况下接受用于非邮件事务（例如VRFY或EXPN）的命令。
An EHLO command MAY be issued by a client later in the session. If it is issued after the session begins, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued. In other words, the sequence of RSET followed immediately by EHLO is redundant, but not harmful other than in the performance cost of executing unnecessary commands.
EHLO命令可以在会话的稍后由客户端发出。如果在会话开始后发出，SMTP服务器必须清除所有缓冲区并重置状态，就像发出RSET命令一样。换言之，紧跟EHLO的RSET序列是冗余的，但除了执行不必要命令的性能成本之外，没有其他危害。
If the EHLO command is not acceptable to the SMTP server, 501, 500, or 502 failure replies MUST be returned as appropriate. The SMTP server MUST stay in the same state after transmitting these replies that it was in before the EHLO was received.
如果SMTP服务器不接受EHLO命令，则必须根据需要返回501、500或502失败回复。SMTP服务器在发送这些回复后必须保持与收到EHLO之前相同的状态。
The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a valid principal host name (not a CNAME or MX name) for its host. If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name and supplemental information provided that will assist in identifying the client.
如果可能，SMTP客户端必须确保EHLO命令的域参数是其主机的有效主主机名（不是CNAME或MX名称）。如果这是不可能的（例如，当客户的地址是动态分配的，并且客户没有明显的名称时），则应使用地址文字替换域名和提供的补充信息，以帮助识别客户。
An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only.
SMTP服务器可以验证EHLO命令中的域名参数是否实际对应于客户端的IP地址。但是，如果验证失败，服务器不得因此拒绝接受消息：有关验证失败的信息仅用于日志记录和跟踪。
The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time during a session, or without previously initializing a session. SMTP servers SHOULD process these normally (that is, not return a 503 code) even if no EHLO command has yet been received; clients SHOULD open a session with EHLO before sending these commands.
NOOP、HELP、EXPN、VRFY和RSET命令可以在会话期间的任何时间使用，也可以在之前不初始化会话的情况下使用。SMTP服务器应正常处理这些（即，不返回503代码），即使尚未收到EHLO命令；在发送这些命令之前，客户端应打开与EHLO的会话。
If these rules are followed, the example in RFC 821 that shows "550 access denied to you" in response to an EXPN command is incorrect unless an EHLO command precedes the EXPN or the denial of access is based on the client's IP address or other authentication or authorization-determining mechanisms.
如果遵循这些规则，RFC 821中显示“550拒绝您访问”以响应EXPN命令的示例是不正确的，除非EXPN之前有EHLO命令，或者拒绝访问基于客户端的IP地址或其他身份验证或授权确定机制。
The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a mail transaction. Once started, a mail transaction consists of a transaction beginning command, one or more RCPT commands, and a DATA command, in that order. A mail transaction may be aborted by the RSET (or a new EHLO) command. There may be zero or more transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail transaction is already open, i.e., it should be sent only if no mail transaction had been started in the session, or it the previous one successfully concluded with a successful DATA command, or if the previous one was aborted with a RSET.
MAIL命令（或过时的SEND、SOML或SAML命令）开始邮件事务。一旦启动，邮件事务将按顺序由事务开始命令、一个或多个RCPT命令和一个数据命令组成。RSET（或新的EHLO）命令可以中止邮件事务。一个会话中可能有零个或多个事务。如果邮件事务已打开，则不得发送邮件（或SEND、SOML或SAML），也就是说，只有在会话中未启动邮件事务，或者前一个邮件事务通过成功的数据命令成功结束，或者前一个邮件事务通过RSET中止时，才应发送邮件。
If the transaction beginning command argument is not acceptable, a 501 failure reply MUST be returned and the SMTP server MUST stay in the same state. If the commands in a transaction are out of order to the degree that they cannot be processed by the server, a 503 failure reply MUST be returned and the SMTP server MUST stay in the same state.
如果事务开始命令参数不可接受，则必须返回501失败回复，并且SMTP服务器必须保持相同状态。如果事务中的命令出现故障，以至于服务器无法处理这些命令，则必须返回503故障回复，并且SMTP服务器必须保持相同的状态。
The last command in a session MUST be the QUIT command. The QUIT command cannot be used at any other time in a session, but SHOULD be used by the client SMTP to request connection closure, even when no session opening command was sent and accepted.
会话中的最后一个命令必须是QUIT命令。QUIT命令不能在会话中的任何其他时间使用，但客户端SMTP应使用该命令请求关闭连接，即使未发送和接受任何会话打开命令。
As specified in section 2.2.2, commands starting in "X" may be used by bilateral agreement between the client (sending) and server (receiving) SMTP agents. An SMTP server that does not recognize such a command is expected to reply with "500 Command not recognized". An extended SMTP server MAY list the feature names associated with these private commands in the response to the EHLO command.
如第2.2.2节所述，以“X”开头的命令可由客户端（发送）和服务器（接收）SMTP代理之间的双边协议使用。无法识别此类命令的SMTP服务器应以“500 command not Recognited”进行回复。扩展SMTP服务器可以在对EHLO命令的响应中列出与这些专用命令关联的功能名称。
Commands sent or accepted by SMTP systems that do not start with "X" MUST conform to the requirements of section 2.2.2.
SMTP系统发送或接受的命令（不以“X”开头）必须符合第2.2.2节的要求。
Replies to SMTP commands serve to ensure the synchronization of requests and actions in the process of mail transfer and to guarantee that the SMTP client always knows the state of the SMTP server. Every command MUST generate exactly one reply.
对SMTP命令的回复用于确保邮件传输过程中请求和操作的同步，并确保SMTP客户端始终知道SMTP服务器的状态。每个命令必须只生成一个回复。
The details of the command-reply sequence are described in section 4.3.
第4.3节描述了命令回复序列的详细信息。
An SMTP reply consists of a three digit number (transmitted as three numeric characters) followed by some text unless specified otherwise in this document. The number is for use by automata to determine what state to enter next; the text is for the human user. The three digits contain enough encoded information that the SMTP client need not examine the text and may either discard it or pass it on to the user, as appropriate. Exceptions are as noted elsewhere in this document. In particular, the 220, 221, 251, 421, and 551 reply codes are associated with message text that must be parsed and interpreted by machines. In the general case, the text may be receiver dependent and context dependent, so there are likely to be varying texts for each reply code. A discussion of the theory of reply codes is given in section 4.2.1. Formally, a reply is defined to be the sequence: a three-digit code, <SP>, one line of text, and <CRLF>, or a multiline reply (as defined in section 4.2.1). Since, in violation of this specification, the text is sometimes not sent, clients which do not receive it SHOULD be prepared to process the code alone (with or without a trailing space character). Only the EHLO, EXPN, and HELP commands are expected to result in multiline replies in normal circumstances, however, multiline replies are allowed for any command.
SMTP回复由三位数字（以三个数字字符传输）和一些文本组成，除非本文档中另有规定。该数字用于自动机确定下一步要进入的状态；文本是供人类用户使用的。这三个数字包含足够的编码信息，SMTP客户端无需检查文本，可以丢弃文本或将其传递给用户（视情况而定）。例外情况如本文件其他部分所述。特别地，220、221、251、421和551应答码与必须由机器解析和解释的消息文本相关联。在一般情况下，文本可能依赖于接收者和上下文，因此每个回复代码可能有不同的文本。第4.2.1节对应答码理论进行了讨论。形式上，回复被定义为序列：三位代码、<SP>、一行文本和<CRLF>，或多行回复（如第4.2.1节所定义）。由于违反本规范，文本有时不发送，因此未接收文本的客户端应准备单独处理代码（带或不带尾随空格字符）。在正常情况下，只有EHLO、EXPN和HELP命令才能产生多行回复，但是，任何命令都允许多行回复。
In ABNF, server responses are:
在ABNF中，服务器响应为：
Greeting = "220 " Domain [ SP text ] CRLF Reply-line = Reply-code [ SP text ] CRLF
Greeting=“220”域[SP text]CRLF回复行=回复代码[SP text]CRLF
where "Greeting" appears only in the 220 response that announces that the server is opening its part of the connection.
其中，“问候语”仅出现在220响应中，该响应宣布服务器正在打开其连接部分。
An SMTP server SHOULD send only the reply codes listed in this document. An SMTP server SHOULD use the text shown in the examples whenever appropriate.
SMTP服务器应仅发送此文档中列出的回复代码。SMTP服务器应在适当时使用示例中显示的文本。
An SMTP client MUST determine its actions only by the reply code, not by the text (except for the "change of address" 251 and 551 and, if necessary, 220, 221, and 421 replies); in the general case, any text, including no text at all (although senders SHOULD NOT send bare codes), MUST be acceptable. The space (blank) following the reply code is considered part of the text. Whenever possible, a receiver-SMTP SHOULD test the first digit (severity indication) of the reply code.
SMTP客户端必须仅通过回复代码而不是文本来确定其操作（除了“地址更改”251和551以及（如有必要）220、221和421回复）；在一般情况下，任何文本，包括完全没有文本（尽管发送方不应发送裸代码），都必须是可接受的。回复代码后面的空格（空白）被视为文本的一部分。只要有可能，SMTP接收方应测试回复代码的第一位数字（严重性指示）。
The list of codes that appears below MUST NOT be construed as permanent. While the addition of new codes should be a rare and significant activity, with supplemental information in the textual part of the response being preferred, new codes may be added as the result of new Standards or Standards-track specifications. Consequently, a sender-SMTP MUST be prepared to handle codes not specified in this document and MUST do so by interpreting the first digit only.
不得将下面出现的代码列表解释为永久代码。虽然添加新代码应该是一项罕见且重要的活动，最好在响应的文本部分添加补充信息，但新标准或标准跟踪规范可能会添加新代码。因此，发件人SMTP必须准备好处理本文档中未指定的代码，并且必须仅解释第一位数字。
The three digits of the reply each have a special significance. The first digit denotes whether the response is good, bad or incomplete. An unsophisticated SMTP client, or one that receives an unexpected code, will be able to determine its next action (proceed as planned, redo, retrench, etc.) by examining this first digit. An SMTP client that wants to know approximately what kind of error occurred (e.g., mail system error, command syntax error) may examine the second digit. The third digit and any supplemental information that may be present is reserved for the finest gradation of information.
答复的三位数字各有特殊意义。第一位数字表示响应是好的、坏的还是不完整的。简单的SMTP客户端或接收到意外代码的客户端将能够通过检查第一位数字来确定其下一个操作（按计划继续、重做、缩减等）。SMTP客户端如果想知道发生了什么类型的错误（例如，邮件系统错误、命令语法错误），可以检查第二个数字。第三位数字和可能存在的任何补充信息保留用于信息的最佳等级。
There are five values for the first digit of the reply code:
回复代码的第一位有五个值：
1yz Positive Preliminary reply The command has been accepted, but the requested action is being held in abeyance, pending confirmation of the information in this reply. The SMTP client should send another command specifying whether to continue or abort the action. Note: unextended SMTP does not have any commands that allow this type of reply, and so does not have continue or abort commands.
1yz肯定初步答复该命令已被接受，但请求的行动被搁置，等待本答复中信息的确认。SMTP客户端应发送另一个命令，指定是继续还是中止操作。注意：未扩展的SMTP没有任何允许此类型回复的命令，因此没有continue或abort命令。
2yz Positive Completion reply The requested action has been successfully completed. A new request may be initiated.
2yz肯定完成回复请求的操作已成功完成。可能会启动新的请求。
3yz Positive Intermediate reply The command has been accepted, but the requested action is being held in abeyance, pending receipt of further information. The SMTP client should send another command specifying this information. This reply is used in command sequence groups (i.e., in DATA).
3yz肯定中间回复命令已被接受，但请求的操作处于暂停状态，等待收到进一步信息。SMTP客户端应发送另一个指定此信息的命令。此回复用于命令序列组（即数据）。
4yz Transient Negative Completion reply The command was not accepted, and the requested action did not occur. However, the error condition is temporary and the action may be requested again. The sender should return to the beginning of the command sequence (if any). It is difficult to assign a meaning to "transient" when two different sites (receiver- and
4yz瞬态否定完成回复命令未被接受，请求的操作未发生。但是，错误情况是暂时的，可能会再次请求该操作。发送方应返回到命令序列的开头（如果有）。当两个不同的位置（接收器和接收器）同时出现时，很难给“瞬态”赋予一个含义
sender-SMTP agents) must agree on the interpretation. Each reply in this category might have a different time value, but the SMTP client is encouraged to try again. A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be successful if repeated without any change in command form or in properties of the sender or receiver (that is, the command is repeated identically and the receiver does not put up a new implementation.)
发件人（SMTP代理）必须同意解释。此类别中的每个答复可能具有不同的时间值，但建议SMTP客户端重试。确定回复是否属于4yz或5yz类别（见下文）的一条经验法则是，如果在命令形式或发送方或接收方的属性没有任何变化的情况下重复回复可以成功，则回复为4yz（即，相同地重复该命令，且接收方不提供新的实现）
5yz Permanent Negative Completion reply The command was not accepted and the requested action did not occur. The SMTP client is discouraged from repeating the exact request (in the same sequence). Even some "permanent" error conditions can be corrected, so the human user may want to direct the SMTP client to reinitiate the command sequence by direct action at some point in the future (e.g., after the spelling has been changed, or the user has altered the account status).
5yz永久否定完成回复命令未被接受，请求的操作未发生。不鼓励SMTP客户端重复确切的请求（以相同的顺序）。甚至一些“永久性”错误条件也可以纠正，因此人工用户可能希望在将来的某个时候（例如，拼写更改后，或用户更改了帐户状态后）通过直接操作指示SMTP客户端重新初始化命令序列。
The second digit encodes responses in specific categories:
第二个数字对特定类别的响应进行编码：
x0z Syntax: These replies refer to syntax errors, syntactically correct commands that do not fit any functional category, and unimplemented or superfluous commands.
x0z语法：这些回复涉及语法错误、不适合任何功能类别的语法正确的命令以及未实现或多余的命令。
x1z Information: These are replies to requests for information, such as status or help.
x1z信息：这些是对信息请求的回复，例如状态或帮助。
x2z Connections: These are replies referring to the transmission channel.
x2z连接：这些是指传输通道的回复。
x3z Unspecified.
x3z未指定。
x4z Unspecified.
x4z未指定。
x5z Mail system: These replies indicate the status of the receiver mail system vis-a-vis the requested transfer or other mail system action.
x5z邮件系统：这些回复指示收件人邮件系统相对于请求的传输或其他邮件系统操作的状态。
The third digit gives a finer gradation of meaning in each category specified by the second digit. The list of replies illustrates this. Each reply text is recommended rather than mandatory, and may even change according to the command with which it is associated. On the other hand, the reply codes must strictly follow the specifications in this section. Receiver implementations should not invent new codes for slightly different situations from the ones described here, but rather adapt codes already defined.
第三个数字在第二个数字指定的每个类别中给出了更精细的意义层次。答复清单说明了这一点。每个回复文本都是推荐的，而不是强制的，甚至可能会根据与其关联的命令进行更改。另一方面，回复代码必须严格遵守本节中的规范。接收器实现不应该为与这里描述的稍有不同的情况发明新的代码，而应该调整已经定义的代码。
For example, a command such as NOOP, whose successful execution does not offer the SMTP client any new information, will return a 250 reply. The reply is 502 when the command requests an unimplemented non-site-specific action. A refinement of that is the 504 reply for a command that is implemented, but that requests an unimplemented parameter.
例如，NOOP等命令的成功执行不会向SMTP客户端提供任何新信息，它将返回250个回复。当命令请求未实现的非站点特定操作时，回复为502。对已实现但请求未实现参数的命令的504应答是对该命令的改进。
The reply text may be longer than a single line; in these cases the complete text must be marked so the SMTP client knows when it can stop reading the reply. This requires a special format to indicate a multiple line reply.
回复文本可能长于一行；在这些情况下，必须标记完整文本，以便SMTP客户端知道何时可以停止读取回复。这需要一种特殊的格式来表示多行回复。
The format for multiline replies requires that every line, except the last, begin with the reply code, followed immediately by a hyphen, "-" (also known as minus), followed by text. The last line will begin with the reply code, followed immediately by <SP>, optionally some text, and <CRLF>. As noted above, servers SHOULD send the <SP> if subsequent text is not sent, but clients MUST be prepared for it to be omitted.
多行回复的格式要求每行（最后一行除外）以回复代码开头，紧接着是连字符“-”（也称为减号），然后是文本。最后一行将以回复代码开头，紧接着是<SP>、可选的一些文本和<CRLF>。如上所述，如果未发送后续文本，服务器应发送<SP>，但客户端必须做好准备，以便省略该文本。
For example:
例如：
123-First line 123-Second line 123-234 text beginning with numbers 123 The last line
123第一行123第二行123-234以数字123开头的文本最后一行
In many cases the SMTP client then simply needs to search for a line beginning with the reply code followed by <SP> or <CRLF> and ignore all preceding lines. In a few cases, there is important data for the client in the reply "text". The client will be able to identify these cases from the current context.
在许多情况下，SMTP客户端只需搜索以回复代码开头的行，后跟<SP>或<CRLF>，然后忽略前面的所有行。在少数情况下，回复“文本”中有客户的重要数据。客户机将能够从当前上下文中识别这些案例。
500 Syntax error, command unrecognized (This may include errors such as command line too long) 501 Syntax error in parameters or arguments 502 Command not implemented (see section 4.2.4) 503 Bad sequence of commands 504 Command parameter not implemented
500语法错误，无法识别命令（这可能包括命令行过长等错误）501参数或参数中的语法错误502未执行命令（参见第4.2.4节）503命令序列错误504未执行命令参数
211 System status, or system help reply 214 Help message (Information on how to use the receiver or the meaning of a particular non-standard command; this reply is useful only to the human user)
211系统状态或系统帮助回复214帮助消息（关于如何使用接收器或特定非标准命令含义的信息；此回复仅对人类用户有用）
220 <domain> Service ready 221 <domain> Service closing transmission channel 421 <domain> Service not available, closing transmission channel (This may be a reply to any command if the service knows it must shut down)
220<domain>服务就绪221<domain>服务关闭传输通道421<domain>服务不可用，关闭传输通道（如果服务知道它必须关闭，这可能是对任何命令的回复）
250 Requested mail action okay, completed 251 User not local; will forward to <forward-path> (See section 3.4) 252 Cannot VRFY user, but will accept message and attempt delivery (See section 3.5.3) 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy) 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) 451 Requested action aborted: error in processing 551 User not local; please try <forward-path> (See section 3.4) 452 Requested action not taken: insufficient system storage 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect) 354 Start mail input; end with <CRLF>.<CRLF> 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here")
250请求邮件操作正常，完成251个用户非本地；将转发到<forward path>（参见第3.4节）252无法接收用户，但将接受邮件并尝试传递（参见第3.5.3节）450请求的邮件操作未执行：邮箱不可用（例如，邮箱忙）550请求的操作未执行：邮箱不可用（例如，未找到邮箱，没有访问权限，或由于策略原因拒绝命令）451请求的操作中止：处理551用户非本地时出错；请尝试<forward path>（参见第3.4节）452请求的操作未采取：系统存储不足552请求的邮件操作中止：超出存储分配553请求的操作未采取：不允许邮箱名称（例如，邮箱语法不正确）354启动邮件输入；以<CRLF>结束<CRLF>554事务失败（或者，在连接打开响应的情况下，“此处没有SMTP服务”）
211 System status, or system help reply 214 Help message (Information on how to use the receiver or the meaning of a particular non-standard command; this reply is useful only to the human user) 220 <domain> Service ready 221 <domain> Service closing transmission channel 250 Requested mail action okay, completed 251 User not local; will forward to <forward-path> (See section 3.4) 252 Cannot VRFY user, but will accept message and attempt delivery (See section 3.5.3)
211系统状态，或系统帮助回复214帮助消息（关于如何使用接收器或特定非标准命令含义的信息；此回复仅对人类用户有用）220<domain>服务就绪221<domain>服务关闭传输通道250请求的邮件操作正常，已完成251个用户非本地；将转发至<forward path>（参见第3.4节）252无法对用户进行VRFY，但将接受消息并尝试传递（参见第3.5.3节）
354 Start mail input; end with <CRLF>.<CRLF>
354 Start mail input; end with <CRLF>.<CRLF>
421 <domain> Service not available, closing transmission channel (This may be a reply to any command if the service knows it must shut down) 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy) 451 Requested action aborted: local error in processing 452 Requested action not taken: insufficient system storage 500 Syntax error, command unrecognized (This may include errors such as command line too long) 501 Syntax error in parameters or arguments 502 Command not implemented (see section 4.2.4) 503 Bad sequence of commands 504 Command parameter not implemented 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) 551 User not local; please try <forward-path> (See section 3.4) 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect) 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here")
421<domain>服务不可用，关闭传输通道（如果服务知道必须关闭，这可能是对任何命令的答复）450未采取请求的邮件操作：邮箱不可用（例如，邮箱忙）451请求的操作中止：处理452请求的操作时发生本地错误未采取：系统存储不足500语法错误，无法识别命令（这可能包括命令行过长等错误）501参数或参数中的语法错误502未执行命令（参见第4.2.4节）503命令顺序错误504未执行命令参数550未采取请求的操作：邮箱不可用（例如，未找到邮箱、无法访问或因策略原因拒绝命令）551用户非本地；请尝试<forward path>（请参阅第3.4节）552请求的邮件操作中止：超出存储分配553请求的操作未采取：不允许邮箱名称（例如，邮箱语法不正确）554事务失败（或者，在连接打开响应的情况下，“此处无SMTP服务”）
Questions have been raised as to when reply code 502 (Command not implemented) SHOULD be returned in preference to other codes. 502 SHOULD be used when the command is actually recognized by the SMTP server, but not implemented. If the command is not recognized, code 500 SHOULD be returned. Extended SMTP systems MUST NOT list capabilities in response to EHLO for which they will return 502 (or 500) replies.
有人提出，何时应优先返回应答代码502（未执行命令），而不是其他代码。当SMTP服务器实际识别该命令但未实现时，应使用502。如果无法识别该命令，则应返回代码500。扩展SMTP系统不得列出响应EHLO的功能，因为它们将返回502（或500）个回复。
When an SMTP server returns a positive completion status (2yz code) after the DATA command is completed with <CRLF>.<CRLF>, it accepts responsibility for:
当SMTP服务器在数据命令使用<CRLF><CRLF>完成后返回肯定完成状态（2yz代码）时，它将承担以下责任：
- delivering the message (if the recipient mailbox exists), or
- 传递邮件（如果收件人邮箱存在），或
- if attempts to deliver the message fail due to transient conditions, retrying delivery some reasonable number of times at intervals as specified in section 4.5.4.
- 如果由于瞬态条件，尝试传递消息失败，则按照第4.5.4节规定的时间间隔，重新尝试传递消息的次数应合理。
- if attempts to deliver the message fail due to permanent conditions, or if repeated attempts to deliver the message fail due to transient conditions, returning appropriate notification to the sender of the original message (using the address in the SMTP MAIL command).
- 如果尝试传递邮件因永久性条件而失败，或者多次尝试传递邮件因暂时性条件而失败，则向原始邮件的发件人返回适当的通知（使用SMTP MAIL命令中的地址）。
When an SMTP server returns a permanent error status (5yz) code after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver that message. The SMTP client retains responsibility for delivery of that message and may either return it to the user or requeue it for a subsequent attempt (see section 4.5.4.1).
当SMTP服务器在数据命令使用<CRLF><CRLF>完成后返回永久错误状态（5yz）代码时，它不得再尝试传递该消息。SMTP客户端保留传递该邮件的责任，可以将其返回给用户，也可以在后续尝试中重新获取该邮件（参见第4.5.4.1节）。
The user who originated the message SHOULD be able to interpret the return of a transient failure status (by mail message or otherwise) as a non-delivery indication, just as a permanent failure would be interpreted. I.e., if the client SMTP successfully handles these conditions, the user will not receive such a reply.
发出消息的用户应该能够将暂时故障状态（通过邮件或其他方式）的返回解释为未送达指示，就像永久故障被解释一样。即，如果客户端SMTP成功处理这些条件，用户将不会收到此类回复。
When an SMTP server returns a permanent error status (5yz) code after the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver the message. As with temporary error status codes, the SMTP client retains responsibility for the message, but SHOULD not again attempt delivery to the same server without user review and intervention of the message.
当SMTP服务器在数据命令完全使用<CRLF><CRLF>后返回永久错误状态（5yz）代码时，它不得再尝试传递邮件。与临时错误状态代码一样，SMTP客户端保留对邮件的责任，但在没有用户审阅和干预邮件的情况下，不应再次尝试传递到同一服务器。
The communication between the sender and receiver is an alternating dialogue, controlled by the sender. As such, the sender issues a command and the receiver responds with a reply. Unless other arrangements are negotiated through service extensions, the sender MUST wait for this response before sending further commands.
发送方和接收方之间的通信是由发送方控制的交替对话。因此，发送方发出命令，接收方回复。除非通过服务扩展协商其他安排，否则发送方在发送进一步命令之前必须等待此响应。
One important reply is the connection greeting. Normally, a receiver will send a 220 "Service ready" reply when the connection is completed. The sender SHOULD wait for this greeting message before sending any commands.
一个重要的回答是连接问候语。通常，当连接完成时，接收器将发送220“服务就绪”回复。在发送任何命令之前，发件人应等待此问候消息。
Note: all the greeting-type replies have the official name (the fully-qualified primary domain name) of the server host as the first word following the reply code. Sometimes the host will have no meaningful name. See 4.1.3 for a discussion of alternatives in these situations.
注意：所有问候语类型的回复都以服务器主机的正式名称（完全限定的主域名）作为回复代码后的第一个单词。有时主机将没有有意义的名称。关于这些情况下备选方案的讨论，见4.1.3。
For example,
例如
220 ISIF.USC.EDU Service ready or 220 mail.foo.com SuperSMTP v 6.1.2 Service ready or 220 [10.0.0.1] Clueless host service ready
220 ISIF.USC.EDU服务就绪或220 mail.foo.com SuperSMTP v 6.1.2服务就绪或220[10.0.0.1]无提示主机服务就绪
The table below lists alternative success and failure replies for each command. These SHOULD be strictly adhered to: a receiver may substitute text in the replies, but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered.
下表列出了每个命令的备选成功和失败回复。应严格遵守这些规定：接收者可以在回复中替换文本，但代码编号和特定命令回复顺序所暗示的含义和行为不得更改。
Each command is listed with its usual possible replies. The prefixes used before the possible replies are "I" for intermediate, "S" for success, and "E" for error. Since some servers may generate other replies under special circumstances, and to allow for future extension, SMTP clients SHOULD, when possible, interpret only the first digit of the reply and MUST be prepared to deal with unrecognized reply codes by interpreting the first digit only. Unless extended using the mechanisms described in section 2.2, SMTP servers MUST NOT transmit reply codes to an SMTP client that are other than three digits or that do not start in a digit between 2 and 5 inclusive.
每个命令都列出了它通常可能的回复。在可能的回复之前使用的前缀是“I”表示中间，“S”表示成功，“E”表示错误。由于某些服务器可能在特殊情况下生成其他回复，并且为了允许将来扩展，SMTP客户端应尽可能仅解释回复的第一位数字，并且必须准备好通过仅解释第一位数字来处理无法识别的回复代码。除非使用第2.2节中所述的机制进行扩展，否则SMTP服务器不得向SMTP客户端发送三位数以外的回复代码，或不以2到5（含2和5）之间的数字开头的回复代码。
These sequencing rules and, in principle, the codes themselves, can be extended or modified by SMTP extensions offered by the server and accepted (requested) by the client.
这些排序规则以及原则上的代码本身可以通过服务器提供的SMTP扩展进行扩展或修改，并由客户端接受（请求）。
In addition to the codes listed below, any SMTP command can return any of the following codes if the corresponding unusual circumstances are encountered:
除了下面列出的代码外，如果遇到相应的异常情况，任何SMTP命令都可以返回以下任意代码：
500 For the "command line too long" case or if the command name was not recognized. Note that producing a "command not recognized" error in response to the required subset of these commands is a violation of this specification.
500表示“命令行过长”或无法识别命令名。请注意，响应这些命令的所需子集而产生“未识别命令”错误违反了本规范。
501 Syntax error in command or arguments. In order to provide for future extensions, commands that are specified in this document as not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 message if arguments are supplied in the absence of EHLO-advertised extensions.
501命令或参数中存在语法错误。为了提供将来的扩展，如果在没有EHLO播发扩展的情况下提供参数，则本文档中指定为不接受参数（DATA、RSET、QUIT）的命令应返回501消息。
421 Service shutting down and closing transmission channel
421服务关闭和关闭传输通道
Specific sequences are:
具体顺序如下：
CONNECTION ESTABLISHMENT
S: 220
E: 554
EHLO or HELO
S: 250
E: 504, 550
MAIL
S: 250
E: 552, 451, 452, 550, 553, 503
RCPT
S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
E: 550, 551, 552, 553, 450, 451, 452, 503, 550
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
RSET
S: 250
VRFY
S: 250, 251, 252
E: 550, 551, 553, 502, 504
EXPN
S: 250, 252
E: 550, 500, 502, 504
HELP
S: 211, 214
E: 502, 504
NOOP
S: 250
QUIT
S: 221
CONNECTION ESTABLISHMENT
S: 220
E: 554
EHLO or HELO
S: 250
E: 504, 550
MAIL
S: 250
E: 552, 451, 452, 550, 553, 503
RCPT
S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
E: 550, 551, 552, 553, 450, 451, 452, 503, 550
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
RSET
S: 250
VRFY
S: 250, 251, 252
E: 550, 551, 553, 502, 504
EXPN
S: 250, 252
E: 550, 500, 502, 504
HELP
S: 211, 214
E: 502, 504
NOOP
S: 250
QUIT
S: 221
When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content, as discussed in section 4.1.1.4.
当SMTP服务器收到要传递或进一步处理的邮件时，它必须在邮件内容的开头插入跟踪（“时间戳”或“已接收”）信息，如第4.1.1.4节所述。
This line MUST be structured as follows:
该行的结构必须如下所示：
- The FROM field, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.
- 必须在SMTP环境中提供的“发件人”字段应包含（1）EHLO命令中显示的源主机名称和（2）包含源IP地址的地址文字（由TCP连接确定）。
- The ID field MAY contain an "@" as suggested in RFC 822, but this is not required.
- ID字段可能包含RFC 822中建议的“@”，但这不是必需的。
- The FOR field MAY contain a list of <path> entries when multiple RCPT commands have been given. This may raise some security issues and is usually not desirable; see section 7.2.
- 当发出多个RCPT命令时，“FOR”字段可能包含<path>项列表。这可能会引起一些安全问题，通常是不可取的；见第7.2节。
An Internet mail program MUST NOT change a Received: line that was previously added to the message header. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location.
Internet邮件程序不得更改以前添加到邮件标题的Received:行。SMTP服务器必须将收到的行前置到邮件；他们不得更改现有行的顺序或在任何其他位置插入收到的行。
As the Internet grows, comparability of Received fields is important for detecting problems, especially slow relays. SMTP servers that create Received fields SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names of any type. Local time (with an offset) is preferred to UT when feasible. This formulation allows slightly more information about local circumstances to be specified. If UT is needed, the receiver need merely do some simple arithmetic to convert the values. Use of UT loses information about the time zone-location of the server. If it is desired to supply a time zone name, it SHOULD be included in a comment.
随着互联网的发展，接收场的可比性对于检测问题非常重要，尤其是低速继电器。创建接收字段的SMTP服务器应在日期（例如-0800）中使用显式偏移量，而不是任何类型的时区名称。可行时，本地时间（带偏移）优先于UT。该公式允许对当地情况提供更多的信息。如果需要UT，接收器只需要做一些简单的算术来转换值。使用UT会丢失有关服务器时区位置的信息。如果需要提供时区名称，则应将其包含在注释中。
When the delivery SMTP server makes the "final delivery" of a message, it inserts a return-path line at the beginning of the mail data. This use of return-path is required; mail systems MUST support it. The return-path line preserves the information in the <reverse-path> from the MAIL command. Here, final delivery means the message has left the SMTP environment. Normally, this would mean it had been delivered to the destination user or an associated mail drop, but in some cases it may be further processed and transmitted by another mail system.
当传递SMTP服务器对邮件进行“最终传递”时，它会在邮件数据的开头插入一个返回路径行。这种返回路径的使用是必需的；邮件系统必须支持它。返回路径行保留邮件命令的<reverse path>中的信息。在这里，最终传递意味着邮件已离开SMTP环境。通常情况下，这意味着它已被交付给目标用户或相关的邮件投递，但在某些情况下，它可能会被另一个邮件系统进一步处理和传输。
It is possible for the mailbox in the return path to be different from the actual sender's mailbox, for example, if error responses are to be delivered to a special error handling mailbox rather than to the message sender. When mailing lists are involved, this arrangement is common and useful as a means of directing errors to the list maintainer rather than the message originator.
返回路径中的邮箱可能与实际发件人的邮箱不同，例如，如果要将错误响应传递到特殊的错误处理邮箱，而不是邮件发件人。当涉及邮件列表时，这种安排是常见的，并且作为一种将错误定向给列表维护者而不是消息发起人的方法是有用的。
The text above implies that the final mail data will begin with a return path line, followed by one or more time stamp lines. These lines will be followed by the mail data headers and body [32].
上面的文本意味着最终邮件数据将以返回路径行开始，后跟一个或多个时间戳行。这些行后面是邮件数据头和正文[32]。
It is sometimes difficult for an SMTP server to determine whether or not it is making final delivery since forwarding or other operations may occur after the message is accepted for delivery. Consequently,
SMTP服务器有时很难确定是否正在进行最终传递，因为转发或其他操作可能发生在邮件被接受传递之后。因此
any further (forwarding, gateway, or relay) systems MAY remove the return path and rebuild the MAIL command as needed to ensure that exactly one such line appears in a delivered message.
任何其他（转发、网关或中继）系统都可以根据需要删除返回路径并重新生成邮件命令，以确保在传递的邮件中仅显示一行。
A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header. SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path headers are present. SMTP servers making final delivery MAY remove Return-path headers before adding their own.
发起SMTP系统的邮件不应发送已包含返回路径标头的邮件。执行中继功能的SMTP服务器不得检查邮件数据，尤其是在确定是否存在返回路径头所需的范围内。进行最终传递的SMTP服务器可能会在添加自己的返回路径头之前删除返回路径头。
The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered. Systems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent.
返回路径的主要目的是指定指示未送达或其他邮件系统故障的消息要发送到的地址。为了明确这一点，在传递消息时应该正好有一条返回路径。使用RFC 822语法和非SMTP传输的系统应指定一个与传输信封关联的明确地址，错误报告（例如，未送达消息）应发送到该地址。
Historical note: Text in RFC 822 that appears to contradict the use of the Return-path header (or the envelope reverse path address from the MAIL command) as the destination for error messages is not applicable on the Internet. The reverse path address (as copied into the Return-path) MUST be used as the target of any mail containing delivery error messages.
历史注释：RFC 822中的文本似乎与使用返回路径头（或邮件命令中的信封反向路径地址）作为错误消息的目的地相矛盾，但不适用于Internet。反向路径地址（复制到返回路径中）必须用作包含传递错误消息的任何邮件的目标。
In particular:
特别地：
- a gateway from SMTP->elsewhere SHOULD insert a return-path header, unless it is known that the "elsewhere" transport also uses Internet domain addresses and maintains the envelope sender address separately.
- SMTP->别处的网关应插入返回路径头，除非已知“别处”传输也使用Internet域地址并单独维护信封发件人地址。
- a gateway from elsewhere->SMTP SHOULD delete any return-path header present in the message, and either copy that information to the SMTP envelope or combine it with information present in the envelope of the other transport system to construct the reverse path argument to the MAIL command in the SMTP envelope.
- 来自别处的网关->SMTP应删除邮件中存在的任何返回路径标头，并将该信息复制到SMTP信封中，或将其与其他传输系统信封中存在的信息组合，以构造SMTP信封中邮件命令的反向路径参数。
The server must give special treatment to cases in which the processing following the end of mail data indication is only partially successful. This could happen if, after accepting several recipients and the mail data, the SMTP server finds that the mail data could be successfully delivered to some, but not all, of the recipients. In such cases, the response to the DATA command MUST be an OK reply. However, the SMTP server MUST compose and send an "undeliverable mail" notification message to the originator of the message.
对于邮件结束数据指示后的处理仅部分成功的情况，服务器必须给予特殊处理。如果在接受多个收件人和邮件数据后，SMTP服务器发现邮件数据可以成功传递给某些收件人，但不是全部收件人，则可能发生这种情况。在这种情况下，对DATA命令的响应必须是OK应答。但是，SMTP服务器必须编写并向邮件的原始发件人发送“无法送达邮件”通知邮件。
A single notification listing all of the failed recipients or separate notification messages MUST be sent for each failed recipient. For economy of processing by the sender, the former is preferred when possible. All undeliverable mail notification messages are sent using the MAIL command (even if they result from processing the obsolete SEND, SOML, or SAML commands) and use a null return path as discussed in section 3.7.
必须为每个失败的收件人发送列出所有失败收件人的单个通知或单独的通知消息。为了节省发送方的处理成本，在可能的情况下首选前者。所有无法投递的邮件通知消息都使用mail命令发送（即使它们是处理过时的SEND、SOML或SAML命令的结果），并使用第3.7节中讨论的空返回路径。
The time stamp line and the return path line are formally defined as follows:
时间戳线和返回路径线的正式定义如下：
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info ";" FWS date-time
戳记=从域到域选项信息“；“FWS日期时间”
; where "date-time" is as defined in [32]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
; where "date-time" is as defined in [32]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
From-domain = "FROM" FWS Extended-Domain CFWS
From domain=“From”FWS扩展域CFWS
By-domain = "BY" FWS Extended-Domain CFWS
按域=“按”FWS扩展域CFWS
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( Address-literal FWS "(" TCP-info ")" )
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( Address-literal FWS "(" TCP-info ")" )
TCP-info = Address-literal / ( Domain FWS Address-literal ) ; Information derived by server from TCP connection ; not client EHLO.
TCP信息=地址文字/（域FWS地址文字）；服务器从TCP连接导出的信息；不是客户EHLO。
Opt-info = [Via] [With] [ID] [For]
Opt-info = [Via] [With] [ID] [For]
Via = "VIA" FWS Link CFWS
Via=“Via”FWS链接CFWS
With = "WITH" FWS Protocol CFWS
With=“With”FWS协议CFWS
ID = "ID" FWS String / msg-id CFWS
ID=“ID”FWS字符串/msg ID CFWS
For = "FOR" FWS 1*( Path / Mailbox ) CFWS
For = "FOR" FWS 1*( Path / Mailbox ) CFWS
Link = "TCP" / Addtl-Link
Addtl-Link = Atom
; Additional standard names for links are registered with the
; Internet Assigned Numbers Authority (IANA). "Via" is
; primarily of value with non-Internet transports. SMTP
Link = "TCP" / Addtl-Link
Addtl-Link = Atom
; Additional standard names for links are registered with the
; Internet Assigned Numbers Authority (IANA). "Via" is
; primarily of value with non-Internet transports. SMTP
; servers SHOULD NOT use unregistered names.
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are registered with the
; Internet Assigned Numbers Authority (IANA). SMTP servers
; SHOULD NOT use unregistered names.
; servers SHOULD NOT use unregistered names.
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are registered with the
; Internet Assigned Numbers Authority (IANA). SMTP servers
; SHOULD NOT use unregistered names.
In order to make SMTP workable, the following minimum implementation is required for all receivers. The following commands MUST be supported to conform to this specification:
为了使SMTP可行，所有接收器都需要以下最低限度的实现。必须支持以下命令才能符合本规范：
EHLO HELO MAIL RCPT DATA RSET NOOP QUIT VRFY
EHLO直升机邮件RCPT数据RSET NOOP退出VRFY
Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case-insensitive local name. This postmaster address is not strictly necessary if the server always returns 554 on connection opening (as described in section 3.1). The requirement to accept mail for postmaster implies that RCPT commands which specify a mailbox for postmaster at any of the domains for which the SMTP server provides mail service, as well as the special case of "RCPT TO:<Postmaster>" (with no domain specification), MUST be supported.
任何包含支持邮件中继或传递的SMTP服务器的系统都必须支持保留邮箱“postmaster”作为不区分大小写的本地名称。如果服务器总是在连接打开时返回554（如第3.1节所述），则此邮局主管地址并非绝对必要。邮局主管接受邮件的要求意味着必须支持在SMTP服务器提供邮件服务的任何域中为邮局主管指定邮箱的RCPT命令，以及“RCPT to:<postmaster>（无域规范）的特例。
SMTP systems are expected to make every reasonable effort to accept mail directed to Postmaster from any other system on the Internet. In extreme cases --such as to contain a denial of service attack or other breach of security-- an SMTP server may block mail directed to Postmaster. However, such arrangements SHOULD be narrowly tailored so as to avoid blocking messages which are not part of such attacks.
SMTP系统应尽一切合理的努力接受从互联网上任何其他系统发送给邮政局长的邮件。在极端情况下（例如包含拒绝服务攻击或其他安全漏洞），SMTP服务器可能会阻止指向邮局主管的邮件。然而，此类安排应进行严格调整，以避免阻止不属于此类攻击的消息。
Without some provision for data transparency, the character sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. In general, users are not aware of such "forbidden" sequences. To
如果不提供数据透明度，字符序列“<CRLF><CRLF>”将结束邮件文本，用户无法发送。一般来说，用户不知道这样的“禁止”序列。到
allow all user composed text to be transmitted transparently, the following procedures are used:
允许透明传输所有用户编写的文本，使用以下步骤：
- Before sending a line of mail text, the SMTP client checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line.
- 在发送一行邮件文本之前，SMTP客户端将检查该行的第一个字符。如果是句点，则在行首插入一个额外的句点。
- When a line of mail text is received by the SMTP server, it checks the line. If the line is composed of a single period, it is treated as the end of mail indicator. If the first character is a period and there are other characters on the line, the first character is deleted.
- 当SMTP服务器收到一行邮件文本时，它会检查该行。如果行由单个时段组成，则将其视为邮件结束指示器。如果第一个字符是句点，并且行中还有其他字符，则删除第一个字符。
The mail data may contain any of the 128 ASCII characters. All characters are to be delivered to the recipient's mailbox, including spaces, vertical and horizontal tabs, and other control characters. If the transmission channel provides an 8-bit byte (octet) data stream, the 7-bit ASCII codes are transmitted right justified in the octets, with the high order bits cleared to zero. See 3.7 for special treatment of these conditions in SMTP systems serving a relay function.
邮件数据可以包含128个ASCII字符中的任意一个。所有字符都将发送到收件人的邮箱，包括空格、垂直和水平制表符以及其他控制字符。如果传输通道提供8位字节（八位字节）数据流，则在八位字节中传输7位ASCII码，高阶位清除为零。有关服务于中继功能的SMTP系统中这些条件的特殊处理，请参见3.7。
In some systems it may be necessary to transform the data as it is received and stored. This may be necessary for hosts that use a different character set than ASCII as their local character set, that store data in records rather than strings, or which use special character sequences as delimiters inside mailboxes. If such transformations are necessary, they MUST be reversible, especially if they are applied to mail being relayed.
在某些系统中，可能需要在接收和存储数据时对其进行转换。对于使用不同于ASCII的字符集作为本地字符集的主机、将数据存储在记录中而不是字符串中的主机，或者在邮箱中使用特殊字符序列作为分隔符的主机，这可能是必需的。如果这种转换是必要的，那么它们必须是可逆的，特别是当它们应用于正在中继的邮件时。
There are several objects that have required minimum/maximum sizes. Every implementation MUST be able to receive objects of at least these sizes. Objects larger than these sizes SHOULD be avoided when possible. However, some Internet mail constructs such as encoded X.400 addresses [16] will often require larger objects: clients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they cannot be handled by it. To the maximum extent possible, implementation techniques which impose no limits on the length of these objects should be used.
有多个对象具有所需的最小/最大尺寸。每个实现必须能够接收至少这些大小的对象。如果可能，应避免使用大于这些尺寸的物体。但是，一些Internet邮件结构（如编码的X.400地址[16]）通常需要更大的对象：客户机可能会尝试传输这些对象，但如果服务器无法处理这些对象，则必须为服务器拒绝它们做好准备。应尽最大可能使用对这些对象的长度没有限制的实现技术。
local-part The maximum total length of a user name or other local-part is 64 characters.
本地部分用户名或其他本地部分的最大总长度为64个字符。
domain The maximum total length of a domain name or number is 255 characters.
域域名或数字的最大总长度为255个字符。
path The maximum total length of a reverse-path or forward-path is 256 characters (including the punctuation and element separators).
路径反向路径或正向路径的最大总长度为256个字符（包括标点符号和元素分隔符）。
command line The maximum total length of a command line including the command word and the <CRLF> is 512 characters. SMTP extensions may be used to increase this limit.
命令行包括命令字和<CRLF>的命令行的最大总长度为512个字符。SMTP扩展可用于增加此限制。
reply line The maximum total length of a reply line including the reply code and the <CRLF> is 512 characters. More information may be conveyed through multiple-line replies.
回复行包括回复代码和<CRLF>的回复行的最大总长度为512个字符。更多信息可通过多行回复传达。
text line The maximum total length of a text line including the <CRLF> is 1000 characters (not counting the leading dot duplicated for transparency). This number may be increased by the use of SMTP Service Extensions.
文本行包含<CRLF>的文本行的最大总长度为1000个字符（不包括为透明而复制的前导点）。此数字可能会因使用SMTP服务扩展而增加。
message content The maximum total length of a message content (including any message headers as well as the message body) MUST BE at least 64K octets. Since the introduction of Internet standards for multimedia mail [12], message lengths on the Internet have grown dramatically, and message size restrictions should be avoided if at all possible. SMTP server systems that must impose restrictions SHOULD implement the "SIZE" service extension [18], and SMTP client systems that will send large messages SHOULD utilize it when possible.
消息内容消息内容（包括任何消息头和消息正文）的最大总长度必须至少为64K个八位字节。自从多媒体邮件采用互联网标准[12]以来，互联网上的邮件长度急剧增长，如果可能的话，应该避免邮件大小限制。必须施加限制的SMTP服务器系统应实现“大小”服务扩展[18]，发送大型邮件的SMTP客户端系统应尽可能使用该扩展。
recipients buffer The minimum total number of recipients that must be buffered is 100 recipients. Rejection of messages (for excessive recipients) with fewer than 100 RCPT commands is a violation of this specification. The general principle that relaying SMTP servers MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation tests on message headers suggests that rejecting a message based on the total number of recipients shown in header fields is to be discouraged. A server which imposes a limit on the number of recipients MUST behave in an orderly fashion, such as to reject additional addresses over its limit rather than silently discarding addresses previously accepted. A client that needs to
recipients buffer必须缓冲的收件人的最小总数为100个。拒绝使用少于100个RCPT命令的邮件（对于过多的收件人）违反了本规范。中继SMTP服务器不得对邮件标题执行验证测试，而传递SMTP服务器不应对邮件标题执行验证测试的一般原则表明，不鼓励基于标题字段中显示的收件人总数拒绝邮件。对收件人数量施加限制的服务器必须以有序的方式运行，例如拒绝超过其限制的其他地址，而不是默默地丢弃以前接受的地址。一个需要
deliver a message containing over 100 RCPT commands SHOULD be prepared to transmit in 100-recipient "chunks" if the server declines to accept more than 100 recipients in a single message.
如果服务器拒绝在一封邮件中接收100多个收件人，则应准备发送包含100多个RCPT命令的邮件，以便在100个收件人“块”中发送。
Errors due to exceeding these limits may be reported by using the reply codes. Some examples of reply codes are:
由于超过这些限制而导致的错误可通过使用回复代码进行报告。回复代码的一些示例如下：
500 Line too long. or 501 Path too long or 452 Too many recipients (see below) or 552 Too much mail data.
500行太长了。或者501路径太长，或者452个收件人太多（见下文），或者552个邮件数据太多。
RFC 821 [30] incorrectly listed the error where an SMTP server exhausts its implementation limit on the number of RCPT commands ("too many recipients") as having reply code 552. The correct reply code for this condition is 452. Clients SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure so the logic below works.
RFC 821[30]错误地将SMTP服务器耗尽其对RCPT命令数量的实现限制（“收件人太多”）的错误列为回复代码552。此条件的正确回复代码为452。在这种情况下，客户机应该将552代码视为临时故障，而不是永久故障，这样下面的逻辑就可以工作了。
When a conforming SMTP server encounters this condition, it has at least 100 successful RCPT commands in its recipients buffer. If the server is able to accept the message, then at least these 100 addresses will be removed from the SMTP client's queue. When the client attempts retransmission of those addresses which received 452 responses, at least 100 of these will be able to fit in the SMTP server's recipients buffer. Each retransmission attempt which is able to deliver anything will be able to dispose of at least 100 of these recipients.
当符合条件的SMTP服务器遇到此情况时，其收件人缓冲区中至少有100个成功的RCPT命令。如果服务器能够接受邮件，则至少会从SMTP客户端队列中删除这100个地址。当客户端尝试重新传输接收到452个响应的地址时，其中至少100个地址能够放入SMTP服务器的收件人缓冲区。每次能够传送任何内容的重传尝试将能够处理至少100个这样的接收者。
If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452 (but the client SHOULD also be prepared for a 552, as noted above). If the server has a configured site-policy limitation on the number of RCPT commands, it MAY instead use a 5XX response code. This would be most appropriate if the policy limitation was intended to apply if the total recipient count for a particular message body were enforced even if that message body was sent in multiple mail transactions.
如果SMTP服务器对RCPT命令的数量有实现限制，并且该限制已用尽，则它必须使用452响应代码（但客户端还应准备552响应代码，如上所述）。如果服务器对RCPT命令的数量有配置的站点策略限制，则它可以改为使用5XX响应代码。如果某个特定邮件正文的收件人总数被强制执行（即使该邮件正文是在多个邮件事务中发送的），那么这将是最合适的策略限制。
An SMTP client MUST provide a timeout mechanism. It MUST use per-command timeouts rather than somehow trying to time the entire mail transaction. Timeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code. To implement this, a timer is set
SMTP客户端必须提供超时机制。它必须使用per命令超时，而不是试图对整个邮件事务计时。超时应该很容易重新配置，最好不用重新编译SMTP代码。要实现这一点，需要设置计时器
for each SMTP command and for each buffer of the data transfer. The latter means that the overall timeout is inherently proportional to the size of the message.
对于每个SMTP命令和数据传输的每个缓冲区。后者意味着总超时与消息的大小成正比。
Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:
根据繁忙邮件中继主机的丰富经验，每个命令的最小超时值应如下所示：
Initial 220 Message: 5 minutes An SMTP client process needs to distinguish between a failed TCP connection and a delay in receiving the initial 220 greeting message. Many SMTP servers accept a TCP connection but delay delivery of the 220 message until their system load permits more mail to be processed.
初始220消息：SMTP客户端进程需要在5分钟内区分TCP连接失败和接收初始220问候消息的延迟。许多SMTP服务器接受TCP连接，但延迟220邮件的传递，直到其系统负载允许处理更多邮件。
MAIL Command: 5 minutes
邮递命令：5分钟
RCPT Command: 5 minutes A longer timeout is required if processing of mailing lists and aliases is not deferred until after the message was accepted.
RCPT命令：如果邮件列表和别名的处理没有延迟到邮件被接受之后，则需要更长的超时5分钟。
DATA Initiation: 2 minutes This is while awaiting the "354 Start Input" reply to a DATA command.
数据启动：2分钟，等待数据命令的“354启动输入”回复。
Data Block: 3 minutes This is while awaiting the completion of each TCP SEND call transmitting a chunk of data.
数据块：3分钟，这是在等待每个TCP发送呼叫完成时发送的数据块。
DATA Termination: 10 minutes. This is while awaiting the "250 OK" reply. When the receiver gets the final period terminating the message data, it typically performs processing to deliver the message to a user mailbox. A spurious timeout at this point would be very wasteful and would typically result in delivery of multiple copies of the message, since it has been successfully sent and the server has accepted responsibility for delivery. See section 6.1 for additional discussion.
数据终止：10分钟。这是在等待“250 OK”回复时进行的。当接收方收到终止消息数据的最后一个时段时，它通常会执行处理以将消息传递到用户邮箱。此时的虚假超时将是非常浪费的，通常会导致邮件的多个副本的传递，因为邮件已成功发送，并且服务器已接受传递的责任。更多讨论见第6.1节。
An SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender.
SMTP服务器在等待发件人的下一个命令时应至少有5分钟的超时。
The common structure of a host SMTP implementation includes user mailboxes, one or more areas for queuing messages in transit, and one or more daemon processes for sending and receiving mail. The exact structure will vary depending on the needs of the users on the host
主机SMTP实现的常见结构包括用户邮箱、一个或多个用于对传输中的消息进行排队的区域，以及一个或多个用于发送和接收邮件的守护进程。具体结构将根据主机上用户的需要而有所不同
and the number and size of mailing lists supported by the host. We describe several optimizations that have proved helpful, particularly for mailers supporting high traffic levels.
以及主机支持的邮件列表的数量和大小。我们描述了一些被证明是有用的优化，特别是对于支持高流量级别的邮件。
Any queuing strategy MUST include timeouts on all activities on a per-command basis. A queuing strategy MUST NOT send error messages in response to error messages under any circumstances.
任何排队策略必须包括每个命令上所有活动的超时。在任何情况下，排队策略都不得发送错误消息以响应错误消息。
The general model for an SMTP client is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information.
SMTP客户端的一般模型是一个或多个进程，它们定期尝试传输传出邮件。在一个典型的系统中，编写消息的程序有一些方法来请求立即注意新的传出邮件，而不能立即发送的邮件必须排队，并由发送者定期重试。邮件队列条目不仅包括邮件本身，还包括信封信息。
The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery.
在一次尝试失败后，发送方必须延迟重试特定目标。通常，重试间隔应至少为30分钟；但是，当SMTP客户端可以确定未传递的原因时，更复杂和可变的策略将是有益的。
Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. The parameters to the retry algorithm MUST be configurable.
重试将继续，直到消息被传输或发送方放弃；放弃时间一般需要至少4-5天。重试算法的参数必须是可配置的。
A client SHOULD keep a list of hosts it cannot reach and corresponding connection timeouts, rather than just retrying queued mail items.
客户端应该保留一个它无法到达的主机列表和相应的连接超时，而不仅仅是重试排队的邮件项目。
Experience suggests that failures are typically transient (the target system or its connection has crashed), favoring a policy of two connection attempts in the first hour the message is in the queue, and then backing off to one every two or three hours.
经验表明，故障通常是暂时的（目标系统或其连接已崩溃），倾向于在消息进入队列的第一个小时内尝试两次连接，然后每两三个小时后退一次。
The SMTP client can shorten the queuing delay in cooperation with the SMTP server. For example, if mail is received from a particular address, it is likely that mail queued for that host can now be sent. Application of this principle may, in many cases, eliminate the requirement for an explicit "send queues now" function such as ETRN [9].
SMTP客户端可以与SMTP服务器协作缩短排队延迟。例如，如果从特定地址接收邮件，则很可能现在可以发送排队等待该主机的邮件。在许多情况下，应用此原则可以消除对显式“立即发送队列”功能（如ETRN）[9]的要求。
The strategy may be further modified as a result of multiple addresses per host (see below) to optimize delivery time vs. resource usage.
由于每个主机有多个地址（见下文），可以进一步修改该策略，以优化交付时间和资源使用。
An SMTP client may have a large queue of messages for each unavailable destination host. If all of these messages were retried in every retry cycle, there would be excessive Internet overhead and the sending system would be blocked for a long period. Note that an SMTP client can generally determine that a delivery attempt has failed only after a timeout of several minutes and even a one-minute timeout per connection will result in a very large delay if retries are repeated for dozens, or even hundreds, of queued messages to the same host.
对于每个不可用的目标主机，SMTP客户端可能有一个较大的消息队列。如果在每个重试周期中重试所有这些消息，则会产生过多的Internet开销，并且发送系统将被阻塞很长一段时间。请注意，SMTP客户端通常只能在超时几分钟后才能确定传递尝试失败，如果对同一主机重复几十次甚至数百次排队邮件重试，则即使每次连接超时一分钟也会导致非常大的延迟。
At the same time, SMTP clients SHOULD use great care in caching negative responses from servers. In an extreme case, if EHLO is issued multiple times during the same SMTP connection, different answers may be returned by the server. More significantly, 5yz responses to the MAIL command MUST NOT be cached.
同时，SMTP客户端在缓存来自服务器的负面响应时应该非常小心。在极端情况下，如果在同一SMTP连接期间多次发出EHLO，服务器可能会返回不同的答案。更重要的是，不能缓存对MAIL命令的5yz响应。
When a mail message is to be delivered to multiple recipients, and the SMTP server to which a copy of the message is to be sent is the same for multiple recipients, then only one copy of the message SHOULD be transmitted. That is, the SMTP client SHOULD use the command sequence: MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there are very many addresses, a limit on the number of RCPT commands per MAIL command MAY be imposed. Implementation of this efficiency feature is strongly encouraged.
当一封邮件要发送给多个收件人，并且邮件副本要发送到的SMTP服务器对于多个收件人是相同的，则只应发送一份邮件副本。也就是说，SMTP客户端应该使用命令序列：MAIL、RCPT、RCPT、，。。。RCPT，数据而不是顺序：邮件，RCPT，数据，…，邮件，RCPT，数据。但是，如果地址非常多，则可能会对每个邮件命令的RCPT命令数量施加限制。强烈鼓励实施这一高效功能。
Similarly, to achieve timely delivery, the SMTP client MAY support multiple concurrent outgoing mail transactions. However, some limit may be appropriate to protect the host from devoting all its resources to mail.
类似地，为了实现及时传递，SMTP客户端可能支持多个并发的传出邮件事务。但是，某些限制可能是适当的，以保护主机不将其所有资源用于邮件。
The SMTP server SHOULD attempt to keep a pending listen on the SMTP port at all times. This requires the support of multiple incoming TCP connections for SMTP. Some limit MAY be imposed but servers that cannot handle more than one SMTP transaction at a time are not in conformance with the intent of this specification.
SMTP服务器应始终尝试在SMTP端口上保留挂起的侦听。这需要支持SMTP的多个传入TCP连接。可能会施加一些限制，但一次不能处理多个SMTP事务的服务器不符合本规范的意图。
As discussed above, when the SMTP server receives mail from a particular host address, it could activate its own SMTP queuing mechanisms to retry any mail pending for that host address.
如上所述，当SMTP服务器从特定主机地址接收邮件时，它可以激活自己的SMTP队列机制，以重试该主机地址的任何挂起邮件。
There are several types of notification messages which are required by existing and proposed standards to be sent with a null reverse path, namely non-delivery notifications as discussed in section 3.7,
现有和拟议标准要求使用空反向路径发送几种类型的通知消息，即第3.7节中讨论的未送达通知，
other kinds of Delivery Status Notifications (DSNs) [24], and also Message Disposition Notifications (MDNs) [10]. All of these kinds of messages are notifications about a previous message, and they are sent to the reverse-path of the previous mail message. (If the delivery of such a notification message fails, that usually indicates a problem with the mail system of the host to which the notification message is addressed. For this reason, at some hosts the MTA is set up to forward such failed notification messages to someone who is able to fix problems with the mail system, e.g., via the postmaster alias.)
其他类型的传递状态通知（DSN）[24]，以及消息处置通知（MDN）[10]。所有这些类型的邮件都是关于上一封邮件的通知，它们被发送到上一封邮件的反向路径。（如果此类通知邮件的传递失败，通常表明通知邮件所针对的主机的邮件系统存在问题。因此，在某些主机上，MTA被设置为将此类失败的通知邮件转发给能够解决邮件系统问题的人，例如通过邮政局长）别名。）
All other types of messages (i.e., any message which is not required by a standards-track RFC to have a null reverse-path) SHOULD be sent with with a valid, non-null reverse-path.
所有其他类型的消息（即，标准跟踪RFC不要求具有空反向路径的任何消息）应使用有效的非空反向路径发送。
Implementors of automated email processors should be careful to make sure that the various kinds of messages with null reverse-path are handled correctly, in particular such systems SHOULD NOT reply to messages with null reverse-path.
自动化电子邮件处理器的实现者应小心确保正确处理具有空反向路径的各种消息，尤其是此类系统不应回复具有空反向路径的消息。
Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup MUST be performed to resolve the domain name [22]. The names are expected to be fully-qualified domain names (FQDNs): mechanisms for inferring FQDNs from partial names or local aliases are outside of this specification and, due to a history of problems, are generally discouraged. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name. If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error.
一旦SMTP客户端在词汇上确定了要将邮件发送到哪个域进行处理（如第3.6节和第3.7节所述），则必须执行DNS查找以解析域名[22]。名称应为完全限定域名（FQDN）：从部分名称或本地别名推断FQDN的机制不在本规范范围内，并且由于存在问题的历史记录，通常不鼓励使用。查找首先尝试查找与该名称关联的MX记录。如果找到了CNAME记录，则结果名称的处理方式与初始名称相同。如果未找到MX记录，但找到了A RR，则A RR将被视为与隐式MX RR关联，首选项为0，指向该主机。如果为给定名称找到一个或多个MX RRs，SMTP系统不得使用与该名称关联的任何a RRs，除非它们使用MX RRs定位；仅当不存在MX记录时，上述“隐式MX”规则才适用。如果存在MX记录，但这些记录都不可用，则必须将此情况报告为错误。
When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the SMTP client SHOULD try at least two addresses.
当查找成功时，由于多个MX记录、多宿主或两者兼而有之，映射可能会产生一个替代传递地址列表，而不是一个地址。为了提供可靠的邮件传输，SMTP客户端必须能够按顺序尝试（并重试）此列表中的每个相关地址，直到传递尝试成功。但是，对可以尝试的备用地址的数量也可能有一个可配置的限制。在任何情况下，SMTP客户端都应尝试至少两个地址。
Two types of information is used to rank the host addresses: multiple MX records, and multihomed hosts.
有两种类型的信息用于对主机地址进行排序：多个MX记录和多主机。
Multiple MX records contain a preference indication that MUST be used in sorting (see below). Lower numbers are more preferred than higher ones. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily-reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization.
多个MX记录包含排序中必须使用的首选项指示（见下文）。较低的数字比较高的数字更受欢迎。如果有多个目的地具有相同的首选项，并且没有明确的理由支持一个目的地（例如，通过识别容易到达的地址），则发件人SMTP必须将其随机分配，以便将负载分散到特定组织的多个邮件交换器上。
The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and SMTP MUST try them in the order presented.
目标主机（可能取自首选MX记录）可能是多主机的，在这种情况下，域名解析程序将返回备选IP地址列表。域名解析程序接口有责任在必要时通过减少首选项对该列表进行排序，SMTP必须按照显示的顺序进行尝试。
Although the capability to try multiple alternative addresses is required, specific installations may want to limit or disable the use of alternative addresses. The question of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. The main argument for using the multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery; the counter-argument is that it may result in unnecessary resource use. Note that resource use is also strongly determined by the sending strategy discussed in section 4.5.4.1.
尽管需要尝试多个备用地址的功能，但特定安装可能希望限制或禁用备用地址的使用。发送方是否应该尝试使用多宿主主机的不同地址重试的问题一直存在争议。使用多个地址的主要理由是，它最大化了及时交付的概率，有时甚至是任何交付的概率；相反的论点是，它可能导致不必要的资源使用。注意，第4.5.4.1节中讨论的发送策略也强烈地决定了资源的使用。
If an SMTP server receives a message with a destination for which it is a designated Mail eXchanger, it MAY relay the message (potentially after having rewritten the MAIL FROM and/or RCPT TO addresses), make final delivery of the message, or hand it off using some mechanism outside the SMTP-provided transport environment. Of course, neither of the latter require that the list of MX records be examined further.
如果SMTP服务器接收到目的地为指定邮件交换器的邮件，它可能会中继邮件（可能是在将邮件从和/或RCPT重写到地址后），最终传递邮件，或使用SMTP提供的传输环境之外的某种机制将其转交。当然，后者都不要求进一步审查MX记录清单。
If it determines that it should relay the message without rewriting the address, it MUST sort the MX records to determine candidates for delivery. The records are first ordered by preference, with the lowest-numbered records being most preferred. The relay host MUST then inspect the list for any of the names or addresses by which it might be known in mail transactions. If a matching record is found, all records at that preference level and higher-numbered ones MUST be discarded from consideration. If there are no records left at that point, it is an error condition, and the message MUST be returned as undeliverable. If records do remain, they SHOULD be tried, best preference first, as described above.
如果它决定在不重写地址的情况下中继消息，则必须对MX记录进行排序，以确定要传递的候选项。这些记录首先按优先顺序排列，编号最低的记录是最优先的。然后，中继主机必须检查列表中的任何名称或地址，这些名称或地址在邮件事务中可能是已知的。如果找到匹配的记录，则必须放弃该首选项级别的所有记录以及编号更高的记录。如果此时没有留下任何记录，则这是一种错误情况，必须将消息作为无法传递返回。如前所述，如果记录确实保留下来，则应首先尝试使用最佳首选项。
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage.
当收件人SMTP接受一封邮件（通过发送“250 OK”消息以响应数据）时，它接受传递或转发该邮件的责任。它必须认真对待这一责任。它不能因为琐碎的原因丢失消息，例如主机稍后崩溃或可预测的资源短缺。
If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line). However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification. Obviously, nothing in this section can or should prohibit local decisions (i.e., as part of the same system environment as the receiver-SMTP) to log or otherwise transmit information about null address events locally if that is desired. If the address is an explicit source route, it MUST be stripped down to its final hop.
如果在接受邮件后出现传递失败，则收件人SMTP必须制定并邮寄通知邮件。必须使用信封中的空（<>）反向路径发送此通知。此通知的收件人必须是信封返回路径（或返回路径：行）中的地址。但是，如果此地址为空（“<>”），则收件人SMTP不得发送通知。显然，本节中的任何内容都不能也不应该禁止本地决定（即，作为与接收方SMTP相同的系统环境的一部分）在本地记录或以其他方式传输有关空地址事件的信息（如果需要）。如果地址是显式源路由，则必须将其剥离到最后一个跃点。
For example, suppose that an error notification must be sent for a message that arrived with:
例如，假设必须为到达的消息发送错误通知：
MAIL FROM:<@a,@b:user@d>
MAIL FROM:<@a,@b:user@d>
The notification message MUST be sent using:
必须使用以下方式发送通知消息：
RCPT TO:<user@d>
RCPT TO:<user@d>
Some delivery failures after the message is accepted by SMTP will be unavoidable. For example, it may be impossible for the receiving SMTP server to validate all the delivery addresses in RCPT command(s) due to a "soft" domain system error, because the target is a mailing list (see earlier discussion of RCPT), or because the server is acting as a relay and has no immediate access to the delivering system.
SMTP接受邮件后，某些传递失败将不可避免。例如，由于“软”域系统错误，接收SMTP服务器可能无法验证RCPT命令中的所有传递地址，因为目标是邮件列表（请参阅前面的RCPT讨论），或者因为服务器充当中继，无法立即访问传递系统。
To avoid receiving duplicate messages as the result of timeouts, a receiver-SMTP MUST seek to minimize the time required to respond to the final <CRLF>.<CRLF> end of data indicator. See RFC 1047 [28] for a discussion of this problem.
为避免因超时而收到重复邮件，收件人SMTP必须尽量缩短响应最终<CRLF><CRLF>数据结束指示符所需的时间。有关此问题的讨论，请参见RFC 1047[28]。
Simple counting of the number of "Received:" headers in a message has proven to be an effective, although rarely optimal, method of detecting loops in mail systems. SMTP servers using this technique SHOULD use a large rejection threshold, normally at least 100 Received entries. Whatever mechanisms are used, servers MUST contain provisions for detecting and stopping trivial loops.
简单计算消息中“已接收：”头的数量已被证明是检测邮件系统中循环的一种有效方法，尽管很少是最佳方法。使用此技术的SMTP服务器应使用较大的拒绝阈值，通常至少有100个接收条目。无论使用何种机制，服务器都必须包含用于检测和停止琐碎循环的规定。
Unfortunately, variations, creative interpretations, and outright violations of Internet mail protocols do occur; some would suggest that they occur quite frequently. The debate as to whether a well-behaved SMTP receiver or relay should reject a malformed message, attempt to pass it on unchanged, or attempt to repair it to increase the odds of successful delivery (or subsequent reply) began almost with the dawn of structured network mail and shows no signs of abating. Advocates of rejection claim that attempted repairs are rarely completely adequate and that rejection of bad messages is the only way to get the offending software repaired. Advocates of "repair" or "deliver no matter what" argue that users prefer that mail go through it if at all possible and that there are significant market pressures in that direction. In practice, these market pressures may be more important to particular vendors than strict conformance to the standards, regardless of the preference of the actual developers.
不幸的是，变化、创造性的解释和对互联网邮件协议的公然违反确实发生了；有些人会说，它们经常发生。关于行为良好的SMTP接收者或中继是否应该拒绝格式错误的邮件、尝试原封不动地传递邮件，还是尝试修复邮件以增加成功传递（或后续回复）的几率的争论，几乎始于结构化网络邮件的出现，并且没有减弱的迹象。拒绝的拥护者声称，尝试的修复很少是完全足够的，拒绝坏消息是修复有问题软件的唯一方法。“修复”或“无论如何交付”的倡导者认为，如果可能的话，用户更喜欢邮件通过它，而且在这方面存在着巨大的市场压力。在实践中，这些市场压力对特定供应商来说可能比严格遵守标准更重要，而不管实际开发商的偏好如何。
The problems associated with ill-formed messages were exacerbated by the introduction of the split-UA mail reading protocols [3, 26, 5, 21]. These protocols have encouraged the use of SMTP as a posting protocol, and SMTP servers as relay systems for these client hosts (which are often only intermittently connected to the Internet). Historically, many of those client machines lacked some of the mechanisms and information assumed by SMTP (and indeed, by the mail format protocol [7]). Some could not keep adequate track of time; others had no concept of time zones; still others could not identify their own names or addresses; and, of course, none could satisfy the assumptions that underlay RFC 822's conception of authenticated addresses.
拆分UA邮件读取协议的引入加剧了与格式错误的邮件相关的问题[3、26、5、21]。这些协议鼓励使用SMTP作为发布协议，使用SMTP服务器作为这些客户端主机（通常只是间歇性连接到Internet）的中继系统。从历史上看，这些客户机中的许多都缺少SMTP（事实上，还有邮件格式协议[7]）假定的一些机制和信息。有些人没有足够的时间记录；其他人没有时区的概念；还有一些人无法确定自己的姓名或地址；当然，没有一个能够满足RFC 822认证地址概念的假设。
In response to these weak SMTP clients, many SMTP systems now complete messages that are delivered to them in incomplete or incorrect form. This strategy is generally considered appropriate when the server can identify or authenticate the client, and there are prior agreements between them. By contrast, there is at best great concern about fixes applied by a relay or delivery SMTP server that has little or no knowledge of the user or client machine.
为了响应这些较弱的SMTP客户端，许多SMTP系统现在以不完整或不正确的形式完成发送给它们的邮件。当服务器可以识别或验证客户机，并且客户机之间存在事先协议时，通常认为此策略是合适的。相比之下，对于中继或传递SMTP服务器应用的修复程序，充其量也有很大的担忧，因为这些服务器对用户或客户端计算机知之甚少或一无所知。
The following changes to a message being processed MAY be applied when necessary by an originating SMTP server, or one used as the target of SMTP as an initial posting protocol:
必要时，原始SMTP服务器或用作SMTP目标作为初始投递协议的服务器可以对正在处理的邮件应用以下更改：
- Addition of a message-id field when none appears
- 无显示时添加消息id字段
- Addition of a date, time or time zone when none appears
- 无显示时添加日期、时间或时区
- Correction of addresses to proper FQDN format
- 将地址更正为正确的FQDN格式
The less information the server has about the client, the less likely these changes are to be correct and the more caution and conservatism should be applied when considering whether or not to perform fixes and how. These changes MUST NOT be applied by an SMTP server that provides an intermediate relay function.
服务器关于客户端的信息越少，这些更改越不可能正确，在考虑是否执行修复以及如何执行修复时，应更加谨慎和保守。提供中间中继功能的SMTP服务器不得应用这些更改。
In all cases, properly-operating clients supplying correct information are preferred to corrections by the SMTP server. In all cases, documentation of actions performed by the servers (in trace fields and/or header comments) is strongly encouraged.
在所有情况下，提供正确信息的正确操作的客户端都比SMTP服务器的更正更可取。在所有情况下，强烈建议记录服务器执行的操作（在跟踪字段和/或标题注释中）。
SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else. Constructing such a message so that the "spoofed" behavior cannot be detected by an expert is somewhat more difficult, but not sufficiently so as to be a deterrent to someone who is determined and knowledgeable. Consequently, as knowledge of Internet mail increases, so does the knowledge that SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. Real mail security lies only in end-to-end methods involving the message bodies, such as those which use digital signatures (see [14] and, e.g., PGP [4] or S/MIME [31]).
SMTP邮件本质上是不安全的，因为即使是相当随意的用户也可以直接与接收和转发SMTP服务器进行协商，并创建邮件，从而欺骗天真的收件人相信他们来自其他地方。构建这样一条信息，使专家无法检测到“欺骗”行为有点困难，但还不足以对有决心和知识的人起到威慑作用。因此，随着互联网邮件知识的增加，SMTP邮件本身无法在传输级别进行身份验证或提供完整性检查的知识也会增加。真正的邮件安全性仅存在于涉及消息体的端到端方法中，例如使用数字签名的方法（参见[14]和，例如PGP[4]或S/MIME[31]）。
Various protocol extensions and configuration options that provide authentication at the transport level (e.g., from an SMTP client to an SMTP server) improve somewhat on the traditional situation described above. However, unless they are accompanied by careful handoffs of responsibility in a carefully-designed trust environment, they remain inherently weaker than end-to-end mechanisms which use digitally signed messages rather than depending on the integrity of the transport system.
在传输级别（例如，从SMTP客户端到SMTP服务器）提供身份验证的各种协议扩展和配置选项在一定程度上改善了上述传统情况。然而，除非在精心设计的信任环境中伴随着谨慎的责任移交，否则它们本质上比使用数字签名消息而不是依赖于传输系统完整性的端到端机制更弱。
Efforts to make it more difficult for users to set envelope return path and header "From" fields to point to valid addresses other than their own are largely misguided: they frustrate legitimate applications in which mail is sent by one user on behalf of another or in which error (or normal) replies should be directed to a special address. (Systems that provide convenient ways for users to alter these fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender fields within the message data can be generated sensibly.)
让用户更难设置信封返回路径和标题“发件人”字段以指向自己以外的有效地址的做法在很大程度上是错误的：它们阻碍了合法的应用程序，在这些应用程序中，邮件由一个用户代表另一个用户发送，或者错误（或正常）回复应指向一个特殊地址。（为用户提供方便的方式以每封邮件为基础更改这些字段的系统应尝试为用户建立主邮箱和永久邮箱地址，以便能够合理地生成邮件数据中的发件人字段。）
This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail.
本规范没有进一步解决与SMTP相关的身份验证问题，只是主张不要禁用有用的功能，以期为试图伪造邮件的无知用户提供少量保护。
Addresses that do not appear in the message headers may appear in the RCPT commands to an SMTP server for a number of reasons. The two most common involve the use of a mailing address as a "list exploder" (a single address that resolves into multiple addresses) and the appearance of "blind copies". Especially when more than one RCPT command is present, and in order to avoid defeating some of the purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the headers, either as part of trace headers or as informational or private-extension headers. Since this rule is often violated in practice, and cannot be enforced, sending SMTP systems that are aware of "bcc" use MAY find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command.
由于多种原因，邮件标题中未显示的地址可能会显示在发送给SMTP服务器的RCPT命令中。最常见的两种方法是使用邮寄地址作为“列表分解器”（一个地址分解为多个地址）和出现“盲拷贝”。特别是当存在多个RCPT命令时，为了避免违背这些机制的某些目的，SMTP客户端和服务器不应将完整的RCPT命令参数集复制到标头中，作为跟踪标头的一部分或作为信息性或专用扩展标头。由于此规则在实践中经常被违反，并且无法强制执行，因此发送知道“密件抄送”使用的SMTP系统可能会发现，将每个盲副本作为单独的邮件事务发送（仅包含一个RCPT命令）是有帮助的。
There is no inherent relationship between either "reverse" (from MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction ("envelope") and the addresses in the headers. Receiving systems SHOULD NOT attempt to deduce such relationships and use them to alter the headers of the message for delivery. The popular "Apparently-to" header is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used.
SMTP事务（“信封”）中的“反向”（来自邮件、SAML等命令）或“转发”（RCPT）地址与标头中的地址之间没有固有关系。接收系统不应试图推断此类关系，并使用它们来更改要传递的消息头。流行的“显然是”标题违反了这一原则，也是意外信息披露的常见来源，不应使用。
As discussed in section 3.5, individual sites may want to disable either or both of VRFY or EXPN for security reasons. As a corollary to the above, implementations that permit this MUST NOT appear to have verified addresses that are not, in fact, verified. If a site
如第3.5节所述，出于安全原因，各个站点可能希望禁用VRFY或EXPN中的一个或两个。作为上述的推论，允许这样做的实现不能看起来具有事实上未经验证的已验证地址。如果一个网站
disables these commands for security reasons, the SMTP server MUST return a 252 response, rather than a code that could be confused with successful or unsuccessful verification.
如果出于安全原因禁用这些命令，SMTP服务器必须返回252响应，而不是可能与验证成功或失败混淆的代码。
Returning a 250 reply code with the address listed in the VRFY command after having checked it only for syntax violates this rule. Of course, an implementation that "supports" VRFY by always returning 550 whether or not the address is valid is equally not in conformance.
在仅检查语法后返回一个地址为VRFY命令中列出的250回复代码违反了此规则。当然，无论地址是否有效，通过始终返回550来“支持”VRFY的实现也同样不一致。
Within the last few years, the contents of mailing lists have become popular as an address information source for so-called "spammers." The use of EXPN to "harvest" addresses has increased as list administrators have installed protections against inappropriate uses of the lists themselves. Implementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs. As authentication mechanisms are introduced into SMTP, some sites may choose to make EXPN available only to authenticated requestors.
在过去几年中，邮件列表的内容已成为所谓“垃圾邮件发送者”的地址信息源。由于列表管理员安装了防止不适当使用列表的保护装置，使用EXPN“获取”地址的情况有所增加。实现仍应提供对EXPN的支持，但站点应仔细评估权衡。由于SMTP中引入了身份验证机制，一些站点可能会选择仅对经过身份验证的请求者提供EXPN。
There has been an ongoing debate about the tradeoffs between the debugging advantages of announcing server type and version (and, sometimes, even server domain name) in the greeting response or in response to the HELP command and the disadvantages of exposing information that might be useful in a potential hostile attack. The utility of the debugging information is beyond doubt. Those who argue for making it available point out that it is far better to actually secure an SMTP server rather than hope that trying to conceal known vulnerabilities by hiding the server's precise identity will provide more protection. Sites are encouraged to evaluate the tradeoff with that issue in mind; implementations are strongly encouraged to minimally provide for making type and version information available in some way to other network hosts.
关于在问候响应或帮助命令响应中公布服务器类型和版本（有时甚至是服务器域名）的调试优势与暴露可能在潜在恶意攻击中有用的信息的劣势之间的权衡，一直存在争论。调试信息的效用是毋庸置疑的。那些主张让SMTP服务器可用的人指出，实际上保护SMTP服务器的安全要好得多，而不是希望通过隐藏服务器的确切身份来隐藏已知的漏洞能够提供更多的保护。鼓励各营业点在考虑该问题的情况下评估折衷方案；强烈建议实现尽可能少地提供类型和版本信息，以某种方式提供给其他网络主机。
In some circumstances, such as when mail originates from within a LAN whose hosts are not directly on the public Internet, trace ("Received") fields produced in conformance with this specification may disclose host names and similar information that would not normally be available. This ordinarily does not pose a problem, but sites with special concerns about name disclosure should be aware of it. Also, the optional FOR clause should be supplied with caution or not at all when multiple recipients are involved lest it inadvertently disclose the identities of "blind copy" recipients to others.
在某些情况下，例如当邮件来自主机不直接位于公共互联网上的LAN时，根据本规范生成的跟踪（“接收”）字段可能会披露主机名和通常不可用的类似信息。这通常不会造成问题，但对名称披露有特殊关注的网站应该意识到这一点。此外，当涉及多个收件人时，应谨慎提供或根本不提供可选FOR条款，以免无意中将“盲拷贝”收件人的身份泄露给其他人。
As discussed in section 3.4, use of the 251 or 551 reply codes to identify the replacement address associated with a mailbox may inadvertently disclose sensitive information. Sites that are concerned about those issues should ensure that they select and configure servers appropriately.
如第3.4节所述，使用251或551回复代码识别与邮箱相关的替换地址可能会无意中泄露敏感信息。关注这些问题的站点应确保适当地选择和配置服务器。
It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server. However, cooperation among sites and installations makes the Internet possible. If sites take excessive advantage of the right to reject traffic, the ubiquity of email availability (one of the strengths of the Internet) will be threatened; considerable care should be taken and balance maintained if a site decides to be selective about the traffic it will accept and process.
这是一个公认的原则，即SMTP服务器可以出于任何操作或技术原因拒绝接受邮件，而这些原因对提供服务器的站点来说是有意义的。然而，网站和设施之间的合作使互联网成为可能。如果网站过度利用拒绝流量的权利，电子邮件的普及（互联网的优势之一）将受到威胁；如果一个站点决定对其将接受和处理的流量进行选择，则应十分小心并保持平衡。
In recent years, use of the relay function through arbitrary sites has been used as part of hostile efforts to hide the actual origins of mail. Some sites have decided to limit the use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering. When mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL, or RCPT as appropriate.
近年来，通过任意站点使用中继功能已被用作敌对行动的一部分，以隐藏邮件的实际来源。一些站点决定将中继功能的使用限制在已知或可识别的源上，并且实现应提供执行此类过滤的能力。当邮件因这些或其他政策原因被拒绝时，应使用550代码来响应EHLO、mail或RCPT（视情况而定）。
IANA will maintain three registries in support of this specification. The first consists of SMTP service extensions with the associated keywords, and, as needed, parameters and verbs. As specified in section 2.2.2, no entry may be made in this registry that starts in an "X". Entries may be made only for service extensions (and associated keywords, parameters, or verbs) that are defined in standards-track or experimental RFCs specifically approved by the IESG for this purpose.
IANA将维护三个注册中心以支持本规范。第一个由SMTP服务扩展和相关关键字组成，根据需要还包括参数和动词。如第2.2.2节所述，不得在此注册表中输入以“X”开头的条目。仅可为IESG为此专门批准的标准跟踪或实验RFC中定义的服务扩展（以及相关关键字、参数或动词）输入条目。
The second registry consists of "tags" that identify forms of domain literals other than those for IPv4 addresses (specified in RFC 821 and in this document) and IPv6 addresses (specified in this document). Additional literal types require standardization before being used; none are anticipated at this time.
第二个注册表由“标记”组成，这些标记用于标识除IPv4地址（在RFC 821和本文档中指定）和IPv6地址（在本文档中指定）以外的域文本形式。其他文字类型在使用前需要标准化；目前预计不会有。
The third, established by RFC 821 and renewed by this specification, is a registry of link and protocol identifiers to be used with the "via" and "with" subclauses of the time stamp ("Received: header")
第三个由RFC 821建立并由本规范更新，是链路和协议标识符的注册表，将与时间戳（“接收：报头”）的“via”和“with”子类一起使用
described in section 4.4. Link and protocol identifiers in addition to those specified in this document may be registered only by standardization or by way of an RFC-documented, IESG-approved, Experimental protocol extension.
如第4.4节所述。除本文件中规定的标识符外，链路和协议标识符只能通过标准化或通过RFC记录、IESG批准的实验协议扩展进行注册。
[1] American National Standards Institute (formerly United States of America Standards Institute), X3.4, 1968, "USA Code for Information Interchange". ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
[1] 美国国家标准协会（前美国标准协会），X3.42068，“美国信息交换代码”。ANSI X3.4-1968已被稍作修改的较新版本所取代，但1968年版本仍然是互联网的最终版本。
[2] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[2] Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J. Reynolds, "Post Office Protocol - version 2", RFC 937, February 1985.
[3] Butler，M.，Chase，D.，Goldberger，J.，Postel，J.和J.Reynolds，“邮局协议-第2版”，RFC 937，1985年2月。
[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[4] Callas，J.，Donnerhacke，L.，Finney，H.和R.Thayer，“OpenPGP消息格式”，RFC2440，1998年11月。
[5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, August 1990.
[5] Crispin，M.，“交互式邮件访问协议-版本2”，RFC 1176，1990年8月。
[6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 2060, December 1996.
[6] Crispin，M.，“互联网消息访问协议-第4版”，RFC 2060，1996年12月。
[7] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.
[7] Crocker，D.，“ARPA互联网文本信息格式标准”，RFC 822，1982年8月。
[8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[8] Crocker，D.和P.Overell，编辑，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[9] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.
[9] De Winter，J.，“远程消息队列启动的SMTP服务扩展”，RFC 1985，1996年8月。
[10] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[10] Fajman，R.，“用于消息处置通知的可扩展消息格式”，RFC 2298，1998年3月。
[11] Freed, N, "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[11] Freed，N，“互联网防火墙的行为和要求”，RFC 2979，2000年10月。
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[12] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年12月。
[13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2920, September 2000.
[13] 弗里德，N.，“用于命令管道的SMTP服务扩展”，RFC 2920，2000年9月。
[14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[14] Galvin，J.，Murphy，S.，Crocker，S.和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[15] Gellens，R.和J.Klensin，“信息提交”，RFC 24761998年12月。
[16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156, January 1998.
[16] Kille，S.，“X.400和RFC822/MIME之间的映射”，RFC 2156，1998年1月。
[17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[17] Hinden，R和S.Deering编辑，“IP版本6寻址体系结构”，RFC 23731998年7月。
[18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
[18] Klesin，J.，Freed，N.和K.Moore，“邮件大小声明的SMTP服务扩展”，STD 10，RFC 1870，1995年11月。
[19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[19] Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
[20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[20] Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，“8bit MIMEtransport的SMTP服务扩展”，RFC 16521994年7月。
[21] Lambert, M., "PCMAIL: A distributed mail system for personal computers", RFC 1056, July 1988.
[21] 兰伯特，M.，“PCMAIL：个人计算机的分布式邮件系统”，RFC1056，1988年7月。
[22] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[22] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, December 1996.
[23] Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年12月。
[24] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[24] Moore，K.，“传递状态通知的SMTP服务扩展”，RFC 18911996年1月。
[25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[25] Moore，K.和G.Vaudreuil，“传递状态通知的可扩展消息格式”，RFC 1894，1996年1月。
[26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[26] Myers，J.和M.Rose，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[27] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986.
[27] 帕特里奇，C.，“邮件路由和域系统”，RFC 974，1986年1月。
[28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February 1988.
[28] 帕特里奇，C.，“重复邮件和SMTP”，RFC 1047，1988年2月。
[29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981.
[29] Postel，J.，ed.，“传输控制协议-DARPA互联网程序协议规范”，STD 7，RFC 793，1981年9月。
[30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1982.
[30] Postel，J.，“简单邮件传输协议”，RFC 821，1982年8月。
[31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[31] Ramsdell，B.，编辑，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[32] Resnick，P.，Ed.，“互联网信息格式”，RFC 2822，2001年4月。
[33] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995.
[33] Vaudreuil，G.“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 1830，1995年8月。
[34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[34] Vaudreuil，G.“增强邮件系统状态代码”，RFC 1893，1996年1月。
John C. Klensin AT&T Laboratories 99 Bedford St Boston, MA 02111 USA
美国马萨诸塞州波士顿贝德福德街99号约翰·C·克伦星AT&T实验室02111
Phone: 617-574-3076 EMail: klensin@research.att.com
电话：617-574-3076电子邮件：klensin@research.att.com
Many people worked long and hard on the many iterations of this document. There was wide-ranging debate in the IETF DRUMS Working Group, both on its mailing list and in face to face discussions, about many technical issues and the role of a revised standard for Internet mail transport, and many contributors helped form the wording in this specification. The hundreds of participants in the many discussions since RFC 821 was produced are too numerous to mention, but they all helped this document become what it is.
在本文档的多次迭代中，许多人付出了漫长而艰苦的努力。IETF工作组在邮件列表和面对面的讨论中就许多技术问题和互联网邮件传输修订标准的作用进行了广泛的辩论，许多贡献者帮助形成了本规范中的措辞。自RFC 821产生以来，在众多讨论中，数百名参与者不胜枚举，但他们都帮助本文件成为现实。
APPENDICES
附录
A. TCP Transport Service
A.TCP传输服务
The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero. Service extensions may modify this rule to permit transmission of full 8-bit data bytes as part of the message body, but not in SMTP commands or responses.
TCP连接支持8位字节的传输。SMTP数据是7位ASCII字符。每个字符作为8位字节传输，高位清除为零。服务扩展可以修改此规则，以允许作为邮件正文的一部分传输完整的8位数据字节，但不能在SMTP命令或响应中传输。
B. Generating SMTP Commands from RFC 822 Headers
B.从RFC 822头生成SMTP命令
Some systems use RFC 822 headers (only) in a mail submission protocol, or otherwise generate SMTP commands from RFC 822 headers when such a message is handed to an MTA from a UA. While the MTA-UA protocol is a private matter, not covered by any Internet Standard, there are problems with this approach. For example, there have been repeated problems with proper handling of "bcc" copies and redistribution lists when information that conceptually belongs to a mail envelopes is not separated early in processing from header information (and kept separate).
某些系统（仅）在邮件提交协议中使用RFC 822邮件头，或者在将此类邮件从UA传递给MTA时，从RFC 822邮件头生成SMTP命令。虽然MTA-UA协议是私人事务，没有任何互联网标准涵盖，但这种方法存在问题。例如，当概念上属于邮件信封的信息在处理初期没有与邮件头信息分开（并保持分开）时，在正确处理“密件抄送”副本和重新分发列表方面反复出现问题。
It is recommended that the UA provide its initial ("submission client") MTA with an envelope separate from the message itself. However, if the envelope is not supplied, SMTP commands SHOULD be generated as follows:
建议UA向其初始（“提交客户端”）MTA提供一个独立于邮件本身的信封。但是，如果未提供信封，则应按如下方式生成SMTP命令：
1. Each recipient address from a TO, CC, or BCC header field SHOULD be copied to a RCPT command (generating multiple message copies if that is required for queuing or delivery). This includes any addresses listed in a RFC 822 "group". Any BCC fields SHOULD then be removed from the headers. Once this process is completed, the remaining headers SHOULD be checked to verify that at least one To:, Cc:, or Bcc: header remains. If none do, then a bcc: header with no additional information SHOULD be inserted as specified in [32].
1. 收件人、抄送或密件抄送标头字段中的每个收件人地址都应复制到RCPT命令（如果排队或传递需要，则生成多个邮件副本）。这包括RFC 822“组”中列出的任何地址。然后，应将所有密件抄送字段从标题中删除。此过程完成后，应检查剩余的标头，以验证是否至少保留一个to:、Cc:、或Bcc:标头。如果没有，则应按照[32]中的规定插入不包含其他信息的bcc:标头。
2. The return address in the MAIL command SHOULD, if possible, be derived from the system's identity for the submitting (local) user, and the "From:" header field otherwise. If there is a system identity available, it SHOULD also be copied to the Sender header field if it is different from the address in the From header field. (Any Sender field that was already there SHOULD be removed.) Systems may provide a way for submitters to override the envelope return address, but may want to restrict its use to privileged users. This will not prevent mail forgery, but may lessen its incidence; see section 7.1.
2. 如果可能，MAIL命令中的返回地址应来自提交（本地）用户的系统标识，否则应来自“发件人：”标题字段。如果有可用的系统标识，如果它与发件人标头字段中的地址不同，还应将其复制到发件人标头字段。（应该删除已经存在的任何发件人字段。）系统可以为提交人提供覆盖信封返回地址的方法，但可能希望将其使用限制为特权用户。这不会防止邮件伪造，但可能会减少其发生率；见第7.1节。
When an MTA is being used in this way, it bears responsibility for ensuring that the message being transmitted is valid. The mechanisms for checking that validity, and for handling (or returning) messages that are not valid at the time of arrival, are part of the MUA-MTA interface and not covered by this specification.
以这种方式使用MTA时，MTA负责确保传输的消息有效。检查有效性以及处理（或返回）到达时无效的消息的机制是MUA-MTA接口的一部分，不在本规范的范围内。
A submission protocol based on Standard RFC 822 information alone MUST NOT be used to gateway a message from a foreign (non-SMTP) mail system into an SMTP environment. Additional information to construct an envelope must come from some source in the other environment, whether supplemental headers or the foreign system's envelope.
仅基于标准RFC 822信息的提交协议不得用于将邮件从外部（非SMTP）邮件系统网关传送到SMTP环境。构造信封的附加信息必须来自其他环境中的某些源，无论是补充标头还是外部系统的信封。
Attempts to gateway messages using only their header "to" and "cc" fields have repeatedly caused mail loops and other behavior adverse to the proper functioning of the Internet mail environment. These problems have been especially common when the message originates from an Internet mailing list and is distributed into the foreign environment using envelope information. When these messages are then processed by a header-only remailer, loops back to the Internet environment (and the mailing list) are almost inevitable.
试图仅使用邮件头的“收件人”和“抄送”字段作为邮件网关，已多次导致邮件循环和其他不利于Internet邮件环境正常运行的行为。当消息来源于Internet邮件列表并使用信封信息分发到外部环境时，这些问题尤其常见。当这些消息被一个只发送头的重发器处理时，返回到Internet环境（和邮件列表）的循环几乎是不可避免的。
C. Source Routes
C.来源路线
Historically, the <reverse-path> was a reverse source routing list of hosts and a source mailbox. The first host in the <reverse-path> SHOULD be the host sending the MAIL command. Similarly, the <forward-path> may be a source routing lists of hosts and a destination mailbox. However, in general, the <forward-path> SHOULD contain only a mailbox and domain name, relying on the domain name system to supply routing information if required. The use of source routes is deprecated; while servers MUST be prepared to receive and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT transmit them and this section was included only to provide context.
历史上，<reverse path>是主机和源邮箱的反向源路由列表。<reverse path>中的第一个主机应该是发送邮件命令的主机。类似地，<转发路径>可以是主机和目标邮箱的源路由列表。但是，一般来说，<forward path>应该只包含邮箱和域名，如果需要，依赖域名系统提供路由信息。不推荐使用源路由；虽然服务器必须准备好接收和处理它们，如第3.3节和F.2节所述，但客户端不应传输它们，本节仅用于提供上下文。
For relay purposes, the forward-path may be a source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-qualified domain names. This form is used to emphasize the distinction between an address and a route. The mailbox is an absolute address, and the route is information about how to get there. The two concepts should not be confused.
出于中继目的，前向路径可以是形式为“@ONE，@TWO:JOE@THREE“，其中1、2和3必须是完全限定的域名。此表格用于强调地址和路线之间的区别。邮箱是一个绝对地址，路由是关于如何到达那里的信息。这两个概念不应混淆。
If source routes are used, RFC 821 and the text below should be consulted for the mechanisms for constructing and updating the forward- and reverse-paths.
如果使用源路由，则应参考RFC 821和以下文本，了解用于构建和更新正向和反向路径的机制。
The SMTP server transforms the command arguments by moving its own identifier (its domain name or that of any domain for which it is acting as a mail exchanger), if it appears, from the forward-path to the beginning of the reverse-path.
SMTP服务器通过将其自己的标识符（其域名或其作为邮件交换器的任何域的域名）从正向路径移动到反向路径的开头来转换命令参数（如果出现）。
Notice that the forward-path and reverse-path appear in the SMTP commands and replies, but not necessarily in the message. That is, there is no need for these paths and especially this syntax to appear in the "To:" , "From:", "CC:", etc. fields of the message header. Conversely, SMTP servers MUST NOT derive final message delivery information from message header fields.
请注意，转发路径和反向路径出现在SMTP命令和回复中，但不一定出现在邮件中。也就是说，不需要在消息头的“to:”、“From:”、“CC:”等字段中显示这些路径，尤其是该语法。相反，SMTP服务器不得从邮件头字段派生最终邮件传递信息。
When the list of hosts is present, it is a "reverse" source route and indicates that the mail was relayed through each host on the list (the first host in the list was the most recent relay). This list is used as a source route to return non-delivery notices to the sender. As each relay host adds itself to the beginning of the list, it MUST use its name as known in the transport environment to which it is relaying the mail rather than that of the transport environment from which the mail came (if they are different).
当主机列表存在时，它是一个“反向”源路由，并指示邮件通过列表上的每个主机进行中继（列表中的第一个主机是最近的中继）。此列表用作将未送达通知返回给发件人的源路由。当每个中继主机将自己添加到列表的开头时，它必须使用其在转发邮件的传输环境中已知的名称，而不是邮件来自的传输环境的名称（如果它们不同）。
D. Scenarios
D.情景
This section presents complete scenarios of several types of SMTP sessions. In the examples, "C:" indicates what is said by the SMTP client, and "S:" indicates what is said by the SMTP server.
本节介绍几种类型的SMTP会话的完整场景。在示例中，“C:”表示SMTP客户端所说的内容，“S:”表示SMTP服务器所说的内容。
This SMTP example shows mail sent by Smith at host bar.com, to Jones, Green, and Brown at host foo.com. Here we assume that host bar.com contacts host foo.com directly. The mail is accepted for Jones and Brown. Green does not have a mailbox at host foo.com.
这个SMTP示例显示了Smith在主机bar.com上发送给Jones、Green和Brown在主机foo.com上的邮件。这里我们假设host bar.com直接与host foo.com联系。琼斯和布朗的邮件已被接受。Green在主机foo.com上没有邮箱。
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RCPT TO:<Brown@foo.com>
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RCPT TO:<Brown@foo.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RSET
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RSET
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
Step 1 -- Source Host to Relay Host
步骤1--源主机到中继主机
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<JQP@bar.com>
S: 250 OK
C: RCPT TO:<@foo.com:Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Date: Thu, 21 May 1998 05:33:29 -0700
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<JQP@bar.com>
S: 250 OK
C: RCPT TO:<@foo.com:Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Date: Thu, 21 May 1998 05:33:29 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
Step 2 -- Relay Host to Destination Host
步骤2——将主机中继到目标主机
S: 220 xyz.com Simple Mail Transfer Service Ready
C: EHLO foo.com
S: 250 xyz.com is on the air
C: MAIL FROM:<@foo.com:JQP@bar.com>
S: 250 OK
C: RCPT TO:<Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Received: from bar.com by foo.com ; Thu, 21 May 1998
C: 05:33:29 -0700
C: Date: Thu, 21 May 1998 05:33:22 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
S: 220 xyz.com Simple Mail Transfer Service Ready
C: EHLO foo.com
S: 250 xyz.com is on the air
C: MAIL FROM:<@foo.com:JQP@bar.com>
S: 250 OK
C: RCPT TO:<Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Received: from bar.com by foo.com ; Thu, 21 May 1998
C: 05:33:29 -0700
C: Date: Thu, 21 May 1998 05:33:22 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250-VRFY
S: 250 HELP
C: VRFY Crispin
S: 250 Mark Crispin <Admin.MRC@foo.com>
C: SEND FROM:<EAK@bar.com>
S: 250 OK
C: RCPT TO:<Admin.MRC@foo.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
S: 250-VRFY
S: 250 HELP
C: VRFY Crispin
S: 250 Mark Crispin <Admin.MRC@foo.com>
C: SEND FROM:<EAK@bar.com>
S: 250 OK
C: RCPT TO:<Admin.MRC@foo.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
E. Other Gateway Issues
E.其他网关问题
In general, gateways between the Internet and other mail systems SHOULD attempt to preserve any layering semantics across the boundaries between the two mail systems involved. Gateway-translation approaches that attempt to take shortcuts by mapping, (such as envelope information from one system to the message headers or body of another) have generally proven to be inadequate in important ways. Systems translating between environments that do not support both envelopes and headers and Internet mail must be written with the understanding that some information loss is almost inevitable.
一般来说，Internet和其他邮件系统之间的网关应尝试在涉及的两个邮件系统之间的边界上保留任何分层语义。试图通过映射走捷径的网关转换方法（例如从一个系统到另一个系统的消息头或消息体的信封信息）通常在重要方面被证明是不充分的。在不支持信封和邮件头以及Internet邮件的环境之间进行系统转换时，必须理解某些信息丢失几乎是不可避免的。
F. Deprecated Features of RFC 821
F.不推荐使用的RFC 821功能
A few features of RFC 821 have proven to be problematic and SHOULD NOT be used in Internet mail.
RFC 821的一些功能已被证明是有问题的，不应在Internet邮件中使用。
This command, described in RFC 821, raises important security issues since, in the absence of strong authentication of the host requesting that the client and server switch roles, it can easily be used to divert mail from its correct destination. Its use is deprecated; SMTP systems SHOULD NOT use it unless the server can authenticate the client.
RFC 821中描述的此命令引发了重要的安全问题，因为在主机没有请求客户端和服务器切换角色的强身份验证的情况下，它可以轻松地用于将邮件从正确的目的地转移。不推荐使用它；除非服务器可以对客户端进行身份验证，否则SMTP系统不应使用它。
RFC 821 utilized the concept of explicit source routing to get mail from one host to another via a series of relays. The requirement to utilize source routes in regular mail traffic was eliminated by the introduction of the domain name system "MX" record and the last significant justification for them was eliminated by the introduction, in RFC 1123, of a clear requirement that addresses following an "@" must all be fully-qualified domain names. Consequently, the only remaining justifications for the use of source routes are support for very old SMTP clients or MUAs and in mail system debugging. They can, however, still be useful in the latter circumstance and for routing mail around serious, but temporary, problems such as problems with the relevant DNS records.
RFC 821利用显式源路由的概念，通过一系列中继从一台主机到另一台主机获取邮件。通过引入域名系统“MX”记录，消除了在常规邮件通信中使用源路由的要求，并且在RFC 1123中引入了一项明确要求，即“@”后面的地址都必须是完全限定的域名，从而消除了使用源路由的最后一个重要理由。因此，使用源路由的唯一剩余理由是支持非常旧的SMTP客户端或MUA以及邮件系统调试。但是，在后一种情况下，它们仍然有用，并可用于在严重但暂时的问题（如相关DNS记录的问题）周围路由邮件。
SMTP servers MUST continue to accept source route syntax as specified in the main body of this document and in RFC 1123. They MAY, if necessary, ignore the routes and utilize only the target domain in the address. If they do utilize the source route, the message MUST be sent to the first domain shown in the address. In particular, a server MUST NOT guess at shortcuts within the source route.
SMTP服务器必须继续接受本文档正文和RFC 1123中指定的源路由语法。如有必要，他们可以忽略路由，只使用地址中的目标域。如果他们使用源路由，则必须将消息发送到地址中显示的第一个域。特别是，服务器不得猜测源路由中的快捷方式。
Clients SHOULD NOT utilize explicit source routing except under unusual circumstances, such as debugging or potentially relaying around firewall or mail system configuration errors.
客户端不应使用显式源路由，除非在异常情况下，例如调试或可能在防火墙周围中继或邮件系统配置错误。
As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to HELO when the server will accept the former. Servers must continue to accept and process HELO in order to support older clients.
如第3.1节和第4.1.1节所述，当服务器接受前者时，EHLO强烈优于HELO。服务器必须继续接受和处理HELO，以支持旧客户端。
RFC 821 provided for specifying an Internet address as a decimal integer host number prefixed by a pound sign, "#". In practice, that form has been obsolete since the introduction of TCP/IP. It is deprecated and MUST NOT be used.
RFC 821用于将Internet地址指定为以磅符号“#”为前缀的十进制整数主机号。实际上，自从TCP/IP引入以来，这种形式已经过时。它已弃用，不得使用。
When dates are inserted into messages by SMTP clients or servers (e.g., in trace fields), four-digit years MUST BE used. Two-digit years are deprecated; three-digit years were never permitted in the Internet mail system.
SMTP客户端或服务器将日期插入邮件时（例如，在跟踪字段中），必须使用四位数的年份。不推荐使用两位数的年份；互联网邮件系统中从未允许使用三位数的年份。
In addition to specifying a mechanism for delivering messages to user's mailboxes, RFC 821 provided additional, optional, commands to deliver messages directly to the user's terminal screen. These commands (SEND, SAML, SOML) were rarely implemented, and changes in workstation technology and the introduction of other protocols may have rendered them obsolete even where they are implemented.
除了指定将消息传递到用户邮箱的机制外，RFC 821还提供了附加的可选命令，用于将消息直接传递到用户的终端屏幕。这些命令（SEND、SAML、SOML）很少实现，工作站技术的变化和其他协议的引入可能会使它们在实现的地方变得过时。
Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers MAY implement them. If they are implemented by servers, the implementation model specified in RFC 821 MUST be used and the command names MUST be published in the response to the EHLO command.
客户端不应将SEND、SAML或SOML作为服务提供。服务器可以实现它们。如果它们由服务器实现，则必须使用RFC 821中指定的实现模型，并且必须在对EHLO命令的响应中发布命令名。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。