Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 6409 QUALCOMM Incorporated
STD: 72 J. Klensin
Obsoletes: 4409 November 2011
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 6409 QUALCOMM Incorporated
STD: 72 J. Klensin
Obsoletes: 4409 November 2011
Category: Standards Track
ISSN: 2070-1721
Message Submission for Mail
邮件提交
Abstract
摘要
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
此备忘录将消息提交与消息中继分离，允许每个服务根据其自身的规则（安全、策略等）运行，并指定提交服务器要采取的操作。
Message relay is unaffected, and continues to use SMTP over port 25.
邮件中继不受影响，并继续通过端口25使用SMTP。
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
当符合本文件要求时，消息提交使用此处指定的协议，通常通过端口587。
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements.
这种功能分离提供了许多好处，包括应用特定安全或策略要求的能力。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6409.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6409.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Document Information ............................................5
2.1. Definitions of Terms Used in This Memo .....................5
2.2. Conventions Used in This Document ..........................6
3. Message Submission ..............................................6
3.1. Submission Identification ..................................6
3.2. Message Rejection and Bouncing .............................6
3.3. Authorized Submission ......................................7
4. Mandatory Actions ...............................................8
4.1. General Submission Rejection Code ..........................8
4.2. Ensure All Domains Are Fully Qualified .....................8
4.3. Require Authentication .....................................8
5. Recommended Actions .............................................9
5.1. Enforce Address Syntax .....................................9
5.2. Log Errors .................................................9
5.3. Apply Shorter Timeouts .....................................9
6. Optional Actions ...............................................10
6.1. Enforce Submission Rights .................................10
6.2. Enforce Permissions .......................................10
6.3. Check Message Data ........................................10
6.4. Support for the Postmaster Address ........................10
6.5. Adjust Character Encodings ................................11
7. Interaction with SMTP Extensions ...............................12
8. Message Modifications ..........................................13
8.1. Add 'Sender' ..............................................14
8.2. Add 'Date' ................................................14
8.3. Add 'Message-ID' ..........................................14
8.4. Transfer Encode ...........................................14
8.5. Sign the Message ..........................................14
8.6. Encrypt the Message .......................................14
8.7. Resolve Aliases ...........................................15
8.8. Header Rewriting ..........................................15
9. Security Considerations ........................................15
10. IANA Considerations ...........................................16
11. Acknowledgments ...............................................16
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................17
Appendix A. Major Changes from RFC 4409 ...........................20
1. Introduction ....................................................4
2. Document Information ............................................5
2.1. Definitions of Terms Used in This Memo .....................5
2.2. Conventions Used in This Document ..........................6
3. Message Submission ..............................................6
3.1. Submission Identification ..................................6
3.2. Message Rejection and Bouncing .............................6
3.3. Authorized Submission ......................................7
4. Mandatory Actions ...............................................8
4.1. General Submission Rejection Code ..........................8
4.2. Ensure All Domains Are Fully Qualified .....................8
4.3. Require Authentication .....................................8
5. Recommended Actions .............................................9
5.1. Enforce Address Syntax .....................................9
5.2. Log Errors .................................................9
5.3. Apply Shorter Timeouts .....................................9
6. Optional Actions ...............................................10
6.1. Enforce Submission Rights .................................10
6.2. Enforce Permissions .......................................10
6.3. Check Message Data ........................................10
6.4. Support for the Postmaster Address ........................10
6.5. Adjust Character Encodings ................................11
7. Interaction with SMTP Extensions ...............................12
8. Message Modifications ..........................................13
8.1. Add 'Sender' ..............................................14
8.2. Add 'Date' ................................................14
8.3. Add 'Message-ID' ..........................................14
8.4. Transfer Encode ...........................................14
8.5. Sign the Message ..........................................14
8.6. Encrypt the Message .......................................14
8.7. Resolve Aliases ...........................................15
8.8. Header Rewriting ..........................................15
9. Security Considerations ........................................15
10. IANA Considerations ...........................................16
11. Acknowledgments ...............................................16
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................17
Appendix A. Major Changes from RFC 4409 ...........................20
SMTP [SMTP-MTA] was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages.
SMTP[SMTP-MTA]被定义为消息*传输*协议，即路由（如果需要）和传递完成（完整）消息的方法。
Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add 'Received', 'Return-Path', and other header fields as required by [SMTP-MTA]. However, SMTP is now also widely used as a message *submission* protocol, that is, a means for Message User Agents (MUAs) to introduce new messages into the MTA routing network. The process that accepts message submissions from MUAs is termed a "Message Submission Agent" (MSA).
邮件传输代理（MTA）不应更改邮件文本，除非根据[SMTP-MTA]的要求添加“已接收”、“返回路径”和其他标头字段。然而，SMTP现在也被广泛用作消息*提交*协议，即消息用户代理（MUA）将新消息引入MTA路由网络的一种手段。接受来自MUAs的消息提交的过程称为“消息提交代理”（MSA）。
In order to permit unconstrained communications, SMTP is not often authenticated during message relay.
为了允许无限制的通信，SMTP在消息中继期间通常不进行身份验证。
Authentication and authorization of initial submissions have become increasingly important, driven by changes in security requirements and rising expectations that submission servers take responsibility for the message traffic they originate.
初始提交的身份验证和授权变得越来越重要，这是由于安全要求的变化以及提交服务器对其产生的消息流量负责的期望不断提高。
For example, due to the prevalence of machines that have worms, viruses, or other malicious software that generate large amounts of spam, many sites now prohibit outbound traffic on the standard SMTP port (port 25), funneling all mail submissions through submission servers.
例如，由于蠕虫、病毒或其他产生大量垃圾邮件的恶意软件的计算机的流行，许多站点现在禁止标准SMTP端口（端口25）上的出站通信，通过提交服务器将所有邮件提交。
In addition to authentication and authorization issues, messages being submitted are, in some cases, finished (complete) messages and, in other cases, are unfinished (incomplete) in one or more aspects. Unfinished messages may need to be completed to ensure they conform to the Message Format specification [MESSAGE-FORMAT] and related requirements. For example, the message may lack a proper 'Date' header field, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished messages (e.g., it might not know its time zone). Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way, e.g., to conceal local name or address spaces. Such completions or modifications have been shown to cause harm when performed by downstream MTAs -- that is, MTAs after the first-hop submission MTA -- and are, in general, considered to be outside the province of standardized MTA functionality.
除了身份验证和授权问题外，在某些情况下，提交的消息是已完成（完整）的消息，在其他情况下，在一个或多个方面是未完成（不完整）的消息。可能需要完成未完成的消息，以确保它们符合消息格式规范[消息格式]和相关要求。例如，消息可能缺少正确的“日期”头字段，并且域可能不是完全限定的。在某些情况下，MUA可能无法生成完成的消息（例如，它可能不知道其时区）。即使提交的邮件已完成，本地站点策略也可能要求以某种方式检查或修改邮件文本，例如隐藏本地名称或地址空间。此类完成或修改在下游MTA执行时会造成损害，即在提交MTA后的第一跳MTA执行时，通常被视为超出标准化MTA功能的范围。
Separating messages into submissions and transfers allows developers and network administrators to do the following more easily:
将消息分离为提交和传输，使开发人员和网络管理员可以更轻松地执行以下操作：
o Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail.
o 实施安全策略，防止未经授权的邮件转发或注入未经请求的批量邮件。
o Implement authenticated submission, including off-site submission by authorized users such as travelers.
o 实施认证提交，包括授权用户（如旅行者）的场外提交。
o Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission.
o 分离相关的软件代码差异，从而使每个代码库更简单，并允许不同的程序进行中继和提交。
o Detect configuration problems with a site's mail clients.
o 检测站点邮件客户端的配置问题。
o Provide a basis for adding enhanced submission services.
o 为添加增强的提交服务提供基础。
This memo describes a low-cost, deterministic means for messages to be identified as submissions, and it specifies what actions are to be taken by a submission server.
此备忘录描述了将消息标识为提交的低成本、确定性方法，并指定了提交服务器要采取的操作。
Many of the concepts and terms used in this document are defined in [SMTP-MTA]; familiarity with those documents is assumed here.
本文件中使用的许多概念和术语在[SMTP-MTA]中有定义；这里假定您熟悉这些文档。
Fully Qualified
完全合格
Containing or consisting of a domain that can be globally resolved using the Domain Name Service, that is, not a local alias or partial specification.
包含或由可使用域名服务全局解析的域组成，即不是本地别名或部分规范。
Message Submission Agent (MSA)
邮件提交代理（MSA）
A process that conforms to this specification. An MSA acts as a submission server to accept messages from MUAs, and it either delivers them or acts as an SMTP client to relay them to an MTA.
符合本规范的工艺。MSA充当提交服务器以接受来自MUA的邮件，它要么传递邮件，要么充当SMTP客户端以将邮件中继到MTA。
Message Transfer Agent (MTA)
邮件传输代理（MTA）
A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server to accept messages from an MSA or another MTA, and it either delivers them or acts as an SMTP client to relay them to another MTA.
符合[SMTP-MTA]的进程。MTA充当SMTP服务器以接受来自MSA或其他MTA的邮件，并传递邮件或充当SMTP客户端以将邮件中继到其他MTA。
Message User Agent (MUA)
消息用户代理（MUA）
A process that acts (often on behalf of a user and with a user interface) to compose and submit new messages, and to process delivered messages.
一种过程，其作用是（通常代表用户并具有用户界面）撰写和提交新消息，以及处理传递的消息。
For delivered messages, the receiving MUA may obtain and process the message according to local conventions or, in what is commonly referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP [IMAP4] is used to access delivered messages, whereas the protocol defined here (or SMTP) is used to submit messages.
对于传递的消息，接收MUA可以根据本地约定获取和处理消息，或者在通常称为拆分MUA模型的情况下，邮局协议[POP3]或IMAP[IMAP4]用于访问传递的消息，而此处定义的协议（或SMTP）用于提交消息。
Examples use the 'example.net' domain.
示例使用“example.net”域。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[关键词]中的定义进行解释。
Port 587 is reserved for email message submission as specified in this document. Messages received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA], with additional restrictions or allowances as specified here.
端口587保留用于提交本文档中指定的电子邮件。在此端口上接收的消息定义为提交。所使用的协议是ESMTP[SMTP-MTA]，此处规定了其他限制或允许。
Although most email clients and servers can be configured to use port 587 instead of 25, there are cases where this is not possible or convenient. A site MAY choose to use port 25 for message submission by designating some hosts to be MSAs and others to be MTAs.
虽然大多数电子邮件客户端和服务器可以配置为使用端口587而不是25，但在某些情况下，这是不可能或不方便的。站点可以通过将某些主机指定为MSA，而将其他主机指定为MTA来选择使用端口25进行邮件提交。
MTAs and MSAs MAY implement message rejection rules that rely, in part, on whether the message is a submission or a relay.
MTA和MSA可能会实施邮件拒绝规则，部分取决于邮件是提交还是中继。
For example, some sites might configure their MTAs to reject all RCPT commands for messages that do not reference local users, and they might configure their MSA to reject all message submissions that do not come from authorized users, with authorization based on either the authenticated identity or the submitting endpoint being within a protected IP environment.
例如，某些站点可能会将其MTA配置为拒绝所有针对不引用本地用户的邮件的RCPT命令，并且可能会将其MSA配置为拒绝所有非授权用户提交的邮件，使用基于身份验证的身份或受保护IP环境中的提交端点的授权。
NOTE: It is better to reject a message than to risk sending one that is damaged. This is especially true for problems that are correctable by the MUA, for example, an invalid 'From' field.
注意：拒绝邮件比冒发送损坏邮件的风险要好。对于可由MUA纠正的问题尤其如此，例如，无效的“发件人”字段。
If an MSA is not able to determine a return path to the submitting user, from a valid MAIL FROM, a valid source IP address, or based on authenticated identity, then the MSA SHOULD immediately reject the message. A message can be immediately rejected by returning a 550 code to the MAIL command.
如果MSA无法根据有效的邮件来源、有效的源IP地址或身份验证确定提交用户的返回路径，则MSA应立即拒绝该消息。通过向MAIL命令返回550代码，可以立即拒绝邮件。
Note that a null return path, that is, MAIL FROM:<>, is permitted and MUST NOT, in itself, be cause for rejecting a message. (MUAs need to generate null return-path messages for a variety of reasons, including disposition notifications.)
请注意，允许使用空返回路径，即邮件发件人：<>，并且其本身不能成为拒绝邮件的原因。（由于各种原因，包括处置通知，MUA需要生成空返回路径消息。）
Except in the case where the MSA is unable to determine a valid return path for the message being submitted, text in this specification that instructs an MSA to issue a rejection code MAY be complied with by accepting the message and subsequently generating a bounce message. (That is, if the MSA is going to reject a message for any reason except being unable to determine a return path, it can optionally do an immediate rejection or accept the message and then mail a bounce.)
除MSA无法确定所提交消息的有效返回路径的情况外，本规范中指示MSA发出拒绝代码的文本可通过接受消息并随后生成跳出消息来遵守。（也就是说，如果MSA出于除无法确定返回路径之外的任何原因拒绝邮件，它可以选择立即拒绝或接受邮件，然后发送回退邮件。）
NOTE: In the normal case of message submission, immediately rejecting the message is preferred, as it gives the user and MUA direct feedback. To properly handle delayed bounces, the client MUA needs to maintain a queue of messages it has submitted and match bounces to them. Note that many contemporary MUAs do not have this capability.
注意：在消息提交的正常情况下，最好立即拒绝消息，因为它会给用户和MUA直接反馈。为了正确处理延迟的反弹，客户机MUA需要维护它已提交的消息队列，并将反弹匹配到它们。请注意，许多当代MUA不具备此功能。
Numerous methods have been used to ensure that only authorized users are able to submit messages. These methods include authenticated SMTP, IP address restrictions, secure IP and other tunnels, and prior POP authentication.
已经使用了许多方法来确保只有经过授权的用户才能提交消息。这些方法包括经过身份验证的SMTP、IP地址限制、安全IP和其他隧道，以及预先的POP身份验证。
Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It allows the MSA to determine an authorization identity for the message submission, one that is not tied to other protocols.
经过身份验证的SMTP[SMTP-AUTH]已广泛部署。它允许MSA确定消息提交的授权标识，该标识与其他协议无关。
IP address restrictions are very widely implemented, but they do not allow for travelers and similar situations, and they can be easily spoofed unless all transport paths between the MUA and MSA are trustworthy.
IP地址限制的实施非常广泛，但它们不允许旅行者和类似情况，并且它们很容易被欺骗，除非MUA和MSA之间的所有传输路径都是可信的。
Secure IP [IPSEC], and other encrypted and authenticated tunneling techniques, can also be used and provide additional benefits of protection against eavesdropping and traffic analysis.
还可以使用安全IP[IPSEC]和其他加密和认证的隧道技术，并提供防止窃听和流量分析的额外好处。
Requiring a POP [POP3] authentication (from the same IP address) within some amount of time (e.g., 20 minutes) prior to the start of a
需要在启动前的一段时间内（例如，20分钟）进行POP[POP3]身份验证（来自同一IP地址）
message submission session has also been used, but this does impose restrictions on clients as well as servers, which may cause difficulties. Specifically, the client must do a POP authentication before an SMTP submission session, and not all clients are capable and configured for this. Also, the MSA must coordinate with the POP server, which may be difficult. There is also a window during which an unauthorized user can submit messages and appear to be a previously authorized user. Since it is dependent on the MUA's IP addresses, this technique is substantially as subject to IP address spoofing as validation based on known IP addresses alone (see above).
还使用了消息提交会话，但这会对客户端和服务器施加限制，这可能会造成困难。具体来说，客户端必须在SMTP提交会话之前执行POP身份验证，并且并非所有客户端都能够并配置此功能。此外，MSA必须与POP服务器协调，这可能很困难。还有一个窗口，在此窗口中，未经授权的用户可以提交消息，并显示为以前授权的用户。由于它依赖于MUA的IP地址，因此该技术实质上与仅基于已知IP地址的验证一样容易受到IP地址欺骗的影响（见上文）。
An MSA MUST do all of the following:
MSA必须执行以下所有操作：
Unless covered by a more precise response code, response code 554 is to be used to reject a MAIL, RCPT, or DATA command that contains something improper.
除非包含更精确的响应代码，否则响应代码554将用于拒绝包含不正确内容的邮件、RCPT或数据命令。
The MSA MUST ensure that all domains in the SMTP envelope are fully qualified.
MSA必须确保SMTP信封中的所有域都是完全限定的。
If the MSA examines or alters the message text in any way, except to add trace header fields [SMTP-MTA], it MUST ensure that all domains in address header fields are fully qualified.
如果MSA以任何方式检查或更改邮件文本，除了添加跟踪标头字段[SMTP-MTA]，它必须确保地址标头字段中的所有域都是完全限定的。
Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command that contains improper domain references.
回复代码554用于拒绝包含不正确域引用的邮件、RCPT或数据命令。
A frequent local convention is to accept single-level domains (e.g., 'sales') and then to expand the reference by adding the remaining portion of the domain name (e.g., to 'sales.example.net'). Local conventions that permit single-level domains SHOULD reject, rather than expand, incomplete multi-level domains (e.g., 'squeaky.sales'), since such expansion is particularly risky.
一种常见的本地约定是接受单级域（如“sales”），然后通过添加域名的剩余部分（如“sales.example.net”）来扩展引用。允许单级域的本地约定应该拒绝而不是扩展不完整的多级域（例如，“squeky.sales”），因为这种扩展尤其危险。
The MSA MUST, by default, issue an error response to the MAIL command if the session has not been authenticated using [SMTP-AUTH], unless it has already independently established authentication or authorization (such as being within a protected subnetwork).
默认情况下，如果会话未使用[SMTP-AUTH]进行身份验证，MSA必须对邮件命令发出错误响应，除非它已独立建立身份验证或授权（例如在受保护的子网内）。
Section 3.3 discusses authentication mechanisms.
第3.3节讨论了身份验证机制。
Reply code 530 [SMTP-AUTH] is used for this purpose.
回复代码530[SMTP-AUTH]用于此目的。
The MSA SHOULD do all of the following.
MSA应执行以下所有操作。
An MSA SHOULD reject messages with illegal syntax in a sender or recipient SMTP envelope address.
MSA应拒绝发件人或收件人SMTP信封地址中语法非法的邮件。
If the MSA examines or alters the message text in any way, except to add trace header fields, it SHOULD reject messages with illegal address syntax in address header fields.
如果MSA以任何方式检查或更改消息文本（添加跟踪头字段除外），则应拒绝在地址头字段中使用非法地址语法的消息。
Reply code 501 is to be used to reject a MAIL or RCPT command that contains a detectably improper address.
回复代码501用于拒绝包含可检测到的不正确地址的邮件或RCPT命令。
When addresses are resolved after submission of the message body, reply code 554 (with a suitable enhanced status code from [SMTP-CODES]) is used after end-of-data, if the message contains invalid addresses in the header.
在提交邮件正文后解析地址时，如果邮件标题中包含无效地址，则在数据结束后使用回复代码554（带有[SMTP-CODES]中的适当增强状态代码）。
The MSA SHOULD log message errors, especially apparent misconfigurations of client software.
MSA应记录消息错误，尤其是客户端软件的明显错误配置。
It can be very helpful to notify the administrator when problems are detected with local mail clients. This is another advantage of distinguishing submission from relay: system administrators might be interested in local configuration problems, but not in client problems at other sites.
当检测到本地邮件客户端出现问题时，通知管理员会非常有帮助。这是区别提交和中继的另一个优点：系统管理员可能对本地配置问题感兴趣，但对其他站点的客户端问题不感兴趣。
Note that it is important to impose limits on such logging to prevent certain forms of denial-of-service (DoS) attacks.
请注意，必须对此类日志设置限制，以防止某些形式的拒绝服务（DoS）攻击。
The timeouts specified in Section 4.5.3.2 of RFC 5321 [SMTP-MTA] are designed to deal with the many types of situations that can be encountered on the public Internet. The relationship among clients and servers corresponding to this specification is typically much closer and more predictable. Submission clients behave differently from relay client in some areas, especially tolerance for timeouts. In practice, message submission clients tend to have short timeouts (perhaps 2-5 minutes for a reply to any command). Submission servers SHOULD respond to any command (even DATA) in fewer than 2 minutes.
RFC 5321[SMTP-MTA]第4.5.3.2节中规定的超时旨在处理公共互联网上可能遇到的多种情况。与此规范相对应的客户机和服务器之间的关系通常更密切，也更可预测。提交客户端在某些方面的行为与中继客户端不同，特别是对超时的容忍度。在实践中，消息提交客户端往往会有短暂的超时（对于任何命令的回复，可能需要2-5分钟）。提交服务器应在2分钟内响应任何命令（甚至数据）。
When the submission server has a close administrative and/or network relationship with the submission client(s) -- e.g., with a webmail interface calling on a tightly bound submission server -- mutual agreement on much shorter timeouts MAY be appropriate.
当提交服务器与提交客户端有着密切的管理和/或网络关系时（例如，通过在紧密绑定的提交服务器上调用webmail接口），双方就更短的超时时间达成一致可能是合适的。
The MSA MAY do any of the following.
MSA可以执行以下任何操作。
The MSA MAY issue an error response to a MAIL command if the address in MAIL FROM appears to have insufficient submission rights or is not authorized with the authentication used (if the session has been authenticated).
如果来自的邮件中的地址似乎没有足够的提交权限，或者未使用所使用的身份验证进行授权（如果会话已通过身份验证），MSA可能会对邮件命令发出错误响应。
Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose.
回复代码550，根据[SMTP-CODES]使用适当的增强状态代码，如5.7.1，用于此目的。
The MSA MAY issue an error response to a RCPT command if inconsistent with the permissions given to the user (if the session has been authenticated).
如果与授予用户的权限不一致（如果会话已通过身份验证），MSA可能会对RCPT命令发出错误响应。
Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose.
回复代码550，根据[SMTP-CODES]使用适当的增强状态代码，如5.7.1，用于此目的。
The MSA MAY issue an error response to the DATA command or send a failure result after end-of-data if the submitted message is syntactically invalid, seems inconsistent with permissions given to the user (if known), or violates site policy in some way.
如果提交的消息在语法上无效，似乎与授予用户的权限（如果已知）不一致，或者以某种方式违反站点策略，MSA可能会对数据命令发出错误响应，或者在数据结束后发送失败结果。
Reply code 554 is used for syntactic problems in the data. Reply code 501 is used if the command itself is not syntactically valid. Reply code 550 with an appropriate enhanced status code per [SMTP-CODES] (such as 5.7.1) is used to reject based on the submitting user. Reply code 550 with an appropriate enhanced status code (such as 5.7.0) is used if the message violates site policy.
回复代码554用于解决数据中的语法问题。如果命令本身在语法上无效，则使用回复代码501。根据[SMTP-CODES]（如5.7.1）使用带有适当增强状态代码的回复代码550根据提交用户进行拒绝。如果消息违反站点策略，则使用带有适当增强状态代码（如5.7.0）的回复代码550。
If appropriate under local conditions and to facilitate conformance with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit a reduced degree of authentication for mail addressed to the "postmaster" (or one of its alternate spelling forms, see
如果在当地条件下合适，并且为了便于符合[SMTP-MTA]中的“邮政局长”要求，MSA可能会允许对发送给“邮政局长”的邮件进行较低程度的身份验证（或其另一种拼写形式，请参见
[SMTP-MTA]), in one or more domains, as compared to requirements enforced for other addresses. Among other benefits, this provides an address of last resort that can be used by authorized users to report problems that otherwise prevent them from submitting mail.
[SMTP-MTA]），与对其他地址强制执行的要求相比。在其他好处中，这提供了一个最后的解决方法，授权用户可以使用该地址报告问题，否则将阻止他们提交邮件。
Subject to limits imposed by other protocols and specifications, the MSA MAY convert among character sets or string encodings to improve message usefulness, likelihood of delivery, or conformance with other specifications or recommendations. Such conversions MAY include, when necessary, replacement of addresses whose encoding does not conform to RFC 5321 with ones that do, using information available out of band.
根据其他协议和规范施加的限制，MSA可以在字符集或字符串编码之间转换，以提高消息的有用性、传递的可能性或与其他规范或建议的一致性。必要时，此类转换可包括使用带外可用信息将编码不符合RFC 5321的地址替换为符合RFC 5321的地址。
The following table lists Standards Track and Experimental SMTP extensions whose documents do not explicitly specify their applicability to this protocol. Listed are the EHLO keyword, name, an indication as to the use of the extension on the submit port, and a reference.
下表列出了标准跟踪和实验性SMTP扩展，这些扩展的文档未明确指定其对此协议的适用性。列出了EHLO关键字、名称、提交端口上使用扩展的指示以及引用。
+--------------------+----------------------+--------+-----------------+
| Keyword | Name |Sub- | Reference |
| | |mission | |
+--------------------+----------------------+--------+-----------------+
|PIPELINING |Pipelining |SHOULD |[PIPELINING] |
|ENHANCEDSTATUSCODES |Enhanced Status Codes |SHOULD |[CODES-EXTENSION]|
|ETRN |Extended Turn |MUST NOT|[ETRN] |
| ... |Extended Codes |SHOULD |[SMTP-CODES] |
|DSN |Delivery Status |SHOULD |[DSN] |
| | Notification | | |
|SIZE |Message size |MAY |[SIZE] |
| ... |521 reply code |MUST NOT|[REPLY-521] |
|CHECKPOINT |Checkpoint/Restart |MAY |[CHECKPOINT] |
|BINARYMIME |Binary MIME |MAY |[CHUNKING] |
|CHUNKING |Chunking |MAY |[CHUNKING] |
|8BITMIME |Use 8-bit data |SHOULD |[RFC6152] |
|AUTH |Authentication |MUST |[SMTP-AUTH] |
|STARTTLS |Start TLS |MAY |[START-TLS] |
|NO-SOLICITING |Notification of |MAY |[RFC3865] |
| | no soliciting | | |
|MTRK |Message Tracking |MAY |[MSG-TRACK] |
|ATRN |On-Demand Relay |MUST NOT|[RFC2645] |
|DELIVERBY |Deliver By |MAY |[RFC2852] |
|CONPERM |Content Conversion |MAY |[RFC4141] |
| | Permission | | |
|CONNEG |Content Conversion |MAY |[RFC4141] |
| | Negotiation | | |
+--------------------+----------------------+--------+-----------------+
Table 1
+--------------------+----------------------+--------+-----------------+
| Keyword | Name |Sub- | Reference |
| | |mission | |
+--------------------+----------------------+--------+-----------------+
|PIPELINING |Pipelining |SHOULD |[PIPELINING] |
|ENHANCEDSTATUSCODES |Enhanced Status Codes |SHOULD |[CODES-EXTENSION]|
|ETRN |Extended Turn |MUST NOT|[ETRN] |
| ... |Extended Codes |SHOULD |[SMTP-CODES] |
|DSN |Delivery Status |SHOULD |[DSN] |
| | Notification | | |
|SIZE |Message size |MAY |[SIZE] |
| ... |521 reply code |MUST NOT|[REPLY-521] |
|CHECKPOINT |Checkpoint/Restart |MAY |[CHECKPOINT] |
|BINARYMIME |Binary MIME |MAY |[CHUNKING] |
|CHUNKING |Chunking |MAY |[CHUNKING] |
|8BITMIME |Use 8-bit data |SHOULD |[RFC6152] |
|AUTH |Authentication |MUST |[SMTP-AUTH] |
|STARTTLS |Start TLS |MAY |[START-TLS] |
|NO-SOLICITING |Notification of |MAY |[RFC3865] |
| | no soliciting | | |
|MTRK |Message Tracking |MAY |[MSG-TRACK] |
|ATRN |On-Demand Relay |MUST NOT|[RFC2645] |
|DELIVERBY |Deliver By |MAY |[RFC2852] |
|CONPERM |Content Conversion |MAY |[RFC4141] |
| | Permission | | |
|CONNEG |Content Conversion |MAY |[RFC4141] |
| | Negotiation | | |
+--------------------+----------------------+--------+-----------------+
Table 1
Future SMTP extensions SHOULD explicitly specify if they are valid on the Submission port.
未来的SMTP扩展应明确指定它们在提交端口上是否有效。
Some SMTP extensions are especially useful for message submission:
某些SMTP扩展对于邮件提交特别有用：
Extended Status Codes [SMTP-CODES] SHOULD be supported and used according to [CODES-EXTENSION]. This permits the MSA to notify the client of specific configuration or other problems in more detail than the response codes listed in this memo. Because some rejections
应支持扩展状态代码[SMTP-Codes]，并根据[Codes-EXTENSION]使用扩展状态代码。这允许MSA将特定配置或其他问题通知客户，其详细程度超过本备忘录中列出的响应代码。因为有些拒绝
are related to a site's security policy, care should be used not to expose more detail to unauthenticated senders than is needed.
与站点的安全策略相关，应注意不要向未经身份验证的发件人透露超出需要的更多详细信息。
[PIPELINING] SHOULD be supported by the MSA.
[管道]应得到MSA的支持。
[SMTP-AUTH] allows the MSA to validate the authority and determine the identity of the submitting user and MUST be supported by the MSA.
[SMTP-AUTH]允许MSA验证权限并确定提交用户的身份，并且必须得到MSA的支持。
[START-TLS] is the most widely used mechanism, at the time this document was written, that allows the MUA and MSA to protect message submission integrity and privacy.
[START-TLS]是编写本文档时使用最广泛的机制，允许MUA和MSA保护消息提交完整性和隐私。
Any references to the DATA command in this memo also refer to any substitutes for DATA, such as the BDAT command used with [CHUNKING].
本备忘录中对DATA命令的任何引用也指数据的任何替代品，例如与[CHUNKING]一起使用的BDAT命令。
Sites MAY modify submissions to ensure compliance with standards and site policy. This section describes a number of such modifications that are often considered useful.
现场可修改提交内容，以确保符合标准和现场政策。本节描述了一些通常认为有用的修改。
NOTE: As a matter of guidance for local decisions to implement message modification, a paramount rule is to limit such actions to remedies for specific problems that have clear solutions. This is especially true with address elements. For example, indiscriminately appending a domain to an address or element that lacks one typically results in more broken addresses. An unqualified address must be verified to be a valid local part in the domain before the domain can be safely added.
注意：作为本地决定实施消息修改的指导，最重要的规则是将此类操作限制为针对具有明确解决方案的特定问题的补救措施。地址元素尤其如此。例如，不加区分地将域附加到缺少域的地址或元素通常会导致更多断开的地址。必须验证非限定地址是否为域中的有效本地部分，然后才能安全添加域。
Any message forwarded or delivered by the MSA MUST conform to the requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements permitted by extensions that are supported by the MSA and accepted by the next-hop server.
MSA转发或传递的任何邮件必须符合[SMTP-MTA]和[message-FORMAT]的要求，或MSA支持并为下一跳服务器接受的扩展所允许的要求。
Message modification can affect the validity of an existing message signature, such as by DomainKeys Identified Mail (DKIM) [DKIM], Pretty Good Privacy (PGP) [RFC4880], or Secure MIME (S/MIME) [RFC5751], and can render the signature invalid. This, in turn, can affect message handling by later receivers, such as filtering engines that consider the presence or absence of a valid signature.
消息修改可能会影响现有消息签名的有效性，例如通过域密钥标识邮件（DKIM）[DKIM]、相当好的隐私（PGP）[RFC4880]或安全MIME（S/MIME）[RFC5751]，并可能导致签名无效。这反过来又会影响后续接收器的消息处理，例如考虑有效签名的存在或不存在的过滤引擎。
The MSA MAY add or replace the 'Sender' field, if the identity of the sender is known and this is not given in the 'From' field.
如果发送者的身份已知且“发件人”字段中未给出，MSA可以添加或替换“发送者”字段。
The MSA MUST ensure that any address it places in a 'Sender' field is, in fact, a valid mail address.
MSA必须确保其在“发件人”字段中放置的任何地址实际上都是有效的邮件地址。
The MSA MAY add a 'Date' field to the submitted message, if it lacks it, or correct the 'Date' field if it does not conform to [MESSAGE-FORMAT] syntax.
MSA可以在提交的邮件中添加“日期”字段（如果没有），或者在“日期”字段不符合[message-FORMAT]语法的情况下更正该字段。
The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note that a number of clients still do not generate 'Message-ID' fields.
MSA应添加或替换“消息ID”字段，如果该字段缺少该字段，或者该字段的语法无效（如[Message-FORMAT]所定义）。请注意，许多客户端仍然不生成“消息ID”字段。
The MSA MAY apply transfer encoding to the message according to MIME conventions, if needed and not harmful to the MIME type.
如果需要并且对MIME类型无害，MSA可以根据MIME约定对消息应用传输编码。
The MSA MAY (digitally) sign or otherwise add authentication information to the message.
MSA可以（数字）签名或以其他方式向消息添加身份验证信息。
The MSA MAY encrypt the message for transport to reflect organizational policies.
MSA可以加密传输消息以反映组织策略。
NOTE: To be useful, the addition of a signature and/or encryption by the MSA generally implies that the connection between the MUA and MSA must, itself, be secured in some other way, for example, by operating inside of a secure environment, by securing the submission connection at the transport layer, or by using an [SMTP-AUTH] mechanism that provides for session integrity.
注：为了有用，MSA添加签名和/或加密通常意味着MUA和MSA之间的连接本身必须以其他方式进行安全保护，例如，通过在安全环境内操作、通过在传输层保护提交连接或使用[SMTP-AUTH]提供会话完整性的机制。
The MSA MAY resolve and rewrite aliases (e.g., Canonical Name (CNAME) records) for domain names, in the SMTP envelope and/or in address fields of the header, subject to local policy.
MSA可根据本地政策，在SMTP信封和/或标头的地址字段中解析和重写域名的别名（例如，规范名称（CNAME）记录）。
NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in addresses and the session-opening announcement. As with other SMTP requirements, RFC 5321 effectively prohibits an MSA from forwarding such messages into the public Internet. Nonetheless, unconditionally resolving aliases could be harmful. For example, if www.example.net and ftp.example.net are both aliases for mail.example.net, rewriting them could lose useful information.
注意：SMTP[SMTP-MTA]禁止在地址和会话打开公告中使用域名别名。与其他SMTP要求一样，RFC 5321有效地禁止MSA将此类邮件转发到公共互联网。尽管如此，无条件解析别名可能是有害的。例如，如果www.example.net和ftp.example.net都是mail.example.net的别名，则重写它们可能会丢失有用的信息。
The MSA MAY rewrite local parts and/or domains in the SMTP envelope and, optionally, in address fields of the header, according to local policy. For example, a site may prefer to rewrite 'JRU' as 'J.Random.User' in order to hide login names and/or to rewrite 'squeaky.sales.example.net' as 'zyx.example.net' to hide machine names and make it easier to move users.
MSA可以根据本地策略重写SMTP信封中的本地部分和/或域，也可以重写标头的地址字段中的本地部分和/或域。例如，网站可能更喜欢将“JRU”重写为“J.Random.User”以隐藏登录名和/或将“squeky.sales.example.net”重写为“zyx.example.net”以隐藏机器名并更容易移动用户。
However, only addresses, local-parts, or domains that match specific local MSA configuration settings should be altered. It would be very dangerous for the MSA to apply data-independent rewriting rules, such as always deleting the first element of a domain name. So, for example, a rule that strips the leftmost element of the domain, if the complete domain matches '*.foo.example.net', would be acceptable.
但是，仅应更改与特定本地MSA配置设置匹配的地址、本地部分或域。MSA应用独立于数据的重写规则是非常危险的，例如总是删除域名的第一个元素。因此，例如，如果完整的域与“*.foo.example.net”匹配，则可以接受一条规则，该规则将剥离域中最左边的元素。
The MSA MUST NOT rewrite a forward-pointing (destination) address in a way that violates the constraints of [SMTP-MTA] on modifications of local-parts. Changes to addressing and encoding, carried out in conjunction with the action of Section 6.5, do not violate this principle if the MSA has sufficient information available to successfully and accurately apply the substitution.
MSA不得以违反[SMTP-MTA]对修改本地部分的限制的方式重写前向指向（目标）地址。如果MSA有足够的可用信息成功和准确地应用替换，则结合第6.5节的行动对寻址和编码进行的更改不会违反此原则。
Separation of submission and relay of messages allows a site to implement different policies for the two types of services, including requiring the use of additional security mechanisms for one or both. It can do this in a way that is simpler, both technically and administratively. This increases the likelihood that policies will be applied correctly.
消息的提交和转发分离允许站点为两种类型的服务实施不同的策略，包括要求对一种或两种服务使用额外的安全机制。它可以以一种更简单的方式做到这一点，无论是在技术上还是在管理上。这增加了正确应用政策的可能性。
Separation also can aid in tracking and preventing unsolicited bulk email.
分离还可以帮助跟踪和防止未经请求的批量电子邮件。
For example, a site could configure its mail servers such that the MSA requires authentication before accepting a message, and the MTA rejects all RCPT commands for non-local users. This can be an important element in a site's total email security policy.
例如，站点可以配置其邮件服务器，以便MSA在接受邮件之前需要身份验证，MTA拒绝非本地用户的所有RCPT命令。这可能是网站总体电子邮件安全策略中的一个重要元素。
If a site fails to require any form of authorization for message submissions (see Section 3.3 for discussion), it is allowing open use of its resources and name; unsolicited bulk email can be injected using its facilities.
如果网站未要求任何形式的消息提交授权（讨论见第3.3节），则允许公开使用其资源和名称；未经请求的批量电子邮件可以使用其设施注入。
Section 3 includes further discussion of issues with some authentication methods.
第3节进一步讨论了一些身份验证方法的问题。
Section 5.2 includes a cautionary note that unlimited logging can enable certain forms of denial-of-service attacks.
第5.2节包括一个警告说明，无限日志记录可能会导致某些形式的拒绝服务攻击。
The entries in Table 1 have been corrected (reference for NO-SOLICITING) and extended (ATRN, DELIVERBY, CONPERM, and CONNEG). The "SMTP Service Extensions" registry has been updated to reflect the changed and new entries. Entries in the registry that do not appear in the table above are correct and should not be altered.
表1中的条目已被更正（无邀约参考）和扩展（ATRN、DeliveryBy、CONPERM和CONNEG）。“SMTP服务扩展”注册表已更新，以反映更改的条目和新条目。注册表中未出现在上表中的条目是正确的，不应更改。
The entry in the "SMTP Service Extensions" registry for RFC 4409 has been updated to reference this document. The original reference for Submit (RFC 2476), which should have been corrected earlier, has also been updated to point to this document.
RFC 4409的“SMTP服务扩展”注册表中的条目已更新为引用此文档。提交的原始参考文件（RFC 2476）本应在早些时候更正，但也已更新，以指向本文件。
The entry in the "Service Name and Transport Protocol Port Number Registry" for port 587 has been updated to point to this document.
端口587的“服务名称和传输协议端口号注册表”中的条目已更新为指向此文档。
The preparation and development of the current version of this specification was stimulated by discussions in the IETF YAM and EAI Working Groups. Dave Crocker, Subramanian Moonesamy, Barry Leiba, John Levine, and others provided text that appeared in this document or versions leading up to it.
IETF YAM和EAI工作组的讨论促进了本规范当前版本的编制和开发。Dave Crocker、Subramanian Moonesamy、Barry Leiba、John Levine和其他人提供了出现在本文档或其之前版本中的文本。
Nathaniel Borenstein and Barry Leiba were instrumental in the development of RFC 4409, the update to RFC 2476.
纳撒尼尔·博伦斯坦（Nathaniel Borenstein）和巴里·莱巴（Barry Leiba）在RFC 4409（RFC 2476的更新）的开发过程中发挥了重要作用。
The original memo (RFC 2476) was developed, in part, based on comments and discussions that took place on and off the IETF-Submit
最初的备忘录（RFC 2476）部分基于IETF提交时和提交后的评论和讨论
mailing list. The help of those who took the time to review that document and make suggestions is appreciated, especially that of Dave Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman.
邮件列表。感谢那些花时间审阅该文件并提出建议的人的帮助，特别是戴夫·克罗克、内德·弗里德、基思·摩尔、约翰·迈尔斯和克里斯·纽曼的帮助。
Special thanks to Harald Alvestrand, who got this effort started.
特别感谢Harald Alvestrand，他开始了这项工作。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SMTP-AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[SMTP-AUTH]Siemborski，R.和A.Melnikov，“用于身份验证的SMTP服务扩展”，RFC 49542007年7月。
[SMTP-MTA] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP-MTA]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[CHECKPOINT] Crocker, D. and N. Freed, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995.
[检查点]Crocker，D.和N.Freed，“检查点/重启的SMTP服务扩展”，RFC 18451995年9月。
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[CHUNKING]Vaudreuil，G.，“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 3030，2000年12月。
[CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[CODES-EXTENSION]Freed，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 2034，1996年10月。
[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[DKIM]Crocker，D.，Hansen，T.，和M.Kucherawy，“域密钥识别邮件（DKIM）签名”，RFC 63762011年9月。
[DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 34612003年1月。
[ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.
[ETRN]De Winter，J.，“远程消息队列启动的SMTP服务扩展”，RFC 1985，1996年8月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[MESSAGE-FORMAT] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[信息格式]Resnick，P.，Ed.“互联网信息格式”，RFC5322，2008年10月。
[MSG-TRACK] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.
[MSG-TRACK]Allman，E.和T.Hansen，“用于邮件跟踪的SMTP服务扩展”，RFC 38852004年9月。
[PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[PIPELINING]Freed，N.，“用于命令管道的SMTP服务扩展”，STD 60，RFC 2920，2000年9月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[REPLY-521] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995.
[回复-521]杜兰德，A.和F.杜邦，“SMTP 521回复代码”，RFC 18461995年9月。
[RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999.
[RFC2645]Gellens，R.，“具有动态IP地址的按需邮件中继（ODMR）SMTP”，RFC 26451999年8月。
[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[RFC2852]Newman，D.，“通过SMTP服务扩展交付”，RFC 2852000年6月。
[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, September 2004.
[RFC3865]Malamud，C.，“一个无请求的简单邮件传输协议（SMTP）服务扩展”，RFC3865，2004年9月。
[RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for Content Conversion", RFC 4141, November 2005.
[RFC4141]丰田章男，K.和D.克罗克，“用于内容转换的SMTP和MIME扩展”，RFC41412005年11月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.
[RFC6152]Klensin，J.，Freed，N.，Rose，M.，和D.Crocker，“8位MIME传输的SMTP服务扩展”，STD 71，RFC 6152，2011年3月。
[SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
[SIZE]Klensin，J.，Freed，N.和K.Moore，“邮件大小声明的SMTP服务扩展”，STD 10，RFC 1870，1995年11月。
[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[SMTP-CODES]Vaudreuil，G.“增强邮件系统状态代码”，RFC 3463，2003年1月。
[START-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[START-TLS]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，2002年2月。
The protocol specified by this document is not substantively different from that of RFC 4409. However, the present specification contains several clarifications and updates to reflect changes and revisions to other documents subsequent to the publication of RFC 4409. The following specific changes may be of interest to some readers.
本文件规定的协议与RFC 4409的协议并无实质性差异。然而，本规范包含若干澄清和更新，以反映RFC 4409发布后对其他文件的更改和修订。一些读者可能会对以下具体更改感兴趣。
o Updated several references to reflect more recent versions of the various specifications. As part of this, reclassified RFC 4954 to a normative reference (SMTP AUTH is a MUST for RFC 4409 and this specification).
o 更新了多个参考，以反映各种规范的最新版本。作为其中的一部分，将RFC 4954重新分类为规范性参考文件（对于RFC 4409和本规范，SMTP认证是必须的）。
o Updated the text in Section 7 to reflect the existence and partial population of the registry and the included table (Table 1) to correct one entry and add others. See Section 10 for more information.
o 更新第7节中的文本，以反映登记册的存在和部分人口，并包括表（表1），以更正一个条目并添加其他条目。更多信息请参见第10节。
o Added new text (Section 5.3) to clarify that Submission Servers should respond quickly.
o 添加了新文本（第5.3节），以澄清提交服务器应快速响应。
o Added text to make it explicit that character encoding changes are permitted.
o 添加文本以明确允许更改字符编码。
o Added text to make it clear that modifications to signed messages may cause problems and that they should be carefully considered.
o 添加文本，以明确对已签名消息的修改可能会导致问题，应仔细考虑这些问题。
Authors' Addresses
作者地址
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-2779 USA
美国加利福尼亚州圣地亚哥Morehouse大道5775号美国高通公司Randall Gellens 92121-2779
EMail: rg+ietf@qualcomm.com
EMail: rg+ietf@qualcomm.com
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
美国马萨诸塞州剑桥市322号马萨诸塞大道1770号约翰·C·克伦辛，邮编：02140
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Phone: +1 617 491 5735
EMail: john-ietf@jck.com