Network Working Group R. Gellens
Request for Comments: 2476 QUALCOMM
Category: Standards Track J. Klensin
MCI
December 1998
Network Working Group R. Gellens
Request for Comments: 2476 QUALCOMM
Category: Standards Track J. Klensin
MCI
December 1998
Message Submission
邮件提交
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Table of Contents
目录
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Information . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions of Terms Used in this Memo . . . . . . . . . 3
2.2. Conventions Used in this Document . . . . . . . . . . . 4
3. Message Submission . . . . . . . . . . . . . . . . . . . . . 4
3.1. Submission Identification . . . . . . . . . . . . . . . 4
3.2. Message Rejection and Bouncing . . . . . . . . . . . . . 4
3.3. Authorized Submission . . . . . . . . . . . . . . . . . 5
3.4. Enhanced Status Codes . . . . . . . . . . . . . . . . . 6
4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . 6
4.1. General Submission Rejection Code . . . . . . . . . . . 6
4.2. Ensure All Domains are Fully-Qualified . . . . . . . . 6
5. Recommended Actions . . . . . . . . . . . . . . . . . . . . 7
5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . 7
5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 7
6. Optional Actions . . . . . . . . . . . . . . . . . . . . . 7
6.1. Enforce Submission Rights . . . . . . . . . . . . . . . 7
6.2. Require Authentication . . . . . . . . . . . . . . . . 8
6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . 8
6.4. Check Message Data . . . . . . . . . . . . . . . . . . 8
7. Interaction with SMTP Extensions . . . . . . . . . . . . . . 8
8. Message Modifications . . . . . . . . . . . . . . . . . . . 9
8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . 10
8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Information . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions of Terms Used in this Memo . . . . . . . . . 3
2.2. Conventions Used in this Document . . . . . . . . . . . 4
3. Message Submission . . . . . . . . . . . . . . . . . . . . . 4
3.1. Submission Identification . . . . . . . . . . . . . . . 4
3.2. Message Rejection and Bouncing . . . . . . . . . . . . . 4
3.3. Authorized Submission . . . . . . . . . . . . . . . . . 5
3.4. Enhanced Status Codes . . . . . . . . . . . . . . . . . 6
4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . 6
4.1. General Submission Rejection Code . . . . . . . . . . . 6
4.2. Ensure All Domains are Fully-Qualified . . . . . . . . 6
5. Recommended Actions . . . . . . . . . . . . . . . . . . . . 7
5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . 7
5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 7
6. Optional Actions . . . . . . . . . . . . . . . . . . . . . 7
6.1. Enforce Submission Rights . . . . . . . . . . . . . . . 7
6.2. Require Authentication . . . . . . . . . . . . . . . . 8
6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . 8
6.4. Check Message Data . . . . . . . . . . . . . . . . . . 8
7. Interaction with SMTP Extensions . . . . . . . . . . . . . . 8
8. Message Modifications . . . . . . . . . . . . . . . . . . . 9
8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . 10
8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10
8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . 10
8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . 10
8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . 10
8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . 10
8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
13. Full Copyright Statement . . . . . . . . . . . . . . . . . 15
8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . 10
8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . 10
8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . 10
8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . 10
8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
13. Full Copyright Statement . . . . . . . . . . . . . . . . . 15
SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages. 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].
SMTP被定义为消息*传输*协议，即路由（如果需要）和传递完成（完整）消息的方法。邮件传输代理（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 which accepts message submissions from MUAs is termed a Message Submission Agent (MSA).
然而，SMTP现在也被广泛用作消息*提交*协议，即消息用户代理（MUA）将新消息引入MTA路由网络的一种手段。从MUAs接收消息提交的过程称为消息提交代理（MSA）。
Messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in some aspect or other. Unfinished messages 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 (for example, 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. 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:
将消息分为提交和传输，使开发人员和网络管理员能够更轻松地：
* 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.
此备忘录描述了一种低成本、确定性的方法，用于将消息标识为提交，并指定提交服务器将采取的操作。
Public comments should be sent to the IETF Submit mailing list, <ietf-submit@imc.org>. To subscribe, send a message containing SUBSCRIBE to <ietf-submit-request@imc.org>. Private comments may be sent to the authors.
公众意见应发送至IETF提交邮件列表，<IETF-submit@imc.org>. 若要订阅，请发送包含订阅<ietf submit的消息-request@imc.org>. 私人评论可以发送给作者。
Fully-Qualified
完全合格
Containing or consisting of a domain which can be globally resolved using the global Domain Name Service; that is, not a local alias or partial specification.
包含或由可使用全局域名服务全局解析的域组成；也就是说，不是本地别名或部分规范。
Message Submission Agent (MSA)
邮件提交代理（MSA）
A process which conforms to this specification, which 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.
一个符合此规范的进程，它充当提交服务器以接受来自MUA的消息，并传递消息或充当SMTP客户端以将消息中继到MTA。
Message Transfer Agent (MTA)
邮件传输代理（MTA）
A process which conforms to [SMTP-MTA], which 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]的进程，它充当SMTP服务器以接受来自MSA或其他MTA的邮件，并传递邮件或充当SMTP客户端以将邮件中继到其他MTA。
Message User Agent (MUA)
消息用户代理（MUA）
A process which acts (usually on behalf of a user) to compose and submit new messages, and process delivered messages. In the split-MUA model, POP or IMAP is used to access delivered messages.
（通常代表用户）撰写和提交新消息以及处理已传递消息的过程。在拆分MUA模型中，POP或IMAP用于访问传递的消息。
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 as specified here.
端口587保留用于提交本文档中指定的电子邮件。在此端口上接收的消息定义为提交。所使用的协议是ESMTP[SMTP-MTA，ESMTP]，此处规定了附加限制。
While 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 MTA to reject all RCPT TOs for messages that do not reference local users, and configure their MSA to reject all message submissions that do not come from authorized users, based on IP address, or authenticated identity.
例如，某些站点可能会将其MTA配置为拒绝所有未引用本地用户的邮件的RCPT to，并将其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 FROM command.
如果MSA无法根据有效的邮件来源、有效的源IP地址或身份验证确定提交用户的返回路径，则MSA应立即拒绝该消息。通过向MAIL FROM命令返回550代码，可以立即拒绝消息。
Note that a null return path, that is, MAIL FROM:<>, is permitted and MUST be accepted. (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 which 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 must maintain a queue of messages it has submitted, and match bounces to them.
注意：在消息提交的正常情况下，最好立即拒绝消息，因为它会给用户和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 prior POP authentication.
已经使用了许多方法来确保只有经过授权的用户才能提交消息。这些方法包括经过身份验证的SMTP、IP地址限制、安全IP和先前的POP身份验证。
Authenticated SMTP [SMTP-AUTH] has been proposed. It allows the MSA to determine an authorization identity for the message submission, which is not tied to other protocols.
已建议使用经过身份验证的SMTP[SMTP-AUTH]。它允许MSA确定消息提交的授权标识，这与其他协议无关。
IP address restrictions are very widely implemented, but do not allow for travellers and similar situations, and can be spoofed.
IP地址限制被广泛实施，但不允许旅行者和类似情况，并且可能被欺骗。
Secure IP [IPSEC] can also be used, and provides 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 (for example, 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 prior authorized user.
在消息提交会话开始之前的一段时间（例如，20分钟）内要求POP[POP3]身份验证（来自相同的IP地址），这也被使用，但这确实会对客户端和服务器施加限制，这可能会造成困难。具体来说，客户端必须在SMTP提交会话之前执行POP身份验证，并且并非所有客户端都能够并配置此功能。此外，MSA必须与POP服务器协调，这可能很困难。还有一个窗口，在此窗口中，未经授权的用户可以提交消息，并显示为先前的授权用户。
This memo suggests several enhanced status codes [SMTP-CODES] for submission-specific rejections. The specific codes used are:
此备忘录建议提交特定拒绝的几个增强状态代码[SMTP-CODE]。使用的具体代码为：
5.6.0 Bad content. The content of the header or text is improper.
5.6.0 内容不好。标题或文本的内容不正确。
5.6.2 Bad domain or address. Invalid or improper domain or address in MAIL FROM, RCPT TO, or DATA.
5.6.2 错误的域或地址。邮件发件人、RCPT收件人或数据中的域或地址无效或不正确。
5.7.1 Not allowed. The address in MAIL FROM appears to have insufficient submission rights, or is invalid, or is not authorized with the authentication used; the address in a RCPT TO command is inconsistent with the permissions given to the user; the message data is rejected based on the submitting user.
5.7.1 不允许。来自的邮件中的地址似乎没有足够的提交权限，或者无效，或者未经使用的身份验证授权；RCPT TO命令中的地址与授予用户的权限不一致；根据提交用户拒绝消息数据。
5.7.0 Site policy. The message appears to violate site policy in some way.
5.7.0 网站政策。该消息似乎在某种程度上违反了站点策略。
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 FROM, RCPT TO, or DATA command that contains something improper. Enhanced status code 5.6.0 is to be used if no other code is more specific.
除非包含更精确的响应代码，否则响应代码554将用于拒绝包含不正确内容的邮件发件人、RCPT收件人或数据命令。如果没有其他代码更具体，则使用增强状态代码5.6.0。
The MSA MUST ensure that all domains in the envelope are fully-qualified.
MSA必须确保信封中的所有域都是完全合格的。
If the MSA examines or alters the message text in 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 FROM, RCPT TO, or DATA command which contains improper domain references.
回复代码554用于拒绝包含不正确域引用的邮件发件人、RCPT收件人或数据命令。
NOTE: A frequent local convention is to accept single-level domains (for example, 'sales') and then to expand the reference by adding the remaining portion of the domain name (for example, to
注意：一个常见的本地约定是接受单级域（例如，“sales”），然后通过添加域名的剩余部分（例如，添加到
'sales.example.net'). Local conventions that permit single-level domains SHOULD reject, rather than expand, incomplete multi-level domains, since such expansion is particularly risky.
“sales.example.net”）。允许单级域的本地约定应该拒绝而不是扩展不完整的多级域，因为这种扩展尤其危险。
The MSA SHOULD do all of the following:
MSA应执行以下所有操作：
An MSA SHOULD reject messages with illegal syntax in a sender or recipient envelope address.
MSA应拒绝发件人或收件人信封地址中语法非法的邮件。
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 FROM or RCPT TO command that contains a detectably improper address.
回复代码501用于拒绝包含可检测到的不正确地址的来自或RCPT to命令的邮件。
When addresses are resolved after submission of the message body, reply code 554 with enhanced status code 5.6.2 is to be used after end-of-data, if the message contains invalid addresses in the header.
当在提交邮件正文后解析地址时，如果邮件标题中包含无效地址，则在数据结束后将使用带有增强状态代码5.6.2的回复代码554。
The MSA SHOULD log message errors, especially apparent misconfigurations of client software.
MSA应记录消息错误，尤其是客户端软件的明显错误配置。
Note: 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.
注意：当检测到本地邮件客户端出现问题时，通知管理员会非常有帮助。这是区别提交和中继的另一个优点：系统管理员可能对本地配置问题感兴趣，但对其他站点的客户端问题不感兴趣。
The MSA MAY do any of the following:
MSA可以执行以下任一操作：
The MSA MAY issue an error response to the MAIL FROM 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).
如果MAIL FROM中的地址似乎没有足够的提交权限，或者未使用所使用的身份验证进行授权（如果会话已通过身份验证），MSA可能会对MAIL FROM命令发出错误响应。
Reply code 550 with enhanced status code 5.7.1 is used for this purpose.
带有增强状态代码5.7.1的回复代码550用于此目的。
The MSA MAY issue an error response to the MAIL FROM command if the session has not been authenticated.
如果会话尚未通过身份验证，MSA可能会对MAIL FROM命令发出错误响应。
Section 3.3 discusses authentication mechanisms.
第3.3节讨论了身份验证机制。
Reply code 530 [SMTP-AUTH] is used for this purpose.
回复代码530[SMTP-AUTH]用于此目的。
The MSA MAY issue an error response to the RCPT TO command if inconsistent with the permissions given to the user (if the session has been authenticated).
如果与授予用户的权限不一致（如果会话已通过身份验证），MSA可能会向RCPT to命令发出错误响应。
Reply code 550 with enhanced status code 5.7.1 is used for this purpose.
带有增强状态代码5.7.1的回复代码550用于此目的。
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 enhanced status code 5.7.1 is used to reject based on the submitting user. Reply code 550 with enhanced status code 5.7.0 is used if the message violates site policy.
回复代码554用于解决数据中的语法问题。如果命令本身在语法上无效，则使用回复代码501。带有增强状态代码5.7.1的回复代码550用于根据提交用户拒绝。如果邮件违反站点策略，则使用带有增强状态代码5.7.0的回复代码550。
The following table lists the current standards-track and Experimental SMTP extensions. Listed are the RFC, name, an indication as to the use of the extension on the submit port, and a reference:
下表列出了当前的标准跟踪和实验SMTP扩展。列出了RFC、名称、关于在提交端口上使用扩展的指示以及参考：
RFC Name Submission Reference
---- --------------- ---------- ------------------
2197 Pipelining SHOULD [PIPELINING]
2034 Error Codes SHOULD [CODES-EXTENSION]
1985 ETRN MUST NOT [ETRN]
1893 Extended Codes SHOULD [SMTP-CODES]
1891 DSN SHOULD [DSN]
1870 Size MAY [SIZE]
1846 521 MUST NOT [521REPLY]
1845 Checkpoint MAY [Checkpoint]
RFC Name Submission Reference
---- --------------- ---------- ------------------
2197 Pipelining SHOULD [PIPELINING]
2034 Error Codes SHOULD [CODES-EXTENSION]
1985 ETRN MUST NOT [ETRN]
1893 Extended Codes SHOULD [SMTP-CODES]
1891 DSN SHOULD [DSN]
1870 Size MAY [SIZE]
1846 521 MUST NOT [521REPLY]
1845 Checkpoint MAY [Checkpoint]
1830 Binary MAY [CHUNKING]
1652 8-bit MIME SHOULD [8BITMIME]
---- Authentication ------ [SMTP-AUTH]
1830 Binary MAY [CHUNKING]
1652 8-bit MIME SHOULD [8BITMIME]
---- Authentication ------ [SMTP-AUTH]
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 than is needed to correct the problem.
扩展状态代码[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.
[SMTP-AUTH]允许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 which 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.
注意：作为本地决定实施消息修改的指导，最重要的规则是将此类操作限制为针对具有明确解决方案的特定问题的补救措施。地址元素尤其如此。例如，不加区分地将域附加到缺少域的地址或元素通常会导致更多断开的地址。必须验证非限定地址是否为域中的有效本地部分，然后才能安全添加域。
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 MAY add or replace the 'Message-ID' field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]).
如果MSA缺少“消息ID”字段，或者该字段的语法无效（如[Message-FORMAT]所定义），则MSA可以添加或替换该字段。
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, e.g., 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 envelope and optionally in address fields of the header, subject to local policy.
MSA可根据本地政策解析域名的别名（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 envelope and optionally in address fields of the header, according to local policy. For example, a site may prefer to rewrite 'JRU' as '
MSA可以根据本地策略在信封中和可选地在报头的地址字段中重写本地部分和/或域。例如，站点可能更喜欢将“JRU”重写为“JRU”
J.Random.User' in order to hide logon names, and/or to rewrite ' squeeky.sales.example.net' as 'zyx.example.net' to hide machine names and make it easier to move users.
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 which strips the left-most element of the domain if the complete domain matches '*.foo.example.net' would be acceptable.
但是，仅应更改与特定本地MSA配置设置匹配的地址、本地部分或域。MSA应用独立于数据的重写规则是非常危险的，例如总是删除域名的第一个元素。因此，例如，如果完整的域与“*.foo.example.net”匹配，则可以接受一条规则，该规则将剥离域中最左边的元素。
Separation of submission and relay of messages can allow 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 MSA to require authentication before accepting a message, and could configure its MTA to reject all RCPT TOs for non-local users. This can be an important element in a site's total email security policy.
例如，站点可以将其MSA配置为在接受邮件之前需要身份验证，并可以将其MTA配置为拒绝非本地用户的所有RCPT to。这可能是网站总体电子邮件安全策略中的一个重要元素。
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节），则允许公开使用其资源和名称；未经请求的批量电子邮件可以使用其设施注入。
This updated memo has been revised 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 the draft and make suggestions is appreciated, especially that of Dave Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman.
本更新备忘录已根据IETF提交邮件列表内外的评论和讨论进行了部分修订。感谢那些花时间审查草案并提出建议的人的帮助，特别是戴夫·克罗克、内德·弗里德、基思·摩尔、约翰·迈尔斯和克里斯·纽曼。
Special thanks to Harald Alvestrand, who got this effort started.
特别感谢Harald Alvestrand，他开始了这项工作。
[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月。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[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 1830, August 1995.
[CHUNKING]Vaudreuil，G.“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 1830，1995年8月。
[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., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[DSN]Moore，K.，“传递状态通知的SMTP服务扩展”，RFC 18911996年1月。
[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月。
[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月。
[HEADERS] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[HEADERS]Palme，J.，“通用互联网消息头”，RFC 2076，1997年2月。
[IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[IPSEC]Atkinson，R.，“互联网协议的安全架构”，RFC 18251995年8月。
[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月。
[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., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
Braden，R.，编辑，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
[PIPELINING]Freed，N.，“用于命令管道的SMTP服务扩展”，RFC 21971997年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", Work in Progress.
[SMTP-AUTH]迈尔斯，J.，“用于身份验证的SMTP服务扩展”，正在进行中。
[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[SMTP-CODES]Vaudreuil，G.“增强邮件系统状态代码”，RFC 1893，1996年1月。
[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 14, RFC 974, January 1986.
帕特里奇，C.，“邮件路由和域系统”，STD 14，RFC 974，1986年1月。
Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
Braden，R.，编辑，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
Randall Gellens QUALCOMM Incorporated 6455 Lusk Blvd. San Diego, CA 92121-2779 U.S.A.
Randall Gellens高通公司卢斯克大道6455号。美国加利福尼亚州圣地亚哥92121-2779。
Phone: +1 619 651 5115
Fax: +1 619 651 5334
EMail: Randy@Qualcomm.Com
Phone: +1 619 651 5115
Fax: +1 619 651 5334
EMail: Randy@Qualcomm.Com
John C. Klensin MCI Telecommunications 800 Boylston St, 7th floor Boston, MA 02199 USA
美国马萨诸塞州波士顿Boylston街7楼John C.Klensin MCI Telecommunications 800号
Phone: +1 617 960 1011
EMail: klensin@mci.net
Phone: +1 617 960 1011
EMail: klensin@mci.net
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。