Network Working Group R. Gellens
Request for Comments: 4409 QUALCOMM
Obsoletes: 2476 J. Klensin
Category: Standards Track April 2006
Network Working Group R. Gellens
Request for Comments: 4409 QUALCOMM
Obsoletes: 2476 J. Klensin
Category: Standards Track April 2006
Message Submission for Mail
邮件提交
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 and final delivery are unaffected, and continue 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.
这种功能分离提供了许多好处，包括应用特定安全或策略要求的能力。
Table of Contents
目录
1. Introduction ....................................................3
2. Document Information ............................................4
2.1. Definitions of Terms Used in This Memo .....................4
2.2. Conventions Used in This Document ..........................5
3. Message Submission ..............................................5
3.1. Submission Identification ..................................5
3.2. Message Rejection and Bouncing .............................5
3.3. Authorized Submission ......................................6
4. Mandatory Actions ...............................................7
4.1. General Submission Rejection Code ..........................7
4.2. Ensure All Domains Are Fully-Qualified .....................7
4.3. Require Authentication .....................................8
5. Recommended Actions .............................................8
5.1. Enforce Address Syntax .....................................8
5.2. Log Errors .................................................8
6. Optional Actions ................................................9
6.1. Enforce Submission Rights ..................................9
6.2. Enforce Permissions ........................................9
6.3. Check Message Data .........................................9
6.4. Support for the Postmaster Address .........................9
7. Interaction with SMTP Extensions ...............................10
8. Message Modifications ..........................................11
8.1. Add 'Sender' ..............................................11
8.2. Add 'Date' ................................................11
8.3. Add 'Message-ID' ..........................................11
8.4. Transfer Encode ...........................................11
8.5. Sign the Message ..........................................11
8.6. Encrypt the Message .......................................12
8.7. Resolve Aliases ...........................................12
8.8. Header Rewriting ..........................................12
9. Security Considerations ........................................12
10. IANA Considerations ...........................................13
11. Acknowledgements ..............................................13
12. Normative References ..........................................14
13. Informative References ........................................14
1. Introduction ....................................................3
2. Document Information ............................................4
2.1. Definitions of Terms Used in This Memo .....................4
2.2. Conventions Used in This Document ..........................5
3. Message Submission ..............................................5
3.1. Submission Identification ..................................5
3.2. Message Rejection and Bouncing .............................5
3.3. Authorized Submission ......................................6
4. Mandatory Actions ...............................................7
4.1. General Submission Rejection Code ..........................7
4.2. Ensure All Domains Are Fully-Qualified .....................7
4.3. Require Authentication .....................................8
5. Recommended Actions .............................................8
5.1. Enforce Address Syntax .....................................8
5.2. Log Errors .................................................8
6. Optional Actions ................................................9
6.1. Enforce Submission Rights ..................................9
6.2. Enforce Permissions ........................................9
6.3. Check Message Data .........................................9
6.4. Support for the Postmaster Address .........................9
7. Interaction with SMTP Extensions ...............................10
8. Message Modifications ..........................................11
8.1. Add 'Sender' ..............................................11
8.2. Add 'Date' ................................................11
8.3. Add 'Message-ID' ..........................................11
8.4. Transfer Encode ...........................................11
8.5. Sign the Message ..........................................11
8.6. Encrypt the Message .......................................12
8.7. Resolve Aliases ...........................................12
8.8. Header Rewriting ..........................................12
9. Security Considerations ........................................12
10. IANA Considerations ...........................................13
11. Acknowledgements ..............................................13
12. Normative References ..........................................14
13. Informative References ........................................14
SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages.
SMTP被定义为消息*传输*协议，即路由（如果需要）和传递完成（完整）消息的方法。
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].
邮件传输代理（MTA）不应更改邮件文本，除非根据[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).
然而，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 [MESSAGE-FORMAT], and later 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 more easily do the following:
将消息分离为提交和传输，使开发人员和网络管理员能够更轻松地执行以下操作：
* Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail
* 实施安全策略，防止未经授权的邮件转发或注入未经请求的批量邮件
* Implement authenticated submission, including off-site submission by authorized users such as travelers
* 实施认证提交，包括授权用户（如旅行者）的场外提交
* Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission
* 分离相关的软件代码差异，从而使每个代码库更简单，并允许不同的程序进行中继和提交
* Detect configuration problems with a site's mail clients
* 检测站点邮件客户端的配置问题
* Provide a basis for adding enhanced submission services in the future
* 为将来添加增强的提交服务提供基础
This memo describes a low-cost, deterministic means for messages to be identified as submissions, and 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 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 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 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）用于提交消息。
In examples, "C:" is used to indicate lines sent by the client, and "S:" indicates those sent by the server. Line breaks within a command example are for editorial purposes only.
在示例中，“C:”表示客户端发送的行，“S:”表示服务器发送的行。命令示例中的换行符仅用于编辑目的。
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, ESMTP], with additional restrictions or allowances as specified here.
端口587保留用于提交本文档中指定的电子邮件。在此端口上接收的消息定义为提交。使用的协议是ESMTP[SMTP-MTA，ESMTP]，此处规定了其他限制或允许。
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 configure their MSA to reject all message submissions that do not come from authorized users, with authorization based either on 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 do not allow for travelers and similar situations, and 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 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).
在消息提交会话开始之前的一段时间内（例如，20分钟），也要求进行POP[POP3]身份验证（来自相同的IP地址），但这会对客户端和服务器施加限制，这可能会造成困难。具体来说，客户端必须在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在默认情况下必须对MAIL命令发出错误响应，除非它已独立建立身份验证或授权（例如在受保护的子网内）。
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 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 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, or 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]), 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]中的“邮政局长”要求，MSA可允许在一个或多个域中对发送给“邮政局长”的邮件（或其另一种拼写形式，请参见[SMTP-MTA]）的认证程度降低，与其他地址的强制要求相比。在其他好处中，这提供了一个最后的解决方法，授权用户可以使用该地址报告问题，否则将阻止他们提交邮件。
The following table lists the current standards-track and Experimental SMTP extensions. 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 Submission Reference
---------- -------------------------- ---------- ----------------
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 Notification SHOULD [DSN]
SIZE Message size MAY [SIZE]
... 521 reply code MUST NOT [521REPLY]
CHECKPOINT Checkpoint/Restart MAY [CHECKPOINT]
BINARYMIME Binary MIME MAY [CHUNKING]
CHUNKING Chunking MAY [CHUNKING]
8BITMIME Use 8-bit data SHOULD [8BITMIME]
AUTH Authentication MUST [SMTP-AUTH]
STARTTLS Start TLS MAY [Start-TLS]
NO-SOLICITING Notification of no soliciting MAY [Msg-Track]
MTRK Message Tracking MAY [Msg-Track]
Keyword Name Submission Reference
---------- -------------------------- ---------- ----------------
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 Notification SHOULD [DSN]
SIZE Message size MAY [SIZE]
... 521 reply code MUST NOT [521REPLY]
CHECKPOINT Checkpoint/Restart MAY [CHECKPOINT]
BINARYMIME Binary MIME MAY [CHUNKING]
CHUNKING Chunking MAY [CHUNKING]
8BITMIME Use 8-bit data SHOULD [8BITMIME]
AUTH Authentication MUST [SMTP-AUTH]
STARTTLS Start TLS MAY [Start-TLS]
NO-SOLICITING Notification of no soliciting MAY [Msg-Track]
MTRK Message Tracking MAY [Msg-Track]
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 are related to a site's security policy, care should be used not to expose more detail to unauthenticated senders than is needed
应支持扩展状态代码[SMTP-Codes]，并根据[Codes-EXTENSION]使用扩展状态代码。这允许MSA将特定配置或其他问题通知客户，其详细程度超过本备忘录中列出的响应代码。由于某些拒绝与站点的安全策略有关，因此应注意不要向未经身份验证的发件人透露超出需要的更多详细信息
[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的支持。
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].
MSA转发或传递的任何邮件必须符合[SMTP-MTA]和[message-FORMAT]的要求。
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 aliases (CNAME records) for domain names, in the SMTP envelope and optionally in address fields of the header, subject to local policy.
MSA可以解析SMTP信封中的域名别名（CNAME记录），也可以解析标头地址字段中的域名别名（CNAME记录），具体取决于本地策略。
NOTE: 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.
注意：无条件解析别名可能有害。例如，如果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 which 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 left-most 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.
MSA不得以违反[SMTP-MTA]对修改本地部分的限制的方式重写前向指向（目标）地址。
Separation of submission and relay of messages allows a site to implement different policies for the two types of services, including requiring use of additional security mechanisms for one or both. It can do this in a way which 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 registration for port 587 has been updated to refer to this memo rather than RFC 2476.
587端口的注册已更新，以参考本备忘录而非RFC 2476。
Nathaniel Borenstein and Barry Leiba were instrumental in the development of this update to RFC 2476.
Nathaniel Borenstein和Barry Leiba在RFC 2476更新的开发过程中发挥了重要作用。
The original memo (RFC 2476) was developed in part based on comments and discussions which took place on and off the IETF-Submit 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.
原始备忘录（RFC 2476）部分基于IETF提交邮件列表内外的评论和讨论。感谢那些花时间审阅该文件并提出建议的人的帮助，特别是戴夫·克罗克、内德·弗里德、基思·摩尔、约翰·迈尔斯和克里斯·纽曼的帮助。
Special thanks to Harald Alvestrand, who got this effort started.
特别感谢Harald Alvestrand，他开始了这项工作。
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[ESMTP]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
[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-MTA] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP-MTA]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, January 1986.
帕特里奇，C.，“邮件路由和域系统”，STD 10，RFC 974，1986年1月。
Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
《简单邮件传输协议》，RFC 28212001年4月。
[521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995.
[521REPLY]Durand，A.和F.Dupont，“SMTP 521回复代码”，RFC 18461995年9月。
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[8BITMIME]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“8bit MIMEtransport的SMTP服务扩展”，RFC 16521994年7月。
[CHECKPOINT] Crocker, D., Freed, N., and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995.
[检查点]Crocker，D.，Freed，N.，和A.Cargille，“检查点/重启的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月。
[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 R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[信息格式]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
Resnick, P., "Internet Message Format", RFC 2822, April 2001.
Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[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月。
[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-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTP-AUTH]迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
[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月。
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
EMail: john+ietf@jck.com
EMail: john+ietf@jck.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。