Network Working Group J. Klensin
Request for Comments: 5321 October 2008
Obsoletes: 2821
Updates: 1123
Category: Standards Track
Network Working Group J. Klensin
Request for Comments: 5321 October 2008
Obsoletes: 2821
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）。本备忘录的分发不受限制。
Abstract
摘要
This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. 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 for "split-UA" (User Agent) mail reading systems and mobile environments.
本文档是Internet电子邮件传输基本协议的规范。它合并、更新和澄清了以前的几个文档，使大部分文档全部或部分过时。它涵盖了现代互联网的SMTP扩展机制和最佳实践，但没有提供有关特定扩展的详细信息。尽管SMTP被设计为邮件传输和交付协议，但本规范还包含对其作为“split UA”（用户代理）邮件阅读系统和移动环境的“邮件提交”协议使用非常重要的信息。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . . 5
1.2. History and Context for This Document . . . . . . . . . . 5
1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 7
2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 9
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Definition and Registration of Extensions . . . . . . 10
2.2.3. Special Issues with Extensions . . . . . . . . . . . . 11
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . . 11
2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 12
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . . 12
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . . 13
2.3.6. Buffer and State Table . . . . . . . . . . . . . . . . 14
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . . 14
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 15
2.3.10. Originator, Delivery, Relay, and Gateway Systems . . . 15
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 15
2.4. General Syntax Principles and Transaction Model . . . . . 16
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . . 17
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 18
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 18
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 19
3.4. Forwarding for Address Correction or Updating . . . . . . 21
3.5. Commands for Debugging Addresses . . . . . . . . . . . . . 22
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . . 24
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . . 25
3.5.4. Semantics and Applications of EXPN . . . . . . . . . . 26
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 26
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . . 26
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . . 26
3.6.3. Message Submission Servers as Relays . . . . . . . . . 27
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 28
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 28
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . . 29
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 29
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 29
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 30
3.8. Terminating Sessions and Connections . . . . . . . . . . . 30
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 31
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . . 5
1.2. History and Context for This Document . . . . . . . . . . 5
1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 7
2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 9
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Definition and Registration of Extensions . . . . . . 10
2.2.3. Special Issues with Extensions . . . . . . . . . . . . 11
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . . 11
2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 12
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . . 12
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . . 13
2.3.6. Buffer and State Table . . . . . . . . . . . . . . . . 14
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . . 14
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 15
2.3.10. Originator, Delivery, Relay, and Gateway Systems . . . 15
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 15
2.4. General Syntax Principles and Transaction Model . . . . . 16
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . . 17
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 18
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 18
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 19
3.4. Forwarding for Address Correction or Updating . . . . . . 21
3.5. Commands for Debugging Addresses . . . . . . . . . . . . . 22
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . . 24
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . . 25
3.5.4. Semantics and Applications of EXPN . . . . . . . . . . 26
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 26
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . . 26
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . . 26
3.6.3. Message Submission Servers as Relays . . . . . . . . . 27
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 28
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 28
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . . 29
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 29
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 29
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 30
3.8. Terminating Sessions and Connections . . . . . . . . . . . 30
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 31
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 31
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . . 31
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 32
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . . 32
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . . 43
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 44
4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . . 46
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1. Reply Code Severities and Theory . . . . . . . . . . . 48
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . . 50
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . . 52
4.2.4. Reply Code 502 . . . . . . . . . . . . . . . . . . . . 53
4.2.5. Reply Codes after DATA and the Subsequent
<CRLF>.<CRLF> . . . . . . . . . . . . . . . . . . . . 53
4.3. Sequencing of Commands and Replies . . . . . . . . . . . . 54
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 54
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 55
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 57
4.5. Additional Implementation Issues . . . . . . . . . . . . . 61
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . . 61
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . . 62
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . . 62
4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . . 62
4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . . 63
4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . . 63
4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . . 63
4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 63
4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 63
4.5.3.1.8. Recipients Buffer . . . . . . . . . . . . . . 64
4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . . 64
4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . . 64
4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . . 65
4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . . 65
4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 65
4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 65
4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . . 66
4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 66
4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 66
4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . . 66
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . . 66
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 68
5. Address Resolution and Mail Handling . . . . . . . . . . . . . 69
5.1. Locating the Target Host . . . . . . . . . . . . . . . . . 69
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 71
6. Problem Detection and Handling . . . . . . . . . . . . . . . . 71
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . . 31
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 32
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . . 32
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . . 43
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 44
4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . . 46
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1. Reply Code Severities and Theory . . . . . . . . . . . 48
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . . 50
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . . 52
4.2.4. Reply Code 502 . . . . . . . . . . . . . . . . . . . . 53
4.2.5. Reply Codes after DATA and the Subsequent
<CRLF>.<CRLF> . . . . . . . . . . . . . . . . . . . . 53
4.3. Sequencing of Commands and Replies . . . . . . . . . . . . 54
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 54
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 55
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 57
4.5. Additional Implementation Issues . . . . . . . . . . . . . 61
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . . 61
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . . 62
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . . 62
4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . . 62
4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . . 63
4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . . 63
4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . . 63
4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 63
4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 63
4.5.3.1.8. Recipients Buffer . . . . . . . . . . . . . . 64
4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . . 64
4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . . 64
4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . . 65
4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . . 65
4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 65
4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 65
4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . . 66
4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 66
4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 66
4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . . 66
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . . 66
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 68
5. Address Resolution and Mail Handling . . . . . . . . . . . . . 69
5.1. Locating the Target Host . . . . . . . . . . . . . . . . . 69
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 71
6. Problem Detection and Handling . . . . . . . . . . . . . . . . 71
6.1. Reliable Delivery and Replies by Email . . . . . . . . . . 71
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . . 72
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . . 73
6.4. Compensating for Irregularities . . . . . . . . . . . . . 73
7. Security Considerations . . . . . . . . . . . . . . . . . . . 75
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . . 75
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 76
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 76
7.4. Mail Rerouting Based on the 251 and 551 Response Codes . . 77
7.5. Information Disclosure in Announcements . . . . . . . . . 77
7.6. Information Disclosure in Trace Fields . . . . . . . . . . 78
7.7. Information Disclosure in Message Forwarding . . . . . . . 78
7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 78
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . . 78
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.1. Normative References . . . . . . . . . . . . . . . . . . . 81
10.2. Informative References . . . . . . . . . . . . . . . . . . 82
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . . 85
Appendix B. Generating SMTP Commands from RFC 822 Header
Fields . . . . . . . . . . . . . . . . . . . . . . . 85
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . . 86
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . . 87
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 88
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 89
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 90
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . . 92
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 92
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 93
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . . 93
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . . 94
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 94
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . . 94
6.1. Reliable Delivery and Replies by Email . . . . . . . . . . 71
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . . 72
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . . 73
6.4. Compensating for Irregularities . . . . . . . . . . . . . 73
7. Security Considerations . . . . . . . . . . . . . . . . . . . 75
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . . 75
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 76
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 76
7.4. Mail Rerouting Based on the 251 and 551 Response Codes . . 77
7.5. Information Disclosure in Announcements . . . . . . . . . 77
7.6. Information Disclosure in Trace Fields . . . . . . . . . . 78
7.7. Information Disclosure in Message Forwarding . . . . . . . 78
7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 78
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . . 78
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.1. Normative References . . . . . . . . . . . . . . . . . . . 81
10.2. Informative References . . . . . . . . . . . . . . . . . . 82
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . . 85
Appendix B. Generating SMTP Commands from RFC 822 Header
Fields . . . . . . . . . . . . . . . . . . . . . . . 85
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . . 86
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . . 87
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 88
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 89
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 90
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . . 92
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 92
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 93
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . . 93
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . . 94
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 94
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . . 94
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 [1] describe some of them.
SMTP独立于特定的传输子系统，只需要可靠的有序数据流通道。虽然本文档专门讨论TCP上的传输，但也可以使用其他传输。RFC 821[1]的附录描述了其中一些。
An important feature of SMTP is its capability to transport mail across multiple networks, usually referred to as "SMTP mail relaying" (see Section 3.6). 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, 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的一个重要功能是能够跨多个网络传输邮件，通常称为“SMTP邮件中继”（见第3.6节）。网络由公共Internet上的可相互访问的TCP主机、防火墙隔离的TCP/IP Intranet上的可相互访问的TCP主机或使用非TCP传输级别协议的某些其他LAN或WAN环境中的主机组成。使用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 (RFC 1035 [2], RFC 974 [12], and Section 5 of this document) are used to identify the appropriate next-hop destination for a message being transported.
通过这种方式，邮件消息可以在其从发件人到最终收件人的路径上通过多个中间中继或网关主机。域名系统的邮件交换机制（RFC 1035[2]、RFC 974[12]和本文件第5节）用于识别正在传输的消息的适当下一跳目的地。
This document is a specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but does not add new or change existing functionality of the following:
本文档是Internet电子邮件传输基本协议的规范。它整合、更新和澄清，但不添加或更改以下功能的现有功能：
o the original SMTP (Simple Mail Transfer Protocol) specification of RFC 821 [1],
o RFC 821[1]的原始SMTP（简单邮件传输协议）规范，
o domain name system requirements and implications for mail transport from RFC 1035 [2] and RFC 974 [12],
o 来自RFC 1035[2]和RFC 974[12]的邮件传输的域名系统要求和影响，
o the clarifications and applicability statements in RFC 1123 [3], and
o RFC 1123[3]中的澄清和适用性声明，以及
o material drawn from the SMTP Extension mechanisms in RFC 1869 [13].
o 材料取自RFC 1869[13]中的SMTP扩展机制。
o Editorial and clarification changes to RFC 2821 [14] to bring that specification to Draft Standard.
o 对RFC 2821[14]进行编辑和澄清修改，以将该规范纳入标准草案。
It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updates RFC 1123 (replacing 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 1869和RFC 2821，并更新了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 Post Office Protocol (POP) (RFC 937 [15], RFC 1939 [16]) and IMAP (RFC 3501 [17]). In general, the separate mail submission protocol specified in RFC 4409 [18] is now preferred to direct use of SMTP; more discussion of that subject appears in that document.
尽管SMTP被设计为邮件传输和交付协议，但本规范还包含对其作为“邮件提交”协议的使用非常重要的信息，这是邮局协议（POP）（RFC 937[15]，RFC 1939[16]）和IMAP（RFC 3501[17]）的建议。一般来说，RFC 4409[18]中规定的单独邮件提交协议现在比直接使用SMTP更可取；关于这个问题的更多讨论见该文件。
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, RFC 5322 [4], discusses message header sections and bodies and specifies formats and structures for them.
附带文档RFC 5322[4]讨论了消息头部分和正文，并指定了它们的格式和结构。
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 in RFC 2119 [5]. As each of these terms was intentionally and carefully chosen to improve the interoperability of email, each use of these terms is to be treated as a conformance requirement.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。由于这些术语中的每一个都是为了提高电子邮件的互操作性而特意精心选择的，因此这些术语的每一次使用都将被视为符合性要求。
Because this document has a long history and to avoid the risk of various errors and of confusing readers and documents that point to this one, most examples and the domain names they contain are preserved from RFC 2821. Readers are cautioned that these are
由于本文档历史悠久，为了避免出现各种错误以及混淆读者和指向本文档的文档的风险，大多数示例及其包含的域名都保留在RFC 2821中。读者应注意，这些是
illustrative examples that should not actually be used in either code or configuration files.
不应在代码或配置文件中实际使用的示例。
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 identifier(s) ("names") of the domain(s) to which mail messages are to be transferred, is a local matter, and is not addressed by this document. In some cases, the designated domain(s), or those 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 (RFC 937 [15], RFC 1939 [16]) or IMAP (RFC 3501 [17]) protocols, or when the SMTP client is inside an isolated transport service environment, the domain 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 domains 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 ones, and their destinations, are expected to support all of the queuing, retrying, and alternate address functions discussed in this specification. In many situations and configurations, the less-capable clients discussed above SHOULD be using the message submission protocol (RFC 4409 [18]) rather than SMTP.
向SMTP客户端显示邮件消息的方式，以及该客户端如何确定邮件消息要传输到的域的标识符（“名称”），是一个本地问题，本文档不涉及此问题。在某些情况下，指定的域或由SMTP客户端确定的域将标识邮件的最终目的地。在其他情况下，与POP（RFC 937[15]、RFC 1939[16]）或IMAP（RFC 3501[17]）协议的实现相关联的SMTP客户端常见，或者当SMTP客户端位于隔离的传输服务环境中时，确定的域将标识所有邮件消息将通过其中继的中间目的地。无论与单个邮件关联的目标域是什么，都可以传输所有通信量的SMTP客户端，或者不维护用于重试最初无法完成的邮件传输的队列的SMTP客户端，可能符合此规范，但不被视为完全有能力。完全功能的SMTP实现，包括这些功能较弱的SMTP所使用的中继及其目的地，预计将支持本规范中讨论的所有排队、重试和备用地址功能。在许多情况和配置中，上面讨论的功能较差的客户端应该使用消息提交协议（RFC 4409[18]），而不是SMTP。
The means by which an SMTP client, once it has determined a target domain, 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, once the server has issued a success response at the end of the mail data, a formal handoff of responsibility for the message occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so (see Sections 6.1, 6.2, and 7.8, below).
换句话说，邮件传输可以在原始SMTP发件人和最终SMTP收件人之间的单个连接中发生，也可以通过中间系统在一系列跃点中发生。在任何一种情况下，一旦服务器在邮件数据末尾发出成功响应，就会发生对消息的正式责任移交：协议要求服务器必须承担传递消息的责任或正确报告失败的责任（见下文第6.1、6.2和7.8节）。
Once the transmission channel is established and initial handshaking is 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 lines in the header section 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 upon extension requests such as command pipelining (RFC 2920 [19]).
服务器响应每个命令并给出回复；答复可能表明该命令已被接受，预期会有其他命令，或者存在临时或永久性错误情况。指定发件人或收件人的命令可能包括服务器允许的SMTP服务扩展请求，如第2.2节所述。该对话框有意地一次锁定一个步骤，尽管这可以通过双方同意的扩展请求（如命令管道）进行修改（RFC 2920[19]）。
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. Historically, this transmission normally occurred 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. A very common case in the Internet today involves submission of the original message to an intermediate, "message submission" server, which is similar to a relay but has some additional properties; such servers are discussed in Section 2.3.10 and at some length in RFC 4409 [18]. 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服务器进行传输。当今互联网上一个非常常见的情况是将原始消息提交到中间“消息提交”服务器，该服务器类似于中继，但具有一些附加属性；第2.3.10节和RFC 4409[18]中详细讨论了此类服务器。通常通过使用域名服务（DNS）邮件交换机制选择充当SMTP中继或进入其他传输环境的网关的中间主机。
Usually, intermediate hosts are determined via the DNS MX record, not by explicit "source" routing (see Section 5 and Appendix C and Appendix 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
SMTP被广泛部署，高质量的实现已被证明非常健壮。然而，互联网社区现在认为一些服务很重要，而这些服务在协议最初设计时是没有预料到的。如果要为这些服务提供支持
added, it must be done in a way that permits older implementations to continue working acceptably. The extension framework consists of:
此外，必须以允许旧的实现继续正常工作的方式进行。扩展框架包括：
o The SMTP command EHLO, superseding the earlier HELO,
o SMTP命令EHLO取代了早期的HELO，
o a registry of SMTP service extensions,
o SMTP服务扩展的注册表，
o additional parameters to the SMTP MAIL and RCPT commands, and
o SMTP邮件和RCPT命令的其他参数，以及
o optional replacements for commands defined in this protocol, such as for DATA in non-ASCII transmissions (RFC 3030 [20]).
o 本协议中定义的命令的可选替代品，例如非ASCII传输中的数据（RFC 3030[20]）。
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批准的实验协议文件中定义。定义必须包括：
o the textual name of the SMTP service extension;
o SMTP服务扩展的文本名称；
o the EHLO keyword value associated with the extension;
o 与扩展关联的EHLO关键字值；
o the syntax and possible values of parameters associated with the EHLO keyword value;
o 与EHLO关键字值关联的参数的语法和可能值；
o 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);
o 与扩展名关联的任何其他SMTP谓词（其他谓词通常与EHLO关键字值相同，但不要求相同）；
o any new parameters the extension associates with the MAIL or RCPT verbs;
o 扩展名与MAIL或RCPT谓词关联的任何新参数；
o a description of how support for the extension affects the behavior of a server and client SMTP; and
o 对扩展支持如何影响服务器和客户端SMTP行为的描述；和
o the increment by which the extension is increasing the maximum length of the commands MAIL and/or RCPT, over that specified in this Standard.
o 扩展插件将命令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”开头的动词必须始终注册。
Extensions that change fairly basic properties of SMTP operation are permitted. The text in other sections of this document must be understood in that context. In particular, extensions can change the minimum limits specified in Section 4.5.3, can change the ASCII character set requirement as mentioned above, or can introduce some optional modes of message handling.
允许更改SMTP操作基本属性的扩展。本文件其他章节中的文本必须在这一背景下理解。特别是，扩展可以更改第4.5.3节中规定的最小限制，可以更改上述ASCII字符集要求，或者可以引入一些可选的消息处理模式。
In particular, if an extension implies that the delivery path normally supports special features of that extension, and an intermediate SMTP system finds a next hop that does not support the required extension, it MAY choose, based on the specific extension and circumstances, to requeue the message and try later and/or try an alternate MX host. If this strategy is employed, the timeout to fall back to an unextended format (if one is available) SHOULD be less than the normal timeout for bouncing as undeliverable (e.g., if normal timeout is three days, the requeue timeout before attempting to transmit the mail without the extension might be one day).
特别是，如果扩展意味着传递路径通常支持该扩展的特殊功能，并且中间SMTP系统发现下一个跃点不支持所需的扩展，则它可以根据特定的扩展和情况选择重新获取消息，稍后重试和/或尝试备用MX主机。如果采用此策略，返回到未扩展格式（如果有）的超时应小于无法投递的正常跳转超时（例如，如果正常超时为三天，则尝试在没有扩展的情况下传输邮件之前的重新排队超时可能为一天）。
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
SMTP信封作为一系列SMTP协议单元发送（如第3节所述）。它包括发起者地址（至
which error reports should be directed), one or more recipient addresses, and optional protocol extension material. Historically, variations on the reverse-path (originator) address specification command (MAIL) could be used to specify alternate delivery modes, such as immediate display; those variations have now been deprecated (see Appendix F and Appendix F.6).
应指示哪些错误报告）、一个或多个收件人地址以及可选协议扩展材料。历史上，反向路径（发起者）地址规范命令（邮件）的变体可用于指定替代交付模式，如即时显示；这些变化现已被弃用（见附录F和附录F.6）。
The SMTP content is sent in the SMTP DATA protocol unit and has two parts: the header section and the body. If the content conforms to other contemporary standards, the header section consists of a collection of header fields, each consisting of a header name, a colon, and data, structured as in the message format specification (RFC 5322 [4]); the body, if structured, is defined according to MIME (RFC 2045 [21]). The content is textual in nature, expressed using the US-ASCII repertoire [6]. Although SMTP extensions (such as "8BITMIME", RFC 1652 [22]) may relax this restriction for the content body, the content header fields are always encoded using the US-ASCII repertoire. Two MIME extensions (RFC 2047 [23] and RFC 2231 [24]) define an algorithm for representing header values outside the US-ASCII repertoire, while still encoding them using the US-ASCII repertoire.
SMTP内容在SMTP数据协议单元中发送，包含两部分：标题部分和正文。如果内容符合其他当代标准，则标题部分由标题字段集合组成，每个字段由标题名称、冒号和数据组成，其结构如消息格式规范（RFC 5322[4]）；主体（如果是结构化的）是根据MIME（RFC 2045[21]）定义的。内容本质上是文本，使用US-ASCII指令表[6]表示。尽管SMTP扩展（如“8BITMIME”，RFC 1652[22]）可能会放宽对内容正文的限制，但内容标题字段始终使用US-ASCII指令表进行编码。两个MIME扩展（RFC 2047[23]和RFC 2231[24]）定义了一种算法，用于表示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 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
RFC 821发布后，额外的邮件系统术语变得很常见，并在方便的情况下用于本规范。特别是，SMTP服务器和客户端提供邮件传输服务，因此充当“邮件传输代理”（MTA）。“邮件用户代理”（MUA或UAs）通常被认为是邮件的来源和目标。从源头上讲，MUA可能会收集用户发送的邮件并将其转交给MTA；最终（“交付”）MTA将被视为将邮件交给MUA（或至少将责任转移给MUA，例如，将邮件存放在“邮件存储”中）。然而，尽管这些术语在其他环境中的使用至少看起来非常精确，但MUA和MTA之间的隐含边界通常无法准确地匹配常见的一致性实践
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.
互联网邮件。因此，读者在推断这些术语在其他地方使用时可能隐含的强烈关系和责任时应谨慎。
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 the next section); they SHOULD NOT be identified by numerical addresses, i.e., by address literals as described in Section 4.1.2.
在本规范中，主机是连接到Internet（或在某些情况下连接到专用TCP/IP网络）并支持SMTP协议的计算机系统。主机名称已知（见下一节）；它们不应通过数字地址标识，即第4.1.2节所述的地址文字。
A domain name (or often just a "domain") consists of one or more components, separated by dots if more than one appears. In the case of a top-level domain used by itself in an email address, a single string is used without any dots. This makes the requirement, described in more detail below, that only fully-qualified domain names appear in SMTP transactions on the public Internet, particularly important where top-level domains are involved. These components ("labels" in DNS terminology, RFC 1035 [2]) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set [6]. 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 RFC 1035 [2] and Section 5 of this specification.
域名（或通常只是“域”）由一个或多个组件组成，如果出现多个组件，则用点分隔。在电子邮件地址中使用顶级域的情况下，使用单个字符串，不带任何点。这使得下面更详细地描述的要求，只有完全限定的域名出现在公共互联网上的SMTP事务中，在涉及顶级域的情况下尤为重要。这些组件（“DNS术语中的标签”，RFC 1035[2]）仅限于SMTP目的，由从ASCII字符集[6]提取的字母、数字和连字符序列组成。域名用作域名层次结构中主机和其他实体的名称。例如，域可能引用别名（CNAME RR的标签）或用于传递邮件的邮件交换器记录的标签，而不是表示主机名。参见RFC 1035[2]和本规范第5节。
The domain name, as described in this document and in RFC 1035 [2], 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.
如本文档和RFC 1035[2]所述，域名是完整的、完全限定的名称（通常称为“FQDN”）。非FQDN形式的域名只不过是本地别名。本地别名不得出现在任何SMTP事务中。
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 address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs:
在SMTP中使用域名时，仅允许使用可解析的完全限定域名（FQDN）。换句话说，可以解析为MX RRs或地址（即A或AAAA）RRs（如第5节所述）的名称是允许的，其目标可以依次解析为MX或地址RRs的CNAME RRs也是允许的。不得使用本地昵称或非限定名称。需要FQDN的规则有两个例外：
o The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4.
o EHLO命令中给出的域名必须是主主机名（解析为地址RR的域名），如果主机没有名称，则必须是地址文字，如第4.1.3节所述，并在第4.1.4节的EHLO讨论中进一步讨论。
o 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.
o 保留邮箱名称“postmaster”可在RCPT命令中使用，无需域限定（见第4.1.1.3节），如果使用，则必须接受。
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 that 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 from the sender to the receiver via the transmission channel in "lines".
SMTP命令和消息数据（除非由服务扩展更改）通过“线路”中的传输通道从发送方传输到接收方。
An SMTP reply is an acknowledgment (positive or negative) sent in "lines" 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. RFC 3463 [25], specifies further structuring of the reply strings, including the use of supplemental and more specific completion codes (see also RFC 5248 [26]).
SMTP回复是一种应答（肯定或否定），通过传输通道以“行”形式从接收方发送到发送方，以响应命令。回复的一般形式是数字完成码（表示失败或成功），通常后跟文本字符串。代码供程序使用，文本通常供人类用户使用。RFC 3463[25]规定了回复字符串的进一步结构，包括使用补充和更具体的完成代码（另请参见RFC 5248[26]）。
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).
行由零个或多个数据字符组成，以序列ASCII字符“CR”（十六进制值0D）结尾，后跟ASCII字符“LF”（十六进制值0A）。该终止顺序在本文件中表示为<CRLF>。一致性实现不得识别或生成任何其他字符或字符序列作为行终止符。服务器可能会对线路长度施加限制（见第4节）。
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>序列传输它们。
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 the message header section and the possibly structured message body. The MIME specification (RFC 2045 [21]) provides the standard mechanisms for structured message bodies.
在本文件中，术语“消息内容”和“邮件数据”可互换使用，用于描述在接受数据命令后和传输数据结束指示之前传输的材料。消息内容包括消息头部分和可能结构化的消息体。MIME规范（RFC 2045[21]）为结构化消息体提供了标准机制。
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 that 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 RFC 2979 [27]).
“网关”SMTP系统（通常称为“网关”）从一个传输环境中的客户端系统接收邮件，并将其传输到另一个传输环境中的服务器系统。网关两侧传输环境之间的协议或消息语义差异可能要求网关系统对SMTP中继系统不允许的消息执行转换。在本规范中，重写地址的防火墙应被视为网关，即使它们的两侧都使用SMTP（参见RFC 2979[27]）。
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
在本规范中，“地址”是一个字符串，用于标识邮件将发送到的用户或邮件将存放到的位置。“邮箱”一词是指该保管机构。这两个术语通常可以互换使用，除非邮件放置位置（邮箱）和对其的引用（地址）之间的区别很重要。地址通常由用户和域规范组成。标准邮箱命名约定定义为“本地”-part@domain"; 与简单的“用户名”相比，现代使用允许更广泛的应用程序集。因此，由于中间主机在尝试
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.
通过修改本地部分来优化传输，本地部分必须仅由地址的域部分中指定的主机解释和分配语义。
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 are required following 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. 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. 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. Mailbox domains follow normal DNS rules and are hence not case sensitive.
动词和参数值（例如，RCPT命令中的“TO:”或“TO:”以及扩展名关键字）不区分大小写，本规范中唯一的例外是邮箱本地部分（SMTP扩展可能明确指定区分大小写的元素）。也就是说，命令动词、参数值（邮箱本地部分除外）和自由格式文本可以用大写、小写或大写和小写的任意组合进行编码，而不会影响其含义。邮箱的本地部分必须视为区分大小写。因此，SMTP实现必须注意保留邮箱本地部分的情况。特别是，对于某些主机，用户“smith”与用户“smith”不同。但是，利用邮箱本地部分的大小写敏感性会妨碍互操作性，因此不鼓励这样做。邮箱域遵循正常的DNS规则，因此不区分大小写。
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 clause 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.
argument子句由以行尾结尾的可变长度字符串组成，即以字符序列<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 [6]. 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 7-bit
命令和回复由ASCII字符集的字符组成[6]。当传输服务提供8位字节（八位字节）传输通道时，每个7位字符在八位字节中传输，右对齐，高阶位清除为零。更具体地说，未扩展的SMTP服务提供7位
transport only. An originating SMTP client that has not successfully negotiated an appropriate extension with a particular server (see the next paragraph) 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 the ultimate delivery of a severely garbled message to the recipient. Delivery SMTP systems MAY reject such messages, or return them as undeliverable, rather than deliver them. In the absence of a server-offered extension explicitly permitting it, a sending SMTP system is not permitted to send envelope commands in any character set other than US-ASCII. Receiving systems SHOULD reject such commands, normally using "500 syntax error - invalid character" replies.
仅限运输。未成功与特定服务器协商适当扩展的原始SMTP客户端（请参阅下一段）不得传输包含八位字节高位信息的消息。如果此类邮件的传输违反了此规则，则接收SMTP服务器可能会清除高阶位或将邮件视为无效而拒绝。通常，SMTP中继应该假定它接收到的邮件内容是有效的，并且假定信封允许这样做，则在不检查该内容的情况下中继它。当然，如果内容被错误标记，并且数据路径无法接受实际内容，这可能会导致最终向收件人发送严重混乱的消息。传递SMTP系统可能会拒绝此类邮件，或将其返回为无法传递，而不是传递。在没有服务器提供的扩展明确允许的情况下，发送SMTP系统不允许以US-ASCII以外的任何字符集发送信封命令。接收系统应拒绝此类命令，通常使用“500语法错误-无效字符”回复。
8-bit message content transmission MAY be requested of the server by a client using extended SMTP facilities, notably the "8BITMIME" extension, RFC 1652 [22]. 8BITMIME SHOULD be supported by SMTP servers. However, it MUST NOT be construed as authorization to transmit unrestricted 8-bit material, nor does 8BITMIME authorize transmission of any envelope material in other than ASCII. 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.
8位消息内容传输可由客户端使用扩展SMTP设施（尤其是“8BITMIME”扩展RFC 1652[22]）向服务器请求。SMTP服务器应支持8BITMIME。但是，不得将其解释为授权传输不受限制的8位材料，也不得将8BITMIME授权传输ASCII以外的任何信封材料。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 in RFC 5234 [7]. Metalanguage terms used in running text are surrounded by pointed brackets (e.g., <CRLF>) for clarity. The reader is cautioned that the grammar expressed in the metalanguage is not comprehensive. There are many instances in which provisions in the text constrain or otherwise modify the syntax or semantics implied by the grammar.
本文档中使用的元语言符号对应于其他Internet邮件系统文档中使用的“增强BNF”。不熟悉该语法的读者应参考RFC 5234[7]中的ABNF规范。为清晰起见，运行文本中使用的元语言术语被尖括号（例如，<CRLF>）包围。读者应注意，元语言所表达的语法并不全面。在许多情况下，文本中的规定限制或以其他方式修改语法隐含的语法或语义。
This section contains descriptions of the procedures used in SMTP: session initiation, mail transaction, forwarding mail, verifying mailbox names and expanding mailing lists, and 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).
SMTP服务器实现可能包括在220代码后的连接回复中标识其软件和版本信息，这一做法允许更有效地隔离和修复任何问题。实施可能会为SMTP服务器做出规定，以便在软件和版本公告引起安全问题时禁用该软件和版本公告。虽然一些系统也会识别邮件问题的联系点，但这并不能代替维护所需的“邮政局长”地址（参见第4节）。
The SMTP protocol allows a server to formally reject a mail session 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 "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.
SMTP协议允许服务器正式拒绝邮件会话，同时仍允许初始连接，如下所示：初始连接打开消息中可能会给出554响应，而不是220响应。采用这种方法的服务器在关闭连接之前必须等待客户端发送QUIT（参见第4.1.1.10节），并应使用“503错误命令序列”响应任何干预命令。由于尝试与此类系统建立SMTP连接可能出错，因此在打开连接时返回554响应的服务器应在回复文本中提供足够的信息，以便于调试发送系统。
Once the server has sent the greeting (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 that are unable to support service extensions, and contemporary clients that 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 that 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邮件事务处理分为三个步骤。事务以一个提供发件人标识的邮件命令开始。（通常，只有在没有进行邮件交易时，才可以发送邮件命令；请参见第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 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.
此命令告知SMTP收件人新邮件事务正在启动，并重置其所有状态表和缓冲区，包括任何收件人或邮件数据。第一个或唯一参数的<reverse path>部分包含源邮箱（在“<”和“>”括号之间），可用于报告错误（有关错误报告的讨论，请参阅第4.2节）。如果接受，SMTP服务器将返回“250确定”回复。如果邮箱规范因某种原因不可接受，服务器必须返回一个回复，指示故障是永久性的（即，如果客户端再次尝试发送相同的地址，故障将再次发生）还是临时性的（即，如果客户端稍后再次尝试，地址可能会被接受）。尽管本要求的范围很明显，但在某些情况下，只有检查一条或多条正向路径（在RCPT命令中）才能确定反向路径的可接受性。在这些情况下，服务器可以合理地接受反向路径（回复250），然后在接收和检查正向路径后报告问题。通常，失败会产生550或553个回复。
Historically, the <reverse-path> was permitted to 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. This step of the procedure can be repeated any number of times.
该过程的第二步是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
此命令的第一个或唯一参数包括标识一个收件人的转发路径（通常是邮箱和域，始终用“<”和“>”括号括起来）。如果接受，SMTP服务器将返回“250确定”回复并存储转发路径。如果
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).
如果已知收件人不是可交付地址，SMTP服务器将返回550个回复，通常带有“无此类用户”等字符串和邮箱名称（可能存在其他情况和回复代码）。
The <forward-path> can contain more than just a mailbox. Historically, the <forward-path> was permitted to contain 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 they 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节）。
Since it has been a common source of errors, it is worth noting that spaces are not permitted on either side of the colon following FROM in the MAIL command or TO in the RCPT command. The syntax is exactly as given above.
由于它是常见的错误源，因此值得注意的是，在MAIL命令或RCPT命令中，在FROM后面的冒号两侧都不允许使用空格。语法与上面给出的完全相同。
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
邮件结束数据指示器还确认邮件事务，并通知SMTP服务器立即处理存储的收件人和邮件
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服务器将返回“250确定”回复。数据命令只能在协议交换中的两点失败：
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), 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 and, in particular, in Section 6.1. 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节，特别是第6.1节所述。在接受数据后使用“550邮箱未找到”（或等效）回复代码会使客户端难以或无法确定哪些收件人失败。
When the RFC 822 format ([28], [4]) is being used, the mail data include the header fields such as those named Date, Subject, To, Cc, and From. Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message header section or message body. In particular, they MUST NOT reject messages in which the numbers of Resent-header fields do not match or Resent-to appears without Resent-from and/or Resent-date.
当使用RFC 822格式（[28]、[4]）时，邮件数据包括标题字段，例如命名日期、主题、收件人、抄送和发件人。服务器SMTP系统不应基于RFC 822或MIME（RFC 2045[21]）邮件头部分或邮件正文中的感知缺陷拒绝邮件。特别是，如果在没有“重新发送自”和/或“重新发送日期”的情况下，“重新发送头”字段的数量不匹配或“重新发送至”字段出现，则他们不得拒绝这些消息。
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 a 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
在企业和“新地址”两种情况下，信息隐藏（有时是安全性）考虑反对通过SMTP协议暴露“最终”地址作为转发活动的副作用。当
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 (see also Section 7.4).
发件人甚至可能无法访问最终地址。因此，RFC 821第3.2节中描述的“转发”机制，尤其是RCPT的251（纠正的目的地）和551应答码，必须由实施者仔细评估，并且在可用时，由配置系统仔细评估（另见第7.4节）。
In particular:
特别地：
o 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. However, 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.
o 服务器在知道地址更改时可以转发消息。当它们这样做时，它们可以提供带有251代码的地址更新信息，或者可以“静默”转发并返回250代码。但是，如果使用251代码，则它们不能假设客户端将实际更新地址信息，甚至不能将该信息返回给用户。
Alternately,
或者，
o Servers MAY reject messages or return them as non-deliverable when they cannot be delivered precisely as 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. However, 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.
o 服务器可能会拒绝邮件，或者在无法按地址准确传递邮件时将其作为不可传递邮件返回。当他们这样做时，他们可能会提供带有551代码的地址更新信息，或者可能会拒绝带有550代码且没有地址特定信息的无法送达的消息。但是，如果使用了551代码，他们不能假设客户机将实际更新地址信息，甚至不能将该信息返回给用户。
SMTP server implementations that support the 251 and/or 551 reply codes SHOULD provide configuration mechanisms so that sites that 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 Section 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 responses 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 RFC 3463 [25], 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 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.
在正常情况下，接收553回复的客户端将向用户公开结果。准确使用给定的表格和“用户不明确”或“不明确”关键字（可能由扩展回复代码补充，如RFC 3463[25]中所述）将有助于根据需要自动翻译成其他语言。当然，高度自动化的客户机或使用英语以外的其他语言操作的客户机可能会选择尝试翻译响应，以向用户返回回复文字以外的其他指示，或者采取一些自动操作，例如在向用户报告之前咨询目录服务以获取更多信息。
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
在某些主机中，单个邮箱的邮件列表和别名之间的区别有点模糊，因为公共数据结构可能包含这两种类型的条目，并且邮件列表可能只包含一个邮箱。如果请求将VRFY应用于邮件列表，则如果如此寻址的邮件将发送给列表上的每个人，则可能会给出肯定的响应，否则应报告错误（例如，“550是邮件列表，而不是用户”或“252无法验证邮件列表的成员”）。如果请求展开用户名，服务器可能会返回
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").
由包含一个名称的列表组成的肯定响应，或者可能报告错误（例如，“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 MUST include the <Mailbox> name using a "<local-part@domain>" construction, where "domain" is a fully-qualified domain name. 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
当从VRFY或EXPN请求返回正常（2yz或551）响应时，响应必须包括使用“<local”的<Mailbox>名称-part@domain>“域名”是一个完全限定的域名。在足以证明违反本规范意图的特殊情况下，可返回自由格式文本。为了便于两台计算机进行分析
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.
和人，地址应该出现在尖括号内。当返回地址而不是自由形式的调试信息时，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 (see Section 7.3). 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, but VRFY was made mandatory in RFC 1123 [3], if EXPN is supported, it MUST be listed as a service extension in an EHLO response. VRFY MAY be listed as a convenience but, since support for it is required, SMTP clients are not required to check for its presence on the extension list before using it.
服务器实现应同时支持VRFY和EXPN。出于安全原因，实施可以通过配置选项或等效选项（见第7.3节）为本地安装提供禁用其中一个或两个命令的方法。当支持这些命令时，当支持中继时，它们不需要跨继电器工作。由于它们在RFC 821中都是可选的，但在RFC 1123[3]中VRFY是强制性的，因此如果支持EXPN，则必须在EHLO响应中将其列为服务扩展。列出VRFY可能是为了方便，但由于需要对它的支持，SMTP客户端在使用它之前不需要检查它是否存在于扩展列表中。
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 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 rejected 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记录）、邮箱（各种类型的本地主机别名）以及各种代理安排，邮件别名系统的传播使得这些策略几乎不可能始终如一地工作，邮件系统不应尝试这些策略。
In general, the availability of Mail eXchanger records in the domain name system (RFC 1035 [2], RFC 974 [12]) makes the use of explicit source routes in the Internet mail system unnecessary. Many historical problems with the interpretation of explicit source routes 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 MAY 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.
通常，域名系统中邮件交换记录的可用性（RFC 1035[2]，RFC 974[12]）使得在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
中继SMTP服务器通常是指定它的DNS MX记录的目标，而不是最终传递系统。中继服务器可以接受或拒绝转发邮件的任务，其方式与为本地用户接受或拒绝邮件的方式相同。如果它接受任务，则它将成为SMTP客户端，建立到DNS中指定的下一个SMTP服务器的传输通道（根据第5节中的规则），并向其发送邮件。如果它拒绝
relay mail to a particular address for policy reasons, a 550 response SHOULD be returned.
由于政策原因，将邮件转发到特定地址时，应返回550回复。
This specification does not deal with the verification of return paths for use in delivery notifications. Recent work, such as that on SPF [29] and DKIM [30] [31], has been done to provide ways to ascertain that an address is valid or belongs to the person who actually sent the message. A server MAY attempt to verify the return path before using its address for delivery notifications, but methods of doing so are not defined here nor is any particular method recommended at this time.
本规范不涉及传递通知中使用的返回路径的验证。最近的工作，例如关于SPF[29]和DKIM[30][31]的工作，已经完成，以提供确定地址有效或属于实际发送消息的人的方法。服务器可能会在使用其地址发送通知之前尝试验证返回路径，但此处未定义验证方法，目前也不推荐任何特定方法。
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. A standardized mail submission protocol has been developed that is gradually superseding practices based on SMTP (see RFC 4409 [18]). In any event, because these arrangements are private and fall outside the scope of this specification, they are not described here.
存在许多邮件发送客户端，特别是与通过POP3或IMAP接收邮件的设施结合使用时，这些客户端的能力有限，无法支持本规范的某些要求，例如将邮件排队等待后续的传递尝试。对于这些客户机，通常的做法是进行私人安排，将所有消息发送到单个服务器进行处理和后续分发。此处指定的SMTP不适合此角色。已经开发了一种标准化的邮件提交协议，该协议正在逐渐取代基于SMTP的实践（参见RFC 4409[18]）。在任何情况下，由于这些安排是私有的，不在本规范的范围内，因此此处不进行描述。
It is important to note that MX records can point to SMTP servers that act as gateways into other environments, not just SMTP relays and final delivery systems; see Sections 3.7 and 5.
需要注意的是，MX记录可以指向SMTP服务器，这些服务器充当到其他环境的网关，而不仅仅是SMTP中继和最终交付系统；见第3.7节和第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, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if possible.
如果SMTP服务器已接受转发邮件的任务，但后来发现目标不正确或邮件因其他原因无法送达，则必须构造“无法送达邮件”通知消息，并将其发送给无法送达邮件的发起人（如反向路径所示）。如果可能，应使用其他标准（例如，参见RFC 3461[32]和RFC 3464[33]）为未交付报告指定的格式。
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
此通知消息必须来自中继主机上的SMTP服务器或首先确定无法完成传递的主机。当然，SMTP服务器不得发送有关传输通知消息时出现问题的通知消息。防止错误报告中出现循环的一种方法是在通知消息的MAIL命令中指定空反向路径。传输此类消息时，反向路径必须设置为null（请参阅
Section 4.5.5 for additional discussion). A MAIL command with a null reverse-path appears as follows:
第4.5.5节进行补充讨论）。具有空反向路径的邮件命令如下所示：
MAIL FROM:<>
MAIL FROM:<>
As discussed in Section 6.4, a relay SMTP has no need to inspect or act upon the header section or body of the message data and MUST NOT do so except to add its own "Received:" header field (Section 4.4) and, optionally, to attempt to detect looping in the mail system (see Section 6.3). Of course, this prohibition also applies to any modifications of these header fields or text (see also Section 7.9).
如第6.4节所述，中继SMTP无需检查或操作邮件数据的标题部分或正文，除非添加自己的“Received:”标题字段（第4.4节），或者尝试检测邮件系统中的循环（参见第6.3节）。当然，该禁令也适用于对这些标题字段或文本的任何修改（另见第7.9节）。
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.10, 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.10节所述，当此类系统位于两个传输服务环境之间的边界时，我们将其称为“网关”或“网关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 6.4.
必要时可以重写标题字段，因为邮件通过网关跨越邮件环境边界。这可能涉及检查消息正文或解释目标地址的本地部分，尽管第6.4节有禁止规定。
Other mail systems gatewayed to the Internet often use a subset of the RFC 822 header section 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 section. 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 section.
在将消息转发到Internet环境中或从Internet环境中转发出去时，网关必须预先发送Received:行，但不得以任何方式更改已在标头部分中的Received:行。
"Received:" header 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 header fields arising in non-SMTP environments, receiving systems MUST NOT reject mail based on the format of a trace header field and SHOULD be extremely robust in the light of unexpected information or formats in those header fields.
“Received:”来自其他环境的消息的标题字段可能不完全符合此规范。然而，Received:行最重要的用途是用于调试邮件故障，而这种调试可能会受到试图“修复”Received:行的善意网关的严重阻碍。非SMTP环境中出现的跟踪头字段的另一个后果是，接收系统不得基于跟踪头字段的格式拒绝邮件，并且鉴于这些头字段中的意外信息或格式，接收系统应非常健壮。
The gateway SHOULD indicate the environment and protocol in the "via" clauses of Received header field(s) that it supplies.
网关应在其提供的接收报头字段的“via”子句中指示环境和协议。
From the Internet side, the gateway SHOULD accept all valid address formats in SMTP commands and in the RFC 822 header section, and all valid RFC 822 messages. Addresses and header fields generated by gateways MUST conform to applicable standards (including this one and RFC 5322 [4]). 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 5322[4]）。当然，网关处理源路由的规则与第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., header fields MUST be transformed (if necessary) to satisfy the standard header syntax of RFC 5322 [4], 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 reverse-path from the SMTP envelope, not to an address in the "From:", "Sender:", or similar header fields of the message.
网关必须确保转发到Internet邮件环境的邮件的所有头字段都满足Internet邮件的要求。特别是，“From:”、“To:”、“Cc:”等标题字段中的所有地址必须进行转换（如有必要），以满足RFC 5322[4]的标准标题语法，必须仅引用完全限定的域名，并且必须对发送回复有效且有用。用于将邮件从Internet协议转换为其他环境的协议的转换算法应确保来自外部邮件环境的错误消息从SMTP信封传递到反向路径，而不是传递到消息的“发件人：”或类似标头字段中的地址。
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 under normal operational circumstances (see Section 7.8) except:
SMTP服务器不得在正常操作情况下有意关闭连接（参见第7.8节），除非：
o After receiving a QUIT command and responding with a 221 reply.
o 在收到QUIT命令并以221回复进行响应之后。
o 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).
o 检测到需要关闭SMTP服务并返回421响应代码后。此响应代码可以在服务器接收到任何命令后发出，或者在必要时从命令接收异步发出（假设客户机将在下一个命令发出后接收）。
o After a timeout, as specified in Section 4.5.3.2, occurs waiting for the client to send a command or data.
o 如第4.5.3.2节所述，在等待客户端发送命令或数据时发生超时。
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 that 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 section (RFC 5322 [4]) MUST be left unchanged; in particular, the "From" field of the header section is unaffected.
支持SMTP的主机应同时支持别名和地址扩展列表模式，以便进行多次传递。当邮件发送或转发到扩展列表表单的每个地址时，信封中的返回地址（“邮件发件人：”）必须更改为管理列表的个人或其他实体的地址。然而，在这种情况下，消息头部分（RFC 5322[4]）必须保持不变；特别是，标题部分的“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 each of the expanded addresses in turn. The return (backward-pointing) 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. Note that the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the backward-pointing address in this case. When a list constrains its processing to the very limited set of modifications and actions described here, it is attempting to emulate an MTA; such lists can be treated as a continuation in email transit.
邮件列表可以说是通过“再分配”而不是“转发”来运行的。要展开列表，收件人邮件程序将依次用每个展开的地址替换信封中的伪邮箱地址。信封中的返回（反向指向）地址已更改，因此最终交付生成的所有错误消息将返回给列表管理员，而不是消息发起人，后者通常无法控制列表的内容，并且通常会发现错误消息令人讨厌。请注意，处理别名（第3.9.1节）和转发（本小节）之间的关键区别在于在这种情况下对反向地址的更改。当列表将其处理限制为此处描述的非常有限的一组修改和操作时，它正试图模拟MTA；这样的列表可以作为电子邮件传输的延续。
There exist mailing lists that perform additional, sometimes extensive, modifications to a message and its envelope. Such mailing lists need to be viewed as full MUAs, which accept a delivery and post a new message.
存在对邮件及其信封进行额外（有时是广泛）修改的邮件列表。这样的邮件列表需要被视为完整的MUA，它接受传递并发布新消息。
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 SHOULD 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 that 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 that 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 clause 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).
可用），客户端应发送地址文本（见第4.1.3节）。
RFC 2821, and some earlier informal practices, encouraged following the literal by information that would help to identify the client system. That convention was not widely supported, and many SMTP servers considered it an error. In the interest of interoperability, it is probably wise for servers to be prepared for this string to occur, but SMTP clients SHOULD NOT send it.
RFC 2821和一些早期的非正式实践鼓励遵循文字，因为这些信息有助于识别客户机系统。该约定没有得到广泛支持，许多SMTP服务器认为这是一个错误。出于互操作性的考虑，服务器为该字符串的出现做好准备可能是明智的，但SMTP客户端不应发送该字符串。
The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command.
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 / address-literal ) CRLF
ehlo=“ehlo”SP（域/地址文字）CRLF
helo = "HELO" SP Domain 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 keywords 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 RFC 5234 [7], is:
通常，对EHLO的响应将是多行回复。响应的每一行都包含一个关键字和一个或多个参数（可选）。按照多行回复的正常语法，这些关键字后面紧跟着代码（250）和连字符（最后一行除外），后面紧跟着代码和空格（最后一行除外）。使用RFC 5234[7]中的ABNF符号和终端符号，肯定响应的语法为：
ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
/ ( "250-" Domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
ehlo-ok-rsp = ( "250" SP 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-126)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 and 127
; inclusive)
ehlo-param = 1*(%d33-126)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 and 127
; 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.
尽管可以用大写、小写或混合大写指定EHLO关键字，但必须始终以不区分大小写的方式识别和处理它们。这只是RFC 821和第2.4节中规定的实践的扩展。
The EHLO response MUST contain keywords (and associated parameters if required) for all commands not listed as "required" in Section 4.5.1 excepting only private-use commands as described in Section 4.1.5. Private-use commands MAY be listed.
EHLO响应必须包含第4.5.1节中未列为“必需”的所有命令的关键字（以及相关参数，如果需要），第4.1.5节中所述的专用命令除外。可以列出专用命令。
This command is used to initiate a mail transaction in which the mail data is delivered to an SMTP server that may, in turn, deliver it to one or more mailboxes or pass it on to another system (possibly using SMTP). The argument clause 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）。argument子句包含反向路径，并且可能包含可选参数。通常，只有在没有邮件事务进行时，才能发送邮件命令，请参见第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 non-delivery notifications), the reverse-path may be null (see Section 3.6).
反向路径由发件人邮箱组成。从历史上看，该邮箱前面可能会有一个主机列表，但这种行为现在已被弃用（请参见附录C）。在回复可能导致邮件循环的某些类型的报告邮件（例如，邮件传递和未传递通知）中，反向路径可能为空（参见第3.6节）。
This command clears the reverse-path buffer, the forward-path buffer, and the mail data buffer, and it inserts the reverse-path information from its argument clause 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 = "MAIL FROM:" Reverse-path [SP Mail-parameters] CRLF
mail=“邮件发件人：”反向路径[SP邮件参数]CRLF
This command is used to identify an individual recipient of the mail data; multiple recipients are specified by multiple uses of this command. The argument clause contains a forward-path and may contain optional parameters.
此命令用于标识邮件数据的单个收件人；此命令的多次使用指定了多个收件人。argument子句包含转发路径，并且可能包含可选参数。
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服务器将根据其主机邮件约定将其插入目标邮箱。
This command appends its forward-path argument to the forward-path buffer; it does not change the reverse-path buffer nor the mail data buffer.
此命令将其正向路径参数附加到正向路径缓冲区；它不会更改反向路径缓冲区或邮件数据缓冲区。
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>
Attempting to use relaying this way is now strongly discouraged. 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 = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" /
Forward-path ) [SP Rcpt-parameters] CRLF
rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" /
Forward-path ) [SP Rcpt-parameters] CRLF
Note that, in a departure from the usual rules for local-parts, the "Postmaster" string shown above is treated as case-insensitive.
注意，与本地部分的常规规则不同，上面显示的“Postmaster”字符串被视为不区分大小写。
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 are terminated by a line containing only a period, that is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is actually the terminator of the previous line (see Section 4.5.2). This is the end of mail data indication. 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 mail data, ends the DATA command itself (the "no mail data" case does not conform to this specification since it would require that neither the trace header fields required by this specification nor the message header section required by RFC 5322 [4] be transmitted). 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
邮件数据由仅包含句点的行终止，即字符序列“<CRLF><CRLF>”，其中第一个<CRLF>实际上是前一行的终止符（参见第4.5.2节）。这是邮件结束数据指示。此终止序列的第一个<CRLF>也是结束数据（消息文本）最后一行的<CRLF>，或者，如果没有邮件数据，则结束数据命令本身（“无邮件数据”）案例不符合本规范，因为它要求既不传输本规范要求的跟踪头字段，也不传输RFC 5322[4]要求的消息头部分）。不得添加额外的<CRLF>，因为这将导致在消息中添加空行。如果消息
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.
正文被传递给原始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 "250 OK" 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模型此时不允许部分失败：服务器接受邮件进行传递并返回肯定响应，或者不接受邮件并返回失败响应。在向数据结束指示发送肯定的“250 OK”完成回复时，接收方对该消息承担全部责任（见第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 = "DATA" CRLF
data=“data”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., it 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 = "RSET" CRLF
rset=“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 = "VRFY" SP String CRLF
vrfy=“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 it may be issued at any time.
此命令对反向路径缓冲区、正向路径缓冲区或邮件数据缓冲区没有影响，可以随时发出。
Syntax:
语法：
expn = "EXPN" SP String CRLF
expn=“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 it may be issued at any time.
此命令对反向路径缓冲区、正向路径缓冲区或邮件数据缓冲区没有影响，可以随时发出。
SMTP servers SHOULD support HELP without arguments and MAY support it with arguments.
SMTP服务器应支持不带参数的帮助，并可能支持带参数的帮助。
Syntax:
语法：
help = "HELP" [ SP String ] CRLF
help=“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 a "250 OK" reply.
此命令不影响任何参数或以前输入的命令。它只指定接收方发送“250 OK”回复，而不指定其他操作。
This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer, and it may be issued at any time. If a parameter string is specified, servers SHOULD ignore it.
此命令对反向路径缓冲区、正向路径缓冲区或邮件数据缓冲区没有影响，可以随时发出。如果指定了参数字符串，服务器应该忽略它。
Syntax:
语法：
noop = "NOOP" [ SP String ] CRLF
noop=“noop”[SP String]CRLF
This command specifies that the receiver MUST send a "221 OK" reply, and then close the transmission channel.
此命令指定接收器必须发送“221 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 it 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. Any current uncompleted mail transaction will be aborted.
可以随时发出QUIT命令。任何当前未完成的邮件事务都将被中止。
Syntax:
语法：
quit = "QUIT" CRLF
quit=“quit”CRLF
If the server SMTP does not recognize or cannot implement one or more of the parameters associated with a particular MAIL FROM or RCPT TO command, it will return code 555.
如果服务器SMTP无法识别或无法实现与特定邮件发件人或RCPT TO命令关联的一个或多个参数，它将返回代码555。
If, for some reason, the server is temporarily unable to accommodate one or more of the parameters associated with a MAIL FROM or RCPT TO command, and if the definition of the specific parameter does not mandate the use of another code, it should return code 455.
如果由于某种原因，服务器暂时无法容纳与“邮件发件人”或“RCPT to”命令相关联的一个或多个参数，并且如果特定参数的定义不强制使用其他代码，则服务器应返回代码455。
Errors specific to particular parameters and their values will be specified in the parameter's defining RFC.
特定于特定参数及其值的错误将在参数的定义RFC中指定。
The syntax of the argument clauses of the above commands (using the syntax specified in RFC 5234 [7] 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 in Section 6 of RFC 5234 [7] or in the message format syntax in RFC 5322 [4].
下面给出了上述命令的参数子句的语法（使用RFC 5234[7]中规定的语法，如适用）。以下给出的一些产品仅与附录C中所述的源路由一起使用。本文件中未定义的终端，如ALPHA、DIGIT、SP、CR、LF、CRLF，如RFC 5234[7]第6节中的“核心”语法或RFC 5322[4]中的消息格式语法所定义。
Reverse-path = Path / "<>"
Reverse-path = Path / "<>"
Forward-path = Path
Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">"
Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," At-domain )
; Note that this form, the so-called "source
; route", MUST BE accepted, SHOULD NOT be
; generated, and SHOULD be ignored.
A-d-l = At-domain *( "," At-domain )
; Note that this form, the so-called "source
; route", MUST BE accepted, SHOULD NOT be
; generated, and SHOULD be ignored.
At-domain = "@" Domain
At domain=“@”域
Mail-parameters = esmtp-param *(SP esmtp-param)
邮件参数=esmtp参数*（SP esmtp参数）
Rcpt-parameters = esmtp-param *(SP esmtp-param)
Rcpt参数=esmtp参数*（SP esmtp参数）
esmtp-param = esmtp-keyword ["=" esmtp-value]
esmtp参数=esmtp关键字[“=”esmtp值]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value = 1*(%d33-60 / %d62-126)
; any CHAR excluding "=", SP, and control
; characters. If this string is an email address,
; i.e., a Mailbox, then the "xtext" syntax [32]
; SHOULD be used.
esmtp-value = 1*(%d33-60 / %d62-126)
; any CHAR excluding "=", SP, and control
; characters. If this string is an email address,
; i.e., a Mailbox, then the "xtext" syntax [32]
; SHOULD be used.
Keyword = Ldh-str
Keyword = Ldh-str
Argument = Atom
Argument = Atom
Domain = sub-domain *("." sub-domain)
域=子域*（“”子域）
sub-domain = Let-dig [Ldh-str]
子域=Let dig[Ldh str]
Let-dig = ALPHA / DIGIT
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
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 / address-literal )
Mailbox = Local-part "@" ( Domain / address-literal )
Local-part = Dot-string / Quoted-string ; MAY be case-sensitive
局部部分=点字符串/带引号的字符串；可能区分大小写
Dot-string = Atom *("." Atom)
点字符串=原子*（“”原子）
Atom = 1*atext
Atom = 1*atext
Quoted-string = DQUOTE *QcontentSMTP DQUOTE
Quoted string=DQUOTE*QcontentSMTP DQUOTE
QcontentSMTP = qtextSMTP / quoted-pairSMTP
QcontentSMTP = qtextSMTP / quoted-pairSMTP
quoted-pairSMTP = %d92 %d32-126
; i.e., backslash followed by any ASCII
; graphic (including itself) or SPace
quoted-pairSMTP = %d92 %d32-126
; i.e., backslash followed by any ASCII
; graphic (including itself) or SPace
qtextSMTP = %d32-33 / %d35-91 / %d93-126
; i.e., within a quoted string, any
; ASCII graphic or space is permitted
; without blackslash-quoting except
; double-quote and the backslash itself.
qtextSMTP = %d32-33 / %d35-91 / %d93-126
; i.e., within a quoted string, any
; ASCII graphic or space is permitted
; without blackslash-quoting except
; double-quote and the backslash itself.
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
系统不得以要求在SMTP中使用非ASCII字符（具有高阶位集的八位字节）的方式定义邮箱
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.
一个）或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 name string with the comma being the fourth character of that string.
请注意，反斜杠“\”是一个引号字符，用于指示下一个字符将按字面意思使用（而不是其正常解释）。例如，“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, RFC 1035 [2]), characters outside the set of alphabetic characters, 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 (this rule, like others, could be overridden by appropriate SMTP extensions).
为了促进互操作性，并与有关在命名和应用程序中保守使用DNS的长期指导一致（例如，请参阅基本DNS文档RFC 1035[2]第2.3.1节），SMTP客户端或服务器的域名标签中不得出现字母、数字和连字符集之外的字符。特别是，不允许使用下划线字符。如果SMTP服务器接收的命令中使用了无效字符代码，并且没有其他拒绝原因，则必须以501响应拒绝该命令（与其他规则一样，此规则可以由适当的SMTP扩展名覆盖）。
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 relevant standards (i.e., RFC 4291 [8] for IPv6).
有时，域名系统不知道某个主机，通信（尤其是报告和修复错误的通信）被阻止。为了绕过这一障碍，允许使用地址的特殊文字形式作为域名的替代。对于IPv4地址，这种形式使用四个小的十进制整数，用点分隔，并用括号括起来，如[123.255.37.2]，它以八位字节形式表示（IPv4）互联网地址。对于IPv6和其他可能最终标准化的寻址形式，该形式由一个标准化的“标记”组成，该标记以作为相关标准一部分的格式标识地址语法、冒号和地址本身（即，IPv6的RFC 4291[8]）。
Specifically:
明确地：
IPv4-address-literal = Snum 3("." Snum)
IPv4地址文字=Snum 3（“.”Snum）
IPv6-address-literal = "IPv6:" IPv6-addr
IPv6地址literal=“IPv6:”IPv6地址
General-address-literal = Standardized-tag ":" 1*dcontent
General-address-literal = Standardized-tag ":" 1*dcontent
Standardized-tag = Ldh-str ; Standardized-tag MUST be specified in a ; Standards-Track RFC and registered with IANA
标准化标记=Ldh str；标准化标签必须在a中指定；标准跟踪RFC并在IANA注册
dcontent = %d33-90 / ; Printable US-ASCII
%d94-126 ; excl. "[", "\", "]"
dcontent = %d33-90 / ; Printable US-ASCII
%d94-126 ; excl. "[", "\", "]"
Snum = 1*3DIGIT
; representing a decimal integer
; value in the range 0 through 255
Snum = 1*3DIGIT
; representing a decimal integer
; value in the range 0 through 255
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
IPv6-hex = 1*4HEXDIG
IPv6-hex = 1*4HEXDIG
IPv6-full = IPv6-hex 7(":" IPv6-hex)
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.
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-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.
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.
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 and the EHLO command is acceptable to the SMTP server, 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服务器可以接受EHLO命令，则SMTP服务器必须清除所有缓冲区并重置状态，就像发出RSET命令一样。换言之，紧跟EHLO的RSET序列是冗余的，但除了执行不必要命令的性能成本之外，没有其他危害。
If the EHLO command is not acceptable to the SMTP server, 501, 500, 502, or 550 failure replies MUST be returned as appropriate. The
如果SMTP服务器不接受EHLO命令，则必须根据需要返回501、500、502或550失败回复。这个
SMTP server MUST stay in the same state after transmitting these replies that it was in before the EHLO was received.
SMTP服务器在传输这些回复后必须保持与收到EHLO之前相同的状态。
The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a primary host name as specified for this command in Section 2.3.5. 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.
如果可能，SMTP客户端必须确保EHLO命令的域参数是第2.3.5节为此命令指定的主主机名。如果这是不可能的（例如，当客户端的地址是动态分配的，并且客户端没有明显的名称时），则应使用地址文本替换域名。
An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. Information captured in the verification attempt is for logging and tracing purposes. Note that this prohibition applies to the matching of the parameter to its IP address only; see Section 7.9 for a more extensive discussion of rejecting incoming connections or mail messages.
SMTP服务器可以验证EHLO命令中的域名参数是否实际对应于客户端的IP地址。但是，如果验证失败，服务器不得基于此拒绝接受消息。验证尝试中捕获的信息用于记录和跟踪目的。请注意，此禁止仅适用于参数与其IP地址的匹配；有关拒绝传入连接或邮件消息的更广泛讨论，请参见第7.9节。
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, a new EHLO, or the QUIT 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 if the previous one successfully concluded with a successful DATA command, or if the previous one was aborted, e.g., with a RSET or new EHLO.
MAIL命令（或过时的SEND、SOML或SAML命令）开始邮件事务。一旦启动，邮件事务将按顺序由事务开始命令、一个或多个RCPT命令和一个数据命令组成。邮件事务可以通过RSET、新的EHLO或QUIT命令中止。一个会话中可能有零个或多个事务。如果邮件事务已打开，则不得发送邮件（或SEND、SOML或SAML），也就是说，只有在会话中未启动邮件事务，或者前一个邮件事务通过成功的数据命令成功结束，或者前一个邮件事务被中止（例如，通过RSET或新的EHLO）时，才应发送邮件。
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
如果事务开始命令参数不可接受，则必须返回501失败回复，并且SMTP服务器必须保持相同状态。如果事务中的命令顺序错误到服务器无法处理的程度，则503失败
reply MUST be returned and the SMTP server MUST stay in the same state.
必须返回回复，并且SMTP服务器必须保持相同的状态。
The last command in a session MUST be the QUIT command. The QUIT command SHOULD be used by the client SMTP to request connection closure, even when no session opening command was sent and accepted.
会话中的最后一个命令必须是QUIT命令。客户端SMTP应使用QUIT命令请求关闭连接，即使未发送和接受任何会话打开命令。
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 the same section). Since, in violation of this specification, the text is sometimes not sent, clients that 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
SMTP回复由三位数字（以三个数字字符传输）和一些文本组成，除非本文档中另有规定。该数字用于自动机确定下一步要进入的状态；文本是供人类用户使用的。这三个数字包含足够的编码信息，SMTP客户端无需检查文本，可以丢弃文本或将其传递给用户（视情况而定）。例外情况如本文件其他部分所述。特别地，220、221、251、421和551应答码与必须由机器解析和解释的消息文本相关联。在一般情况下，文本可能依赖于接收者和上下文，因此每个回复代码可能有不同的文本。第4.2.1节对应答码理论进行了讨论。形式上，回复被定义为序列：三位代码、<SP>、一行文本和<CRLF>，或多行回复（定义见同一节）。由于违反此规范，文本有时不发送，因此未接收文本的客户端应准备单独处理代码（带或不带尾随空格字符）。在正常情况下，只有EHLO、EXPN和HELP命令才能生成多行回复
circumstances; however, multiline replies are allowed for any command.
情况；但是，任何命令都允许多行回复。
In ABNF, server responses are:
在ABNF中，服务器响应为：
Greeting = ( "220 " (Domain / address-literal)
[ SP textstring ] CRLF ) /
( "220-" (Domain / address-literal)
[ SP textstring ] CRLF
*( "220-" [ textstring ] CRLF )
"220" [ SP textstring ] CRLF )
Greeting = ( "220 " (Domain / address-literal)
[ SP textstring ] CRLF ) /
( "220-" (Domain / address-literal)
[ SP textstring ] CRLF
*( "220-" [ textstring ] CRLF )
"220" [ SP textstring ] CRLF )
textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
Reply-line = *( Reply-code "-" [ textstring ] CRLF )
Reply-code [ SP textstring ] CRLF
Reply-line = *( Reply-code "-" [ textstring ] CRLF )
Reply-code [ SP textstring ] CRLF
Reply-code = %x32-35 %x30-35 %x30-39
Reply-code = %x32-35 %x30-35 %x30-39
where "Greeting" appears only in the 220 response that announces that the server is opening its part of the connection. (Other possible server responses upon connection follow the syntax of Reply-line.)
其中，“问候语”仅出现在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必须准备好处理本文档中未指定的代码，并且必须仅解释第一位数字。
In the absence of extensions negotiated with the client, SMTP servers MUST NOT send reply codes whose first digits are other than 2, 3, 4,
在没有与客户端协商扩展的情况下，SMTP服务器不得发送第一位数字不是2、3、4的回复代码，
or 5. Clients that receive such out-of-range codes SHOULD normally treat them as fatal errors and terminate the mail transaction.
或5。收到此类超出范围代码的客户端通常应将其视为致命错误并终止邮件事务。
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 four values for the first digit of the reply code:
回复代码的第一位有四个值：
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 sender-SMTP agents) must agree on the interpretation. Each reply in this category might have a different time value, but the SMTP client SHOULD 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).
4yz瞬态否定完成回复命令未被接受，请求的操作未发生。但是，错误情况是暂时的，可能会再次请求该操作。发送方应返回到命令序列的开头（如果有）。当两个不同的站点（接收方和发送方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 SHOULD NOT repeat 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
5yz永久否定完成回复命令未被接受，请求的操作未发生。SMTP客户端不应重复确切的请求（以相同的顺序）。甚至一些“永久性”错误条件也可以更正，因此人工用户可能希望将SMTP客户端指向
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).
在将来的某个时候（例如，拼写已更改或用户已更改帐户状态后），通过直接操作重新初始化命令序列。
It is worth noting that the file transfer protocol (FTP) [34] uses a very similar code architecture and that the SMTP codes are based on the FTP model. However, SMTP uses a one-command, one-response model (while FTP is asynchronous) and FTP's 1yz codes are not part of the SMTP model.
值得注意的是，文件传输协议（FTP）[34]使用非常相似的代码体系结构，SMTP代码基于FTP模型。但是，SMTP使用一个命令、一个响应模型（而FTP是异步的），FTP的1yz代码不属于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:
例如：
250-First line 250-Second line 250-234 Text beginning with numbers 250 The last line
250第一行250第二行250-234以数字250开头的文本最后一行
In a multiline reply, the reply code on each of the lines MUST be the same. It is reasonable for the client to rely on this, so it can make processing decisions based on the code in any line, assuming that all others will be the same. 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.
在多行回复中，每行上的回复代码必须相同。客户机依赖于此是合理的，因此它可以根据任何一行中的代码做出处理决策，假设所有其他代码都是相同的。在少数情况下，回复“文本”中有客户的重要数据。客户机将能够从当前上下文中识别这些案例。
500 Syntax error, command unrecognized (This may include errors such as command line too long)
500语法错误，无法识别命令（这可能包括命令行过长等错误）
501 Syntax error in parameters or arguments
501参数或参数中的语法错误
502 Command not implemented (see Section 4.2.4)
502未执行命令（见第4.2.4节）
503 Bad sequence of commands
503命令顺序错误
504 Command parameter not implemented
504命令参数未实现
211 System status, or system help reply
211系统状态，或系统帮助回复
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)
214帮助消息（关于如何使用接收器或特定非标准命令含义的信息；此回复仅对人类用户有用）
220 <domain> Service ready
220<域>服务就绪
221 <domain> Service closing transmission channel
221<域>服务关闭传输信道
421 <domain> Service not available, closing transmission channel (This may be a reply to any command if the service knows it must shut down)
421<domain>服务不可用，关闭传输通道（如果服务知道它必须关闭，这可能是对任何命令的回复）
250 Requested mail action okay, completed
250请求的邮件操作正常，已完成
251 User not local; will forward to <forward-path> (See Section 3.4)
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)
252无法验证用户，但将接受消息并尝试传递（见第3.5.3节）
455 Server unable to accommodate parameters
455服务器无法容纳参数
555 MAIL FROM/RCPT TO parameters not recognized or not implemented
555从/RCPT发送至参数的邮件未识别或未实现
450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons)
450未执行请求的邮件操作：邮箱不可用（例如，邮箱忙或因策略原因暂时被阻止）
550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)
550未采取请求的操作：邮箱不可用（例如，未找到邮箱、没有访问权限或由于策略原因拒绝命令）
451 Requested action aborted: error in processing
451请求的操作已中止：处理中出错
551 User not local; please try <forward-path> (See Section 3.4)
551 User not local; please try <forward-path> (See Section 3.4)
452 Requested action not taken: insufficient system storage
452未采取请求的操作：系统存储不足
552 Requested mail action aborted: exceeded storage allocation
552请求的邮件操作中止：超出存储分配
553 Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect)
553未采取请求的操作：不允许使用邮箱名称（例如，邮箱语法不正确）
354 Start mail input; end with <CRLF>.<CRLF>
354 Start mail input; end with <CRLF>.<CRLF>
554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here")
554事务失败（或者，在连接打开响应的情况下，“此处没有SMTP服务”）
211 System status, or system help reply
211系统状态，或系统帮助回复
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)
214帮助消息（关于如何使用接收器或特定非标准命令含义的信息；此回复仅对人类用户有用）
220 <domain> Service ready
220<域>服务就绪
221 <domain> Service closing transmission channel
221<域>服务关闭传输信道
250 Requested mail action okay, completed
250请求的邮件操作正常，已完成
251 User not local; will forward to <forward-path> (See Section 3.4)
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)
252无法验证用户，但将接受消息并尝试传递（见第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)
421<domain>服务不可用，关闭传输通道（如果服务知道它必须关闭，这可能是对任何命令的回复）
450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons)
450未执行请求的邮件操作：邮箱不可用（例如，邮箱忙或因策略原因暂时被阻止）
451 Requested action aborted: local error in processing
451请求的操作已中止：处理中出现本地错误
452 Requested action not taken: insufficient system storage
452未采取请求的操作：系统存储不足
455 Server unable to accommodate parameters
455服务器无法容纳参数
500 Syntax error, command unrecognized (This may include errors such as command line too long)
500语法错误，无法识别命令（这可能包括命令行过长等错误）
501 Syntax error in parameters or arguments
501参数或参数中的语法错误
502 Command not implemented (see Section 4.2.4)
502未执行命令（见第4.2.4节）
503 Bad sequence of commands
503命令顺序错误
504 Command parameter not implemented
504命令参数未实现
550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)
550未采取请求的操作：邮箱不可用（例如，未找到邮箱、没有访问权限或由于策略原因拒绝命令）
551 User not local; please try <forward-path> (See Section 3.4)
551 User not local; please try <forward-path> (See Section 3.4)
552 Requested mail action aborted: exceeded storage allocation
552请求的邮件操作中止：超出存储分配
553 Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect)
553未采取请求的操作：不允许使用邮箱名称（例如，邮箱语法不正确）
554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here")
554事务失败（或者，在连接打开响应的情况下，“此处没有SMTP服务”）
555 MAIL FROM/RCPT TO parameters not recognized or not implemented
555从/RCPT发送至参数的邮件未识别或未实现
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代码）时，它将承担以下责任：
o delivering the message (if the recipient mailbox exists), or
o 传递邮件（如果收件人邮箱存在），或
o 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.
o 如果由于瞬态条件，尝试传递消息失败，则按照第4.5.4节规定的时间间隔，重新尝试传递消息的次数应合理。
o 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).
o 如果尝试传递邮件因永久性条件而失败，或者多次尝试传递邮件因暂时性条件而失败，则向原始邮件的发件人返回适当的通知（使用SMTP MAIL命令中的地址）。
When an SMTP server returns a temporary error status (4yz) code after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make a subsequent attempt to deliver that message. The SMTP client retains responsibility for the 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>完成后返回临时错误状态（4yz）代码时，它不得随后尝试传递该消息。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. 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 completed 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 of the message and response and appropriate intervention.
当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 Section 4.1.3 for a discussion of alternatives in these situations.
注意：所有问候语类型的回复都以服务器主机的正式名称（完全限定的主域名）作为回复代码后的第一个单词。有时主机将没有有意义的名称。关于这些情况下备选方案的讨论，见第4.1.3节。
For example,
例如
220 ISIF.USC.EDU Service ready
220 ISIF.USC.EDU服务就绪
or
或
220 mail.example.com SuperSMTP v 6.1.2 Service ready
220 mail.example.com SuperSMTP v 6.1.2服务就绪
or
或
220 [10.0.0.1] Clueless host service ready
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 meanings and actions implied by the code numbers and by the specific command reply sequence MUST be preserved.
替换回复中的文本，但必须保留代码编号和特定命令回复序列所暗示的含义和操作。
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. However, if the target is more precise granularity in the codes, rather than codes for completely new purposes, the system described in RFC 3463 [25] SHOULD be used in preference to the invention of new codes.
这些排序规则以及原则上的代码本身可以通过服务器提供的SMTP扩展进行扩展或修改，并由客户端接受（请求）。然而，如果目标是代码中更精确的粒度，而不是用于全新目的的代码，则应优先使用RFC 3463[25]中描述的系统，而不是发明新代码。
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. Similarly, producing a "command too long" message for a command line shorter than 512 characters would violate the provisions of Section 4.5.3.1.4.
500表示“命令行过长”或无法识别命令名。请注意，响应这些命令的所需子集而产生“未识别命令”错误违反了本规范。同样，为短于512个字符的命令行生成“命令过长”消息将违反第4.5.3.1.4节的规定。
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
S:220 E:554
EHLO or HELO
埃洛还是希洛
S: 250 E: 504 (a conforming implementation could return this code only in fairly obscure cases), 550, 502 (permitted only with an old-style server that does not support EHLO)
S:250E:504（一致性实现只能在相当模糊的情况下返回此代码）、550502（仅允许在不支持EHLO的旧式服务器上使用）
邮政
S: 250 E: 552, 451, 452, 550, 553, 503, 455, 555
S:250E:552451452550345555
RCPT
RCPT
S: 250, 251 (but see Section 3.4 for discussion of 251 and 551) E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555
S:250251（但有关251和551的讨论请参见第3.4节）E:5505515525534504514514522555
DATA
数据
I: 354 -> data -> S: 250
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E:55255451452
E: 450, 550 (rejections for policy reasons)
E:450550（因政策原因被拒绝）
E: 503, 554
E:503554
RSET
RSET
S: 250
S:250
VRFY
弗菲
S: 250, 251, 252 E: 550, 551, 553, 502, 504
S:250251252E:550551553502504
EXPN
扩展
S: 250, 252 E: 550, 500, 502, 504
S:250252E:5505002502504
HELP
帮助
S: 211, 214 E: 502, 504
S:211214E:502504
NOOP
努普
S: 250
S:250
QUIT
退出
S: 221
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:
该行的结构必须如下所示：
o The FROM clause, 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.
o FROM子句必须在SMTP环境中提供，它应包含（1）EHLO命令中显示的源主机名称和（2）包含源IP地址的地址文字，由TCP连接确定。
o The ID clause MAY contain an "@" as suggested in RFC 822, but this is not required.
o ID子句可能包含RFC 822中建议的“@”，但这不是必需的。
o If the FOR clause appears, it MUST contain exactly one <path> entry, even when multiple RCPT commands have been given. Multiple <path>s raise some security issues and have been deprecated, see Section 7.2.
o 如果出现FOR子句，则它必须仅包含一个<path>条目，即使给出了多个RCPT命令。多个<path>会引发一些安全问题，已被弃用，请参见第7.2节。
An Internet mail program MUST NOT change or delete a Received: line that was previously added to the message header section. 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邮件程序不得更改或删除以前添加到邮件标题部分的接收：行。SMTP服务器必须将收到的行前置到邮件；他们不得更改现有行的顺序或在任何其他位置插入收到的行。
As the Internet grows, comparability of Received header fields is important for detecting problems, especially slow relays. SMTP servers that create Received header fields SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names of any type. Local time (with an offset) SHOULD be used rather than UT when feasible. This formulation allows slightly more information about local circumstances to be specified. If UT is needed, the
随着互联网的发展，接收到的报头字段的可比性对于检测问题非常重要，尤其是慢速中继。创建接收头字段的SMTP服务器应该在日期（例如-0800）中使用显式偏移量，而不是任何类型的时区名称。可行时，应使用当地时间（带偏移）而不是UT。该公式允许对当地情况提供更多的信息。如果需要UT，则
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.
接收者只需要做一些简单的运算来转换这些值。使用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 rest of the mail data: first the balance of the mail header section and then the body (RFC 5322 [4]).
上面的文本意味着最终邮件数据将以返回路径行开始，后跟一个或多个时间戳行。这些行后面是邮件数据的其余部分：首先是邮件头部分的余额，然后是正文（RFC 5322[4]）。
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, 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.
SMTP服务器有时很难确定是否正在进行最终传递，因为转发或其他操作可能发生在邮件被接受传递之后。因此，任何进一步的（转发、网关或中继）系统都可以根据需要删除返回路径并重新生成邮件命令，以确保在传递的消息中只显示一行这样的内容。
A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header field. SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path header fields are present. SMTP servers making final delivery MAY remove Return-path header fields 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 field (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: o a gateway from SMTP -> elsewhere SHOULD insert a return-path header field, unless it is known that the "elsewhere" transport also uses Internet domain addresses and maintains the envelope sender address separately.
特别是：o来自SMTP->别处的网关应插入返回路径标头字段，除非已知“别处”传输也使用Internet域地址并单独维护信封发件人地址。
o a gateway from elsewhere -> SMTP SHOULD delete any return-path header field 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.
o 来自别处的网关->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 SHOULD be used when possible. Note that the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the backward-pointing address in this case. All notification messages about undeliverable mail MUST be sent using the MAIL command (even if they result from processing the obsolete SEND, SOML, or SAML commands) and MUST use a null return path as discussed in Section 3.6.
必须为每个失败的收件人发送列出所有失败收件人的单个通知或单独的通知消息。为了节省发送方的处理成本，应尽可能使用前者。请注意，处理别名（第3.9.1节）和转发（本小节）之间的关键区别在于在这种情况下对反向地址的更改。所有关于无法送达邮件的通知消息必须使用mail命令发送（即使它们是处理过时的SEND、SOML或SAML命令产生的），并且必须使用第3.6节中讨论的空返回路径。
The time stamp line and the return path line are formally defined as follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 [4]):
时间戳线和返回路径线的正式定义如下（“FWS”和“CFWS”的定义见RFC 5322[4]）：
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 [CFWS] ";"
FWS date-time
; where "date-time" is as defined in RFC 5322 [4]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
Stamp = From-domain By-domain Opt-info [CFWS] ";"
FWS date-time
; where "date-time" is as defined in RFC 5322 [4]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
From-domain = "FROM" FWS Extended-Domain
From domain=“From”FWS扩展域
By-domain = CFWS "BY" FWS Extended-Domain
按域=CFWS“按”FWS扩展域
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]
[Additional-Registered-Clauses]
Opt-info = [Via] [With] [ID] [For]
[Additional-Registered-Clauses]
Via = CFWS "VIA" FWS Link
Via=CFWS“Via”FWS链路
With = CFWS "WITH" FWS Protocol
With=CFWS“With”FWS协议
ID = CFWS "ID" FWS ( Atom / msg-id ) ; msg-id is defined in RFC 5322 [4]
ID=CFWS“ID”FWS（原子/消息ID）；消息id在RFC 5322[4]中定义
For = CFWS "FOR" FWS ( Path / Mailbox )
For=CFWS“For”FWS（路径/邮箱）
Additional-Registered-Clauses = CFWS Atom FWS String
; Additional standard clauses may be
added in this
; location by future standards and
registration with
; IANA. SMTP servers SHOULD NOT use
unregistered
; names. See Section 8.
Additional-Registered-Clauses = CFWS Atom FWS String
; Additional standard clauses may be
added in this
; location by future standards and
registration with
; IANA. SMTP servers SHOULD NOT use
unregistered
; names. See Section 8.
Link = "TCP" / Addtl-Link
Link=“TCP”/Addtl链接
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.
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
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are
; registered with the Internet Assigned Numbers
; Authority (IANA) in the "mail parameters"
; registry [9]. SMTP servers SHOULD NOT
; use unregistered names.
Attdl-Protocol = Atom
; Additional standard names for protocols are
; registered with the Internet Assigned Numbers
; Authority (IANA) in the "mail parameters"
; registry [9]. SMTP servers SHOULD NOT
; use unregistered names.
In order to make SMTP workable, the following minimum implementation MUST be provided by 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 that 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 that 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 allow all user composed text to be transmitted transparently, the following procedures are used:
如果不提供数据透明度，字符序列“<CRLF><CRLF>”将结束邮件文本，用户无法发送。一般来说，用户不知道这样的“禁止”序列。为了使所有用户编写的文本能够透明地传输，使用了以下步骤：
o 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.
o 在发送一行邮件文本之前，SMTP客户端将检查该行的第一个字符。如果是句点，则在行首插入一个额外的句点。
o 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.
o 当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 Section 3.6 for special treatment of these conditions in SMTP systems serving a relay function.
邮件数据可以包含128个ASCII字符中的任意一个。所有字符都将发送到收件人的邮箱，包括空格、垂直和水平制表符以及其他控制字符。如果传输通道提供8位字节（八位字节）数据流，则在八位字节中传输7位ASCII码，右对齐，高阶位清除为零。有关服务于中继功能的SMTP系统中这些条件的特殊处理，请参见第3.6节。
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 (RFC 2156 [35]) 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 that impose no limits on the length of these objects should be used.
有多个对象具有所需的最小/最大尺寸。每个实现必须能够接收至少这些大小的对象。如果可能，应避免使用大于这些尺寸的物体。但是，一些Internet邮件构造，例如编码的X.400地址（RFC 2156[35]）通常需要更大的对象。客户端可能会尝试传输这些数据，但如果服务器无法处理这些数据，则必须为服务器拒绝这些数据做好准备。应尽最大可能使用对这些对象的长度没有限制的实现技术。
Extensions to SMTP may involve the use of characters that occupy more than a single octet each. This section therefore specifies lengths in octets where absolute lengths, rather than character counts, are intended.
SMTP的扩展可能涉及使用每个字符占用多个八位字节的字符。因此，本节以八位字节为单位指定了绝对长度，而不是字符计数。
The maximum total length of a user name or other local-part is 64 octets.
用户名或其他本地部分的最大总长度为64个八位字节。
The maximum total length of a domain name or number is 255 octets.
域名或数字的最大总长度为255个八位字节。
The maximum total length of a reverse-path or forward-path is 256 octets (including the punctuation and element separators).
反向路径或正向路径的最大总长度为256个八位字节（包括标点符号和元素分隔符）。
The maximum total length of a command line including the command word and the <CRLF> is 512 octets. SMTP extensions may be used to increase this limit.
包括命令字和<CRLF>的命令行的最大总长度为512个八位字节。SMTP扩展可用于增加此限制。
The maximum total length of a reply line including the reply code and the <CRLF> is 512 octets. More information may be conveyed through multiple-line replies.
包括应答代码和<CRLF>的应答行的最大总长度为512个八位字节。更多信息可通过多行回复传达。
The maximum total length of a text line including the <CRLF> is 1000 octets (not counting the leading dot duplicated for transparency). This number may be increased by the use of SMTP Service Extensions.
包含<CRLF>的文本行的最大总长度为1000个八位字节（不包括为透明而复制的前导点）。此数字可能会因使用SMTP服务扩展而增加。
The maximum total length of a message content (including any message header section as well as the message body) MUST BE at least 64K octets. Since the introduction of Internet Standards for multimedia mail (RFC 2045 [21]), 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 of RFC 1870 [10], and SMTP client systems that will send large messages SHOULD utilize it when possible.
消息内容（包括任何消息头部分以及消息正文）的最大总长度必须至少为64K个八位字节。自从引入多媒体邮件的互联网标准（RFC 2045[21]）以来，互联网上的邮件长度急剧增长，如果可能，应避免邮件大小限制。必须施加限制的SMTP服务器系统应实现RFC 1870[10]的“大小”服务扩展，而将发送大型邮件的SMTP客户端系统应尽可能使用该扩展。
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 server MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation tests on message header fields suggests that messages SHOULD NOT be rejected based on the total number of recipients shown in header fields. A server that imposes a limit on the number of recipients MUST behave in an orderly fashion, such as rejecting additional addresses over its limit rather than silently discarding addresses previously accepted. A client that needs to 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命令的邮件（对于过多的收件人）违反了本规范。中继SMTP服务器不得和传递SMTP服务器不得对邮件标题字段执行验证测试的一般原则表明，不应根据标题字段中显示的收件人总数拒绝邮件。对收件人数量施加限制的服务器必须以有序的方式运行，例如拒绝超过其限制的其他地址，而不是默默地放弃以前接受的地址。如果服务器拒绝在单个消息中接收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.
500行太长了。
or
或
501 Path too long
501路径太长
or
或
452 Too many recipients (see below)
452收件人太多（见下文）
or
或
552 Too much mail data.
552邮件数据太多。
RFC 821 [1] 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[1]错误地将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
当符合条件的SMTP服务器遇到此情况时，其收件人缓冲区中至少有100个成功的RCPT命令。如果服务器能够接受该消息，那么至少有100个
addresses will be removed from the SMTP client's queue. When the client attempts retransmission of those addresses that received 452 responses, at least 100 of these will be able to fit in the SMTP server's recipients buffer. Each retransmission attempt that is able to deliver anything will be able to dispose of at least 100 of these recipients.
将从SMTP客户端队列中删除地址。当客户端尝试重新传输接收到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 5yz response code. In particular, if the intent is to prohibit messages with more than a site-specified number of recipients, rather than merely limit the number of recipients in a given mail transaction, it would be reasonable to return a 503 response to any DATA command received subsequent to the 452 (or 552) code or to simply return the 503 after DATA without returning any previous negative response.
如果SMTP服务器对RCPT命令的数量有实现限制，并且该限制已用尽，则它必须使用452响应代码（但客户端还应准备552响应代码，如上所述）。如果服务器对RCPT命令的数量有配置的站点策略限制，则它可以改为使用5yz响应代码。特别是，如果目的是禁止具有超过站点指定的接收者数量的消息，而不仅仅是限制给定邮件事务中的接收者数量，那么对452（或552）之后接收的任何数据命令返回503响应将是合理的代码或仅返回503 after数据，而不返回任何以前的否定响应。
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 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客户端必须提供超时机制。它必须使用per命令超时，而不是试图对整个邮件事务计时。超时应该很容易重新配置，最好不用重新编译SMTP代码。为了实现这一点，为每个SMTP命令和数据传输的每个缓冲区设置一个计时器。后者意味着总超时与消息的大小成正比。
Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:
根据繁忙邮件中继主机的丰富经验，每个命令的最小超时值应如下所示：
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.
SMTP客户端进程需要区分TCP连接失败和接收初始消息的延迟。许多SMTP服务器接受TCP连接，但延迟220邮件的传递，直到其系统负载允许处理更多邮件。
A longer timeout is required if processing of mailing lists and aliases is not deferred until after the message was accepted.
如果邮件列表和别名的处理没有推迟到邮件被接受之后，则需要更长的超时时间。
This is while awaiting the "354 Start Input" reply to a DATA command.
这是在等待数据命令的“354开始输入”回复时发生的。
This is while awaiting the completion of each TCP SEND call transmitting a chunk of data.
这是在等待每个TCP发送调用完成传输数据块时发生的。
4.5.3.2.6. DATA Termination: 10 Minutes.
4.5.3.2.6. 数据终止：10分钟。
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.
这是在等待“250 OK”回复时进行的。当接收方收到终止消息数据的最后一个时段时，它通常会执行处理以将消息传递到用户邮箱。此时的虚假超时将是非常浪费的，通常会导致邮件的多个副本的传递，因为邮件已成功发送，并且服务器已接受传递的责任。更多讨论见第6.1节。
4.5.3.2.7. Server Timeout: 5 Minutes.
4.5.3.2.7. 服务器超时：5分钟。
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 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.
主机SMTP实现的常见结构包括用户邮箱、一个或多个用于对传输中的消息进行排队的区域，以及一个或多个用于发送和接收邮件的守护进程。具体结构将根据主机上用户的需求以及主机支持的邮件列表的数量和大小而有所不同。我们描述了一些被证明是有用的优化，特别是对于支持高流量级别的邮件。
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. It MAY be appropriate to set a shorter maximum number of retries for non-delivery notifications and equivalent error messages than for standard messages. 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, RFC 1985 [36].
SMTP客户端可以与SMTP服务器协作缩短排队延迟。例如，如果从特定地址接收邮件，则很可能现在可以发送排队等待该主机的邮件。在许多情况下，应用这一原则可以消除对显式“立即发送队列”功能的要求，如ETRN、RFC 1985[36]。
The strategy may be further modified as a result of multiple addresses per host (see below) to optimize delivery time versus 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. This efficiency feature SHOULD be implemented.
当一封邮件要发送给多个收件人，并且邮件副本要发送到的SMTP服务器对于多个收件人是相同的，则只应发送一份邮件副本。也就是说，SMTP客户端应该使用命令序列：MAIL，RCPT，RCPT，…，RCPT，DATA，而不是顺序：MAIL，RCPT，DATA，…，MAIL，RCPT，DATA。但是，如果地址非常多，则可能会对每个邮件命令的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 (specified by IANA as port 25) 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端口（由IANA指定为端口25）上保留挂起的侦听。这需要支持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 that 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, other kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and Message Disposition Notifications (MDNs, RFC 3798 [37]). 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.)
现有和拟议标准要求使用空反向路径发送几种类型的通知消息，即第3.7节中讨论的未送达通知、其他类型的送达状态通知（DSN、RFC 3461[32]）和消息处置通知（MDN、RFC 3798[37]）。所有这些类型的邮件都是关于上一封邮件的通知，它们被发送到上一封邮件的反向路径。（如果此类通知邮件的传递失败，通常表明通知邮件所针对的主机的邮件系统存在问题。因此，在某些主机上，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 a valid, non-null reverse-path.
所有其他类型的消息（即，标准跟踪RFC不要求具有空反向路径的任何消息）应使用有效的非空反向路径发送。
Implementers of automated email processors should be careful to make sure that the various kinds of messages with a null reverse-path are handled correctly. In particular, such systems SHOULD NOT reply to messages with a null reverse-path, and they SHOULD NOT add a non-null reverse-path, or change a null reverse-path to a non-null one, to such messages when forwarding.
自动化电子邮件处理器的实现者应该小心确保正确处理具有空反向路径的各种消息。特别是，此类系统不应回复具有空反向路径的消息，并且在转发时不应向此类消息添加非空反向路径，或将空反向路径更改为非空路径。
Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in Sections 2.3.5 and 3.6), a DNS lookup MUST be performed to resolve the domain name (RFC 1035 [2]). 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. Due to a history of problems, SMTP servers used for initial submission of messages SHOULD NOT make such inferences (Message Submission Servers [18] have somewhat more flexibility) and intermediate (relay) SMTP servers MUST NOT make them.
一旦SMTP客户端在词汇上识别邮件将发送到哪个域进行处理（如第2.3.5节和第3.6节所述），则必须执行DNS查找以解析域名（RFC 1035[2]）。名称应为完全限定域名（FQDN）：从部分名称或本地别名推断FQDN的机制不在此规范范围内。由于存在问题，用于首次提交邮件的SMTP服务器不应做出此类推断（邮件提交服务器[18]具有更大的灵活性），中间（中继）SMTP服务器不得做出此类推断。
The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name. If a non-existent domain error is returned, this situation MUST be reported as an error. If a temporary error is returned, the message MUST be queued and retried later (see Section 4.5.4.1). If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. If MX records are present, but none of them are usable, or the implicit MX is unusable, this situation MUST be reported as an error.
查找首先尝试查找与该名称关联的MX记录。如果找到CNAME记录，则结果名称的处理方式与初始名称相同。如果返回不存在的域错误，则必须将此情况报告为错误。如果返回临时错误，则必须排队等待消息并稍后重试（请参阅第4.5.4.1节）。如果返回的MX列表为空，则该地址将被视为与隐式MX RR关联，首选项为0，指向该主机。如果存在MX记录，但这些记录都不可用，或者隐式MX不可用，则必须将此情况报告为错误。
If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any address 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.
如果为给定名称找到一个或多个MX RRs，SMTP系统不得使用与该名称关联的任何地址RRs，除非它们使用MX RRs定位；仅当不存在MX记录时，上述“隐式MX”规则才适用。如果存在MX记录，但这些记录都不可用，则必须将此情况报告为错误。
When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. The prohibition on labels in the data that resolve to CNAMEs is discussed in more detail in RFC 2181, Section 10.3 [38].
当查找与MX RR关联的域名并获取关联的数据字段时，该响应的数据字段必须包含域名。查询该域名时，必须返回至少一个地址记录（例如，A或AAAA RR），该记录提供了邮件应定向到的SMTP服务器的IP地址。任何其他响应，特别是包括查询时将返回CNAME记录的值，都不属于本标准的范围。RFC 2181第10.3节[38]对解析为CNAMEs的数据中的标签禁令进行了更详细的讨论。
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 are used to rank the host addresses: multiple MX records, and multihomed hosts.
有两种类型的信息用于对主机地址进行排序：多个MX记录和多主机。
MX records contain a preference indication that MUST be used in sorting if more than one such record appears (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 the SMTP sender 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
如果它确定应该在不重写地址的情况下中继消息，则必须对MX记录进行排序，以确定消息的候选项
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.
传送这些记录首先按优先顺序排列，编号最低的记录是最优先的。然后，中继主机必须检查列表中的任何名称或地址，这些名称或地址在邮件事务中可能是已知的。如果找到匹配的记录，则必须放弃该首选项级别的所有记录以及编号更高的记录。如果此时没有留下任何记录，则这是一种错误情况，必须将消息作为无法传递返回。如前所述，如果记录确实保留下来，则应首先尝试使用最佳首选项。
In the contemporary Internet, SMTP clients and servers may be hosted on IPv4 systems, IPv6 systems, or dual-stack systems that are compatible with either version of the Internet Protocol. The host domains to which MX records point may, consequently, contain "A RR"s (IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC 3974 [39] discusses some operational experience in mixed environments, it was not comprehensive enough to justify standardization, and some of its recommendations appear to be inconsistent with this specification. The appropriate actions to be taken either will depend on local circumstances, such as performance of the relevant networks and any conversions that might be necessary, or will be obvious (e.g., an IPv6-only client need not attempt to look up A RRs or attempt to reach IPv4-only servers). Designers of SMTP implementations that might run in IPv6 or dual-stack environments should study the procedures above, especially the comments about multihomed hosts, and, preferably, provide mechanisms to facilitate operational tuning and mail interoperability between IPv4 and IPv6 systems while considering local circumstances.
在当代互联网中，SMTP客户端和服务器可能托管在IPv4系统、IPv6系统或与任一版本的互联网协议兼容的双堆栈系统上。因此，MX记录指向的主机域可能包含“A RR”（IPv4）、“AAAA RR”（IPv6）或它们的任意组合。虽然RFC 3974[39]讨论了混合环境中的一些操作经验，但其不够全面，不足以证明标准化的合理性，其一些建议似乎与本规范不一致。要采取的适当行动将取决于本地情况，如相关网络的性能和可能需要的任何转换，或者是显而易见的（例如，仅IPv6的客户端不需要尝试查找RRs或尝试访问仅IPv4的服务器）。可能在IPv6或双栈环境中运行的SMTP实现的设计者应研究上述过程，特别是关于多宿主机的评论，最好提供机制，以促进IPv4和IPv6系统之间的操作调优和邮件互操作性，同时考虑本地情况。
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. Some reasons that are not considered frivolous are discussed in the next subsection and in Section 7.8.
当收件人SMTP接受一封邮件（通过发送“250 OK”消息以响应数据）时，它接受传递或转发该邮件的责任。它必须认真对待这一责任。它不能因为琐碎的原因丢失消息，例如主机稍后崩溃或可预测的资源短缺。下一小节和第7.8节将讨论一些不被认为无关紧要的原因。
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,
如果在接受邮件后出现传递失败，则收件人SMTP必须制定并邮寄通知邮件。必须使用信封中的空（<>）反向路径发送此通知。此通知的收件人必须是信封返回路径（或返回路径：行）中的地址。然而
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相同的系统环境的一部分）在本地记录或以其他方式传输有关空地址事件的信息（如果需要）。如果地址是显式源路由，则必须将其剥离到最后一个跃点。
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 [40] for a discussion of this problem.
为避免因超时而收到重复邮件，收件人SMTP必须尽量缩短响应最终<CRLF><CRLF>数据结束指示符所需的时间。有关此问题的讨论，请参见RFC 1047[40]。
Utility and predictability of the Internet mail system requires that messages that can be delivered should be delivered, regardless of any syntax or other faults associated with those messages and regardless of their content. If they cannot be delivered, and cannot be rejected by the SMTP server during the SMTP transaction, they should be "bounced" (returned with non-delivery notification messages) as described above. In today's world, in which many SMTP server operators have discovered that the quantity of undesirable bulk email vastly exceeds the quantity of desired mail and in which accepting a message may trigger additional undesirable traffic by providing verification of the address, those principles may not be practical.
Internet邮件系统的实用性和可预测性要求可以传递的邮件应该被传递，而不管与这些邮件相关的任何语法或其他错误，也不管其内容如何。如果无法传递这些邮件，并且在SMTP事务期间SMTP服务器无法拒绝这些邮件，则应如上所述将其“退回”（与未传递通知邮件一起返回）。在当今世界，许多SMTP服务器运营商发现，不受欢迎的批量电子邮件的数量远远超过了所需邮件的数量，并且接受邮件可能会通过提供地址验证而触发额外的不受欢迎的通信量，这些原则可能不实用。
As discussed in Section 7.8 and Section 7.9 below, dropping mail without notification of the sender is permitted in practice. However, it is extremely dangerous and violates a long tradition and community expectations that mail is either delivered or returned. If
如下文第7.8节和第7.9节所述，在实践中允许在不通知发件人的情况下投递邮件。然而，这是极其危险的，违反了长期以来的传统和社区对邮件的寄送或退回的期望。如果
silent message-dropping is misused, it could easily undermine confidence in the reliability of the Internet's mail systems. So silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate.
无声信息丢弃被滥用，很容易破坏人们对互联网邮件系统可靠性的信心。因此，只有在高度确信消息具有严重欺诈性或不适当的情况下，才应考虑无声删除消息。
To stretch the principle of delivery if possible even further, it may be a rational policy to not deliver mail that has an invalid return address, although the history of the network is that users are typically better served by delivering any message that can be delivered. Reliably determining that a return address is invalid can be a difficult and time-consuming process, especially if the putative sending system is not directly accessible or does not fully and accurately support VRFY and, even if a "drop messages with invalid return addresses" policy is adopted, it SHOULD be applied only when there is near-certainty that the return addresses are, in fact, invalid.
如果可能的话，为了进一步扩展传递原则，不传递返回地址无效的邮件可能是一种合理的策略，尽管网络的历史表明，通常通过传递任何可以传递的邮件来更好地为用户服务。可靠地确定返回地址无效可能是一个困难且耗时的过程，尤其是在假定的发送系统无法直接访问或不能完全准确地支持VRFY的情况下，并且即使采用了“删除返回地址无效的邮件”策略，只有当几乎可以确定返回地址实际上是无效的时，才应使用该方法。
Conversely, if a message is rejected because it is found to contain hostile content (a decision that is outside the scope of an SMTP server as defined in this document), rejection ("bounce") messages SHOULD NOT be sent unless the receiving site is confident that those messages will be usefully delivered. The preference and default in these cases is to avoid sending non-delivery messages when the incoming message is determined to contain hostile content.
相反，如果邮件被拒绝是因为发现包含恶意内容（此决定超出了本文档中定义的SMTP服务器的范围），则拒绝（“反弹”）邮件不应发送，除非接收站点确信这些邮件将有效地传递。在这些情况下，首选和默认设置是在确定传入消息包含恶意内容时避免发送未送达消息。
Simple counting of the number of "Received:" header fields 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
不幸的是，变化、创造性的解释和对互联网邮件协议的公然违反确实发生了；有些人会说，它们经常发生。关于行为良好的SMTP接收者或中继是否应该拒绝格式错误的邮件、尝试原封不动地传递邮件，还是尝试修复邮件以增加成功传递（或后续回复）的几率的争论，几乎始于结构化网络邮件的出现，并且没有减弱的迹象。拒绝的拥护者声称，尝试的修复很少是完全足够的，拒绝坏消息是修复有问题软件的唯一方法。“修复”或“无论如何交付”的倡导者认为用户更喜欢这样
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.
如果可能的话，邮件会通过它，并且在这方面存在着巨大的市场压力。在实践中，这些市场压力对特定供应商来说可能比严格遵守标准更重要，而不管实际开发商的偏好如何。
The problems associated with ill-formed messages were exacerbated by the introduction of the split-UA mail reading protocols (Post Office Protocol (POP) version 2 [15], Post Office Protocol (POP) version 3 [16], IMAP version 2 [41], and PCMAIL [42]). These protocols encouraged the use of SMTP as a posting (message submission) 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, RFC 822 [28]). 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邮件阅读协议（邮局协议（POP）版本2[15]、邮局协议（POP）版本3[16]、IMAP版本2[41]和PCMAIL[42]）的引入加剧了与格式错误邮件相关的问题。这些协议鼓励将SMTP用作投递（邮件提交）协议，并将SMTP服务器用作这些客户端主机（通常只是间歇性连接到Internet）的中继系统。从历史上看，这些客户机中的许多都缺乏SMTP（以及邮件格式协议RFC 822[28]）所采用的一些机制和信息。有些人没有足够的时间记录；其他人没有时区的概念；还有一些人无法确定自己的姓名或地址；当然，没有一个能够满足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. Many of these issues are addressed by using a separate protocol, such as that defined in RFC 4409 [18], for message submission, rather than using originating SMTP servers for that purpose.
为了响应这些较弱的SMTP客户端，许多SMTP系统现在以不完整或不正确的形式完成发送给它们的邮件。当服务器可以识别或验证客户机，并且客户机之间存在事先协议时，通常认为此策略是合适的。相比之下，对于中继或传递SMTP服务器应用的修复程序，充其量也有很大的担忧，因为这些服务器对用户或客户端计算机知之甚少或一无所知。其中许多问题是通过使用单独的协议来解决的，如RFC 4409[18]中定义的协议，用于邮件提交，而不是为此目的使用原始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 (message submission) protocol:
必要时，原始SMTP服务器或用作SMTP目标的SMTP服务器可将以下更改应用于正在处理的邮件，作为初始投递（邮件提交）协议：
o Addition of a message-id field when none appears
o 无显示时添加消息id字段
o Addition of a date, time, or time zone when none appears
o 无显示时添加日期、时间或时区
o Correction of addresses to proper FQDN format
o 将地址更正为正确的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 SHOULD be provided in trace header fields and/or header field comments for actions performed by the servers.
在所有情况下，提供正确信息的正确操作的客户端都比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 that use digital signatures (see RFC 1847 [43] and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/ Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]).
SMTP邮件本质上是不安全的，因为即使是相当随意的用户也可以直接与接收和转发SMTP服务器进行协商，并创建邮件，从而欺骗天真的收件人相信他们来自其他地方。构建这样一条信息，使专家无法检测到“欺骗”行为有点困难，但还不足以对有决心和知识的人起到威慑作用。因此，随着互联网邮件知识的增加，SMTP邮件本身无法在传输级别进行身份验证或提供完整性检查的知识也会增加。真正的邮件安全性仅存在于涉及消息体的端到端方法中，例如使用数字签名的方法（参见RFC 1847[43]，例如RFC 4880[44]中的相当好的隐私（PGP）或RFC 3851[45]中的安全/多用途互联网邮件扩展（S/MIME））。
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, in general, they only authenticate one server to another rather than a chain of relays and servers, much less authenticating users or user machines. Consequently, unless they are accompanied by careful handoffs of responsibility in a carefully designed trust environment, they remain inherently weaker than end-to-end mechanisms that 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, in which error (or normal) replies should be directed to a special address, or in which a single message is sent to multiple recipients on different hosts. (Systems that provide convenient ways for users to alter these header fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender header 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 a user who is trying to fake mail.
本规范没有进一步解决与SMTP相关的身份验证问题，只是主张不要禁用有用的功能，以期为试图伪造邮件的用户提供少量保护。
Addresses that do not appear in the message header section 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 header section, either as part of trace header fields or as informational or private-extension header fields. 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 header section. Receiving systems SHOULD NOT attempt to deduce such relationships and use them to alter the header section of the message for delivery. The popular "Apparently-to" header field 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 (see below). 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 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.
如第3.5节所述，出于安全原因，各个站点可能希望禁用VRFY或EXPN中的一个或两个（见下文）。作为上述的推论，允许这样做的实现不能看起来具有事实上未经验证的已验证地址。如果站点出于安全原因禁用这些命令，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的实现也同样不一致。
On the public Internet, 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. However, VRFY and EXPN are still useful for authenticated users and within an administrative domain. For example, VRFY and EXPN are useful for performing internal audits of how email gets routed to check and to make sure no one is automatically forwarding sensitive mail outside the organization. Sites implementing SMTP authentication may choose to make VRFY and EXPN available only to authenticated requestors. Implementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.
由于列表管理员安装了防止不适当使用列表的保护措施，使用EXPN“获取”地址的情况有所增加。但是，VRFY和EXPN对于经过身份验证的用户和管理域内的用户仍然有用。例如，VRFY和EXPN可用于对电子邮件的路由方式进行内部审核，以检查并确保没有人在组织外部自动转发敏感邮件。实现SMTP身份验证的站点可以选择使VRFY和EXPN仅对经过身份验证的请求者可用。实现仍应提供对EXPN的支持，但站点应仔细评估权衡。
Whether disabling VRFY provides any real marginal security depends on a series of other conditions. In many cases, RCPT commands can be used to obtain the same information about address validity. On the other hand, especially in situations where determination of address validity for RCPT commands is deferred until after the DATA command is received, RCPT may return no information at all, while VRFY is expected to make a serious attempt to determine validity before generating a response code (see discussion above).
禁用VRFY是否提供真正的边际安全性取决于一系列其他条件。在许多情况下，可以使用RCPT命令来获得关于地址有效性的相同信息。另一方面，特别是在RCPT命令的地址有效性的确定延迟到收到数据命令之后的情况下，RCPT可能根本不返回任何信息，而VRFY则希望在生成响应代码之前认真尝试确定有效性（见上文讨论）。
Before a client uses the 251 or 551 reply codes from a RCPT command to automatically update its future behavior (e.g., updating the user's address book), it should be certain of the server's authenticity. If it does not, it may be subject to a man in the middle attack.
在客户端使用RCPT命令中的251或551回复代码自动更新其未来行为（例如，更新用户的通讯簿）之前，应该确定服务器的真实性。如果没有，它可能会受到中间人的攻击。
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 SHOULD 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") header 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回复代码识别与邮箱相关的替换地址可能会无意中泄露敏感信息。关注这些问题的站点应确保适当地选择和配置服务器。
In recent years, there has been an increase of attacks on SMTP servers, either in conjunction with attempts to discover addresses for sending unsolicited messages or simply to make the servers inaccessible to others (i.e., as an application-level denial of service attack). While the means of doing so are beyond the scope of this Standard, rational operational behavior requires that servers be permitted to detect such attacks and take action to defend themselves. For example, if a server determines that a large number of RCPT TO commands are being sent, most or all with invalid addresses, as part of such an attack, it would be reasonable for the server to close the connection after generating an appropriate number of 5yz (normally 550) replies.
近年来，针对SMTP服务器的攻击不断增加，可能是为了发现发送未经请求邮件的地址，也可能是为了让其他人无法访问服务器（即，作为应用程序级拒绝服务攻击）。虽然这样做的方法超出了本标准的范围，但合理的操作行为要求允许服务器检测此类攻击并采取行动进行自我防护。例如，如果作为此类攻击的一部分，服务器确定正在发送大量RCPT TO命令（大部分或全部地址无效），则服务器在生成适当数量的5yz（通常为550）回复后关闭连接是合理的。
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 (or HELO), MAIL, or RCPT as appropriate.
近年来，通过任意站点使用中继功能已被用作敌对行动的一部分，以隐藏邮件的实际来源。一些站点决定将中继功能的使用限制在已知或可识别的源上，并且实现应提供执行此类过滤的能力。当邮件因这些或其他政策原因被拒绝时，应使用550代码来响应EHLO（或HELO）、mail或RCPT（视情况而定）。
IANA maintains three registries in support of this specification, all of which were created for RFC 2821 or earlier. This document expands the third one as specified below. The registry references listed are as of the time of publication; IANA does not guarantee the locations associated with the URLs. The registries are as follows:
IANA维护三个注册表以支持此规范，所有这些注册表都是为RFC 2821或更早版本创建的。本文件扩展了第三个文件，如下所述。所列的注册参考资料截至发布时；IANA不保证与URL关联的位置。登记处如下：
o The first, "Simple Mail Transfer Protocol (SMTP) Service Extensions" [46], 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.
o 第一个“简单邮件传输协议（SMTP）服务扩展”[46]，由SMTP服务扩展和相关关键字组成，根据需要还包括参数和动词。如第2.2.2节所述，不得在此注册表中输入以“X”开头的条目。仅可为IESG为此专门批准的标准跟踪或实验RFC中定义的服务扩展（以及相关关键字、参数或动词）输入条目。
o The second registry, "Address Literal Tags" [47], consists of "tags" that identify forms of domain literals other than those for IPv4 addresses (specified in RFC 821 and in this document). The initial entry in that registry is for IPv6 addresses (specified in this document). Additional literal types require standardization before being used; none are anticipated at this time.
o 第二个注册表“Address Literal Tags”[47]由“Tags”组成，这些“Tags”标识IPv4地址以外的域文字的形式（在RFC 821和本文档中指定）。该注册表中的初始条目用于IPv6地址（在本文档中指定）。其他文字类型在使用前需要标准化；目前预计不会有。
o The third, "Mail Transmission Types" [46], 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 field) 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. This name space is for identification and not limited in size: the IESG is encouraged to approve on the basis of clear documentation and a distinct method rather than preferences about the properties of the method itself.
o 第三个“邮件传输类型”[46]，由RFC 821建立，并由本规范更新，是链接和协议标识符的注册表，将与第4.4节中所述的时间戳的“via”和“with”（“Received:“header field”）子类一起使用。除本文件中规定的标识符外，链路和协议标识符只能通过标准化或通过RFC记录、IESG批准的实验协议扩展进行注册。此名称空间用于标识，但不限于大小：鼓励IESG根据清晰的文档和独特的方法而不是方法本身的属性偏好进行批准。
An additional subsection has been added to the "VIA link types" and "WITH protocol types" subsections of this registry to contain registrations of "Additional-registered-clauses" as described above. The registry will contain clause names, a description, a
本注册中心的“VIA link type”和“WITH protocol type”子部分增加了一个附加子部分，以包含上述“附加注册条款”的注册。注册表将包含子句名称、描述和
summary of the syntax of the associated String, and a reference. As new clauses are defined, they may, in principle, specify creation of their own registries if the Strings consist of reserved terms or keywords rather than less restricted strings. As with link and protocol identifiers, additional clauses may be registered only by standardization or by way of an RFC-documented, IESG-approved, Experimental protocol extension. The additional clause name space is for identification and is not limited in size: the IESG is encouraged to approve on the basis of clear documentation, actual use or strong signs that the clause will be used, and a distinct requirement rather than preferences about the properties of the clause itself.
关联字符串的语法摘要和引用。在定义新的子句时，原则上，如果字符串由保留的术语或关键字组成，而不是限制较少的字符串，则它们可以指定创建自己的注册表。与链路和协议标识符一样，附加条款只能通过标准化或通过RFC记录、IESG批准、实验协议扩展的方式进行注册。额外的条款名称空间用于标识，且不受大小限制：鼓励IESG根据明确的文件、实际使用情况或条款将被使用的明显标志，以及关于条款本身属性的明确要求（而非偏好）进行批准。
In addition, if additional trace header fields (i.e., in addition to Return-path and Received) are ever created, those trace fields MUST be added to the IANA registry established by BCP 90 (RFC 3864) [11] for use with RFC 5322 [4].
此外，如果创建了其他跟踪头字段（即，除了返回路径和接收），则必须将这些跟踪字段添加到BCP 90（RFC 3864）[11]建立的IANA注册表中，以便与RFC 5322[4]一起使用。
Many people contributed to the development of RFC 2821. That document should be consulted for those acknowledgments. For the present document, the editor and the community owe thanks to Dawn Mann and Tony Hansen who assisted in the very painful process of editing and converting the internal format of the document from one system to another.
许多人为RFC 2821的发展做出了贡献。应查阅该文件以获得这些确认。对于本文件，编辑和社区应感谢Dawn Mann和Tony Hansen，他们在编辑和将文件的内部格式从一个系统转换到另一个系统的过程中提供了非常痛苦的帮助。
Neither this document nor RFC 2821 would have been possible without the many contribution and insights of the late Jon Postel. Those contributions of course include the original specification of SMTP in RFC 821. A considerable quantity of text from RFC 821 still appears in this document as do several of Jon's original examples that have been updated only as needed to reflect other changes in the specification.
如果没有已故Jon Postel的许多贡献和见解，本文件和RFC 2821都是不可能的。这些贡献当然包括RFC 821中SMTP的原始规范。RFC 821中的大量文本仍然出现在本文档中，Jon的几个原始示例也一样，这些示例仅在需要时进行了更新，以反映规范中的其他更改。
Many people made comments or suggestions on the mailing list or in notes to the author. Important corrections or clarifications were suggested by several people, including Matti Aarnio, Glenn Anderson, Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman, Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt Gulbrandsen, Eric Hall, Richard O. Hammer, Tony Hansen, Peter J. Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett, Mark Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hector Santos, David F. Skoll, Paul Smith, and Brett Watson.
许多人在邮件列表或给作者的注释中提出了意见或建议。一些人提出了重要的更正或澄清，包括马蒂·阿尼奥、格伦·安德森、德里克·J·鲍尔林、亚历克斯·范登·博格尔特、斯蒂芬·波茨梅尔、文特·瑟夫、朱塔·德杰纳、史蒂夫·多纳、丽莎·杜肖奥、弗兰克·埃勒曼、内德·弗里德、兰迪·盖伦、萨巴廷·古库科格鲁、菲利普·根瑟、阿恩特·古尔布兰森、埃里克·霍尔、，Richard O.Hammer、Tony Hansen、Peter J.Holzer、Kari Hurta、Bryon Roche Kain、Valdis Kletnieks、Mathias Koerber、John Leslie、Bruce Lilly、Jeff Macdonald、Mark E.Mallett、Mark Martinec、S.Moonesamy、Lyndon Nerenberg、Chris Newman、Douglas Otis、Pete Resnick、Robert A.Rosenberg、Vince Sabio、Hector Santos、David F.Skoll、Paul Smith、，还有布雷特·沃森。
The efforts of the Area Directors -- Lisa Dusseault, Ted Hardie, and Chris Newman -- to get this effort restarted and keep it moving, and of an ad hoc committee with the same purpose, are gratefully acknowledged. The members of that committee were (in alphabetical order) Dave Crocker, Cyrus Daboo, Tony Finch, Ned Freed, Randall Gellens, Tony Hansen, the author, and Alexey Melnikov. Tony Hansen also acted as ad hoc chair on the mailing list reviewing this document; without his efforts, sense of balance and fairness, and patience, it clearly would not have been possible.
感谢区域主管Lisa Dusseault、Ted Hardie和Chris Newman为重新启动这项工作并保持其运行所做的努力，以及一个具有相同目的的特设委员会所做的努力。该委员会的成员（按字母顺序）是戴夫·克罗克、塞勒斯·达布、托尼·芬奇、内德·弗里德、兰德尔·盖伦斯、托尼·汉森、作者和亚历克赛·梅尔尼科夫。Tony Hansen还担任审查本文件的邮件列表的特别主席；没有他的努力、平衡感、公平感和耐心，这显然是不可能的。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[3] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[3] Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[4] Resnick, P., "Internet Message Format", RFC 5322, October 2008.
[4] Resnick，P.，“互联网信息格式”，RFC 5322，2008年10月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
[6] 美国国家标准协会（前美国标准协会），“美国信息交换代码”，ANSI X3.4-1968，1968年。
ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
ANSI X3.4-1968已被稍作修改的较新版本所取代，但1968年版本仍然是互联网的最终版本。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[7] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[8] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[8] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[9] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.
[9] 纽曼，C.，“ESMTP和LMTP传输类型登记”，RFC 3848，2004年7月。
[10] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
[10] Klensin，J.，Freed，N.和K.Moore，“邮件大小声明的SMTP服务扩展”，STD 10，RFC 1870，1995年11月。
[11] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[11] Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[12] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986.
[12] 帕特里奇，C.，“邮件路由和域系统”，RFC 974，1986年1月。
[13] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[13] Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
[14] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[14] 《简单邮件传输协议》，RFC 28212001年4月。
[15] Butler, M., Postel, J., Chase, D., Goldberger, J., and J. Reynolds, "Post Office Protocol: Version 2", RFC 937, February 1985.
[15] Butler，M.，Postel，J.，Chase，D.，Goldberger，J.，和J.Reynolds，“邮局协议：版本2”，RFC 937，1985年2月。
[16] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[16] Myers，J.和M.Rose，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[17] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[17] Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[18] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[18] Gellens，R.和J.Klensin，“邮件邮件提交”，RFC 4409，2006年4月。
[19] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[19] 弗里德，N.，“用于命令管道的SMTP服务扩展”，STD 60，RFC 2920，2000年9月。
[20] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[20] Vaudreuil，G.，“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 3030，2000年12月。
[21] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[21] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[22] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[22] Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“8bit MIMEtransport的SMTP服务扩展”，RFC 16521994年7月。
[23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[23] Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[24] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[24] Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[25] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[25] Vaudreuil，G.，“增强型邮件系统状态代码”，RFC 3463，2003年1月。
[26] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.
[26] Hansen，T.和J.Klensin，“SMTP增强邮件系统状态代码的注册”，BCP 138，RFC 5248，2008年6月。
[27] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[27] 弗里德，N.，“互联网防火墙的行为和要求”，RFC 2979，2000年10月。
[28] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[28] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[29] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[29] Wong，M.和W.Schlitt，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 4408，2006年4月。
[30] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006.
[30] Fenton，J.，“激励域密钥识别邮件（DKIM）的威胁分析”，RFC 46862006年9月。
[31] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[31] Allman，E.，Callas，J.，Delany，M.，Libbey，M.，Fenton，J.，和M.Thomas，“域密钥识别邮件（DKIM）签名”，RFC 48712007年5月。
[32] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[32] Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[33] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[33] Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[34] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[34] Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[35] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[35] Kille，S.，“混音器（Mime互联网X.400增强中继）：X.400和RFC 822/Mime之间的映射”，RFC 2156，1998年1月。
[36] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.
[36] De Winter，J.，“远程消息队列启动的SMTP服务扩展”，RFC 1985，1996年8月。
[37] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[37] Hansen，T.和G.Vaudreuil，“消息处置通知”，RFC 3798，2004年5月。
[38] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[38] Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[39] Nakamura, M. and J. Hagino, "SMTP Operational Experience in Mixed IPv4/v6 Environments", RFC 3974, January 2005.
[39] Nakamura，M.和J.Hagino，“IPv4/v6混合环境中的SMTP操作经验”，RFC 3974，2005年1月。
[40] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February 1988.
[40] 帕特里奇，C.，“重复邮件和SMTP”，RFC 1047，1988年2月。
[41] Crispin, M., "Interactive Mail Access Protocol: Version 2", RFC 1176, August 1990.
[41] Crispin，M.，“交互式邮件访问协议：版本2”，RFC 1176，1990年8月。
[42] Lambert, M., "PCMAIL: A distributed mail system for personal computers", RFC 1056, June 1988.
[42] 兰伯特，M.，“PCMAIL：个人计算机的分布式邮件系统”，RFC10561988年6月。
[43] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[43] Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[44] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[44] Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[45] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[45] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[46] Internet Assigned Number Authority (IANA), "IANA Mail Parameters", 2007, <http://www.iana.org/assignments/mail-parameters>.
[46] 互联网分配号码管理局（IANA），“IANA邮件参数”，2007年<http://www.iana.org/assignments/mail-parameters>.
[47] Internet Assigned Number Authority (IANA), "Address Literal Tags", 2007, <http://www.iana.org/assignments/address-literal-tags>.
[47] 互联网分配号码管理局（IANA），“地址文字标签”，2007年<http://www.iana.org/assignments/address-literal-tags>.
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, or, if specifically designed to do so, in SMTP commands or responses.
TCP连接支持8位字节的传输。SMTP数据是7位ASCII字符。每个字符作为8位字节传输，高位清除为零。服务扩展可能会修改此规则，以允许将完整的8位数据字节作为邮件正文的一部分进行传输，或者，如果专门设计这样做，则在SMTP命令或响应中进行传输。
Some systems use an RFC 822 header section (only) in a mail submission protocol, or otherwise generate SMTP commands from RFC 822 header fields 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 the mail envelope is not separated early in processing from header field 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 header fields SHOULD then be removed from the header section. Once this process is completed, the remaining header fields SHOULD be checked to verify that at least one TO, CC, or BCC header field remains. If none do, then a BCC header field with no additional information SHOULD be inserted as specified in [4].
1. 收件人、抄送或密件抄送标头字段中的每个收件人地址都应复制到RCPT命令（如果排队或传递需要，则生成多个邮件副本）。这包括RFC 822“组”中列出的任何地址。然后，应将所有密件抄送标头字段从标头部分中删除。此过程完成后，应检查剩余的标头字段，以验证是否至少保留一个to、CC或BCC标头字段。如果没有，则应按照[4]中的规定插入不包含其他信息的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 header 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 header fields 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-section-only remailer, loops back to the Internet environment (and the mailing list) are almost inevitable.
试图仅使用邮件头的“收件人”和“抄送”字段作为邮件网关，已多次导致邮件循环和其他不利于Internet邮件环境正常运行的行为。当消息来源于Internet邮件列表并使用信封信息分发到外部环境时，这些问题尤其常见。当这些消息被一个只有头段的重发器处理时，返回到Internet环境（和邮件列表）的循环几乎是不可避免的。
Historically, the <reverse-path> was a reverse source routing list of hosts and a source mailbox. The first host in the <reverse-path> was historically the host sending the MAIL command; today, source routes SHOULD NOT appear in the reverse-path. 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 (see Appendix F.2); while servers MUST be prepared to receive and handle them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT transmit them and this section is included in the current specification only to provide context. It has been modified somewhat from the material in RFC 821 to prevent server actions that might confuse clients or subsequent servers that do not expect a full source route implementation.
历史上，<reverse path>是主机和源邮箱的反向源路由列表。<reverse path>中的第一个主机历史上是发送邮件命令的主机；今天，源路由不应出现在反向路径中。类似地，<转发路径>可以是主机和目标邮箱的源路由列表。但是，一般来说，<forward path>应该只包含邮箱和域名，如果需要，依赖域名系统提供路由信息。不推荐使用源路由（见附录F.2）；虽然服务器必须准备好接收和处理它们，如第3.3节和附录F.2所述，但客户端不应传输它们，本节包含在当前规范中只是为了提供上下文。它已根据RFC 821中的材料进行了一些修改，以防止可能会混淆客户端或不希望实现完整源路由的后续服务器的服务器操作。
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 (here, JOE@ THREE) 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必须是完全限定的域名。此表格用于强调地址和路线之间的区别。邮箱（这里是JOE@THREE）是一个绝对地址，路线是关于如何到达那里的信息。这两个概念不应混淆。
If source routes are used, RFC 821 and the text below should be consulted for the mechanisms for constructing and updating the
如果使用源路由，则应参考RFC 821和以下文本，了解构建和更新源路由的机制
forward-path. A server that is reached by means of a source route (e.g., its domain name appears first in the list in the forward-path) MUST remove its domain name from any forward-paths in which that domain name appears before forwarding the message and MAY remove all other source routing information. The reverse-path SHOULD NOT be updated by servers conforming to this specification.
前进的道路。通过源路由到达的服务器（例如，其域名首先出现在转发路径的列表中）必须在转发邮件之前从该域名出现的任何转发路径中删除其域名，并可能删除所有其他源路由信息。符合本规范的服务器不应更新反向路径。
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 section. Conversely, SMTP servers MUST NOT derive final message routing information from message header fields.
请注意，转发路径和反向路径出现在SMTP命令和回复中，但不一定出现在邮件中。也就是说，不需要在消息头部分的“to:”、“From:”、“CC:”等字段中显示这些路径，尤其是该语法。相反，SMTP服务器不得从邮件头字段派生最终邮件路由信息。
When the list of hosts is present despite the recommendations above, 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. If, contrary to the recommendations here, a 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). Note that a situation could easily arise in which some relay hosts add their names to the reverse source route and others do not, generating discontinuities in the routing list. This is another reason why servers needing to return a message SHOULD ignore the source route entirely and simply use the domain as specified in the Mailbox.
尽管有上述建议，当主机列表仍然存在时，它是一个“反向”源路由，并指示邮件通过列表上的每个主机进行了中继（列表中的第一个主机是最近的中继）。此列表用作将未送达通知返回给发件人的源路由。如果与此处的建议相反，中继主机将自己添加到列表的开头，则它必须使用在其中继邮件的传输环境中已知的名称，而不是邮件来自的传输环境中的名称（如果它们不同）。请注意，很容易出现这样的情况：一些中继主机将其名称添加到反向源路由，而其他主机则不添加名称，从而在路由列表中产生不连续性。这也是为什么需要返回邮件的服务器应该完全忽略源路由而只使用邮箱中指定的域的另一个原因。
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, and 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上发送的邮件，以及在主机foo.com上发送给Jones、Green和Brown的邮件。这里我们假设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: 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: 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: 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--源主机到中继主机
The source host performs a DNS lookup on XYZ.COM (the destination address) and finds DNS MX records specifying xyz.com as the best preference and foo.com as a lower preference. It attempts to open a connection to xyz.com and fails. It then opens a connection to foo.com, with the following dialogue:
源主机在XYZ.COM（目标地址）上执行DNS查找，并查找指定XYZ.COM为最佳首选项、指定foo.COM为较低首选项的DNS MX记录。它试图打开与xyz.com的连接，但失败。然后打开到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:<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: 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
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:<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
Step 2 -- Relay Host to Destination Host
步骤2——将主机中继到目标主机
foo.com, having received the message, now does a DNS lookup on xyz.com. It finds the same set of MX records, but cannot use the one that points to itself (or to any other host as a worse preference). It tries to open a connection to xyz.com itself and succeeds. Then we have:
foo.com收到消息后，现在在xyz.com上进行DNS查找。它查找同一组MX记录，但不能使用指向自身（或指向任何其他主机作为更糟糕的首选项）的记录。它尝试打开与xyz.com本身的连接并成功。然后我们有：
S: 220 xyz.com Simple Mail Transfer Service Ready
C: EHLO foo.com
S: 250 xyz.com is on the air
C: MAIL FROM:<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:<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: 250-VRFY
S: 250 HELP
C: VRFY Crispin
S: 250 Mark Crispin <Admin.MRC@foo.com>
C: MAIL 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: 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: MAIL 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
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 mapping envelope information from one system to the message header section or body of another) have generally proven to be inadequate in important ways. Systems translating between environments that do not support both envelopes and a header section and Internet mail must be written with the understanding that some information loss is almost inevitable.
一般来说，Internet和其他邮件系统之间的网关应尝试在涉及的两个邮件系统之间的边界上保留任何分层语义。网关转换方法试图通过映射（例如将信封信息从一个系统映射到另一个系统的消息头部分或消息体）来实现快捷方式，但通常在重要方面都被证明是不够的。在不同时支持信封和标题部分以及Internet邮件的环境之间进行系统转换时，必须理解某些信息丢失几乎是不可避免的。
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 SHOULD be used rather than 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 header 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命令的响应中发布命令名。
Author's Address
作者地址
John C. Klensin 1770 Massachusetts Ave, Suite 322 Cambridge, MA 02140 USA
美国马萨诸塞州剑桥市马萨诸塞大道1770号322室，邮编02140
EMail: john+smtp@jck.com
EMail: john+smtp@jck.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.