Network Working Group E. Allman
Request for Comments: 4405 Sendmail, Inc.
Category: Experimental H. Katz
Microsoft Corp.
April 2006
Network Working Group E. Allman
Request for Comments: 4405 Sendmail, Inc.
Category: Experimental H. Katz
Microsoft Corp.
April 2006
SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message
SMTP服务扩展，用于指示电子邮件的负责提交者
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
IESG Note
IESG注释
The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such, these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group.
以下文件（RFC 4405、RFC 4406、RFC 4407和RFC 4408）作为实验性RFC同时发布，尽管没有普遍的技术共识，协调这两种方法的努力也失败了。因此，这些文件没有得到IETF的全面审查，而是按“原样”发布，以记录MARID工作组中考虑的不同方法。
The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them.
IESG对首选哪种方法不持任何立场，并提醒读者，每种方法都存在严重的开放性问题，并关注如何同时使用它们。IESG认为，记录不同的方法比不记录它们危害更小。
Note that the Sender ID experiment may use DNS records that may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt.
请注意，发送方ID实验可能使用为当前SPF实验或这组实验中的早期版本创建的DNS记录。根据记录的内容，这可能意味着发件人ID试探法将错误地应用于消息。根据接收者与这些试探法相关联的操作，消息可能不会被传递，也可能在接收时被丢弃。
Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. Participants publishing SPF experiment DNS records should consider
依赖发送方ID实验DNS记录的参与者将收到警告，在这种情况下，他们可能会丢失有效消息。参与者发布SPF实验DNS记录应考虑
the advice given in section 3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict.
RFC 4406第3.4节中给出的建议，可能希望发布v=spf1和spf2.0记录以避免冲突。
Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem.
发送者ID实验的参与者需要意识到，当与符合标准的系统交互时，使用Resent-*头字段的方式将导致无法接收合法电子邮件（特别是通过不添加RENT-*头来符合标准的自动转发器，以及符合RFC 822但尚未实现RFC 2822 RENT-*语义的系统）。在不解决此互操作性问题的情况下，在标准轨道上提前发送ID是不合适的。
The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future.
请社区在出版后的两年内观察这两种方法的成功或失败，以便将来能够达成社区共识。
Abstract
摘要
This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain.
此备忘录定义了简单邮件传输协议（SMTP）服务的扩展，该服务允许SMTP客户端指定电子邮件的负责提交者。负责提交者是最近负责将消息引入传输流的实体的电子邮件地址。此扩展有助于接收电子邮件服务器有效地确定SMTP客户端是否有权代表负责提交者的域传输邮件。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. The SUBMITTER Service Extension .................................4
3. The SUBMITTER Keyword of the EHLO Command .......................5
4. The SUBMITTER Parameter of the MAIL Command .....................5
4.1. Setting the SUBMITTER Parameter Value ......................5
4.2. Processing the SUBMITTER Parameter .........................5
4.3. Transmitting to a Non-SUBMITTER-Aware SMTP Server ..........6
5. Examples ........................................................6
5.1. Mail Submission ............................................7
5.2. Mail Forwarding ............................................7
5.3. Mobile User ................................................8
5.4. Guest E-Mail Service .......................................9
5.5. SUBMITTER Used on a Non-Delivery Report ...................11
6. Security Considerations ........................................11
7. Acknowledgements ...............................................12
8. IANA Considerations ............................................12
9. References .....................................................12
9.1. Normative References ......................................12
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. The SUBMITTER Service Extension .................................4
3. The SUBMITTER Keyword of the EHLO Command .......................5
4. The SUBMITTER Parameter of the MAIL Command .....................5
4.1. Setting the SUBMITTER Parameter Value ......................5
4.2. Processing the SUBMITTER Parameter .........................5
4.3. Transmitting to a Non-SUBMITTER-Aware SMTP Server ..........6
5. Examples ........................................................6
5.1. Mail Submission ............................................7
5.2. Mail Forwarding ............................................7
5.3. Mobile User ................................................8
5.4. Guest E-Mail Service .......................................9
5.5. SUBMITTER Used on a Non-Delivery Report ...................11
6. Security Considerations ........................................11
7. Acknowledgements ...............................................12
8. IANA Considerations ............................................12
9. References .....................................................12
9.1. Normative References ......................................12
The practice of falsifying the identity of the sender of an e-mail message, commonly called "spoofing", is a prevalent tactic used by senders of unsolicited commercial e-mail, or "spam". This form of abuse has highlighted the need to improve identification of the "responsible submitter" of an e-mail message.
伪造电子邮件发送者身份的做法，通常称为“欺骗”，是未经请求的商业电子邮件或“垃圾邮件”发送者普遍使用的策略。这种形式的滥用突出了改进电子邮件“负责提交人”身份识别的必要性。
In this specification, the responsible submitter is the entity most recently responsible for injecting a message into the e-mail transport stream. The e-mail address of the responsible submitter will be referred to as the Purported Responsible Address (PRA) of the message. The Purported Responsible Domain (PRD) is the domain portion of that address.
在本规范中，负责提交者是最近负责将消息注入电子邮件传输流的实体。负责提交人的电子邮件地址将被称为消息的声称负责地址（PRA）。声称的责任域（PRD）是该地址的域部分。
This specification codifies rules for encoding the purported responsible address into the SMTP transport protocol. This will permit receiving SMTP servers to efficiently validate whether or not the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain.
本规范编纂了将声称的责任地址编码到SMTP传输协议中的规则。这将允许接收SMTP服务器有效地验证SMTP客户端是否有权代表负责提交者的域传输邮件。
Broadly speaking, there are two possible approaches for determining the purported responsible address: either from RFC 2821 [SMTP] protocol data or from RFC 2822 [MSG-FORMAT] message headers. Each approach has certain advantages and disadvantages.
广义地说，有两种可能的方法来确定声称的责任地址：从RFC 2821[SMTP]协议数据或从RFC 2822[MSG-FORMAT]消息头。每种方法都有一定的优缺点。
Deriving the purported responsible domain from RFC 2821 data has the advantage that validation can be performed before the SMTP client has transmitted the message body. If spoofing is detected, then the SMTP server has the opportunity, depending upon local policy, to reject the message before it is ever transmitted. The disadvantage of this approach is the risk of false positives, that is, incorrectly concluding that the sender's e-mail address has been spoofed. There are today legitimate reasons why the Internet domain names used in RFC 2821 commands may be different from those of the sender of an e-mail message.
从RFC 2821数据派生所谓的责任域的优点是，可以在SMTP客户端传输消息正文之前执行验证。如果检测到欺骗，则SMTP服务器有机会根据本地策略在邮件传输之前拒绝该邮件。这种方法的缺点是存在误报的风险，即错误地认为发件人的电子邮件地址被欺骗。今天，RFC 2821命令中使用的Internet域名可能与电子邮件发件人的域名不同，这是有正当理由的。
Deriving the purported responsible domain from RFC 2822 headers has the advantage that validation can usually be based on an identity that is displayed to recipients by existing Mail User Agents (MUAs) as the sender's identity. This aids in detection of a particularly noxious form of spoofing known as "phishing" in which a malicious sender attempts to fool a recipient into believing that a message originates from an entity well known to the recipient. This approach carries a lower risk of false positives since there are fewer legitimate reasons for RFC 2822 headers to differ from the true sender of the message. The disadvantage of this approach is that it does require parsing and analysis of message headers. In practice,
从RFC 2822头导出声称的责任域的优点是，验证通常可以基于现有邮件用户代理（MUA）向收件人显示的身份作为发件人的身份。这有助于检测一种称为“网络钓鱼”的特别有害的欺骗形式，其中恶意发件人试图欺骗收件人，使其相信邮件来自收件人熟知的实体。这种方法具有较低的误报风险，因为RFC 2822头与消息的真正发送者不同的合法原因较少。这种方法的缺点是它确实需要解析和分析消息头。实际上,，
much if not all the message body is also transmitted since the SMTP protocol described in RFC 2821 provides no mechanism to interrupt message transmission after the DATA command has been issued.
由于RFC 2821中描述的SMTP协议不提供在发出数据命令后中断消息传输的机制，因此即使不是全部，也会传输大部分消息正文。
It is desirable to unify these two approaches in a way that combines the benefits of both while minimizing their respective disadvantages.
希望以一种既能综合两者优点又能最小化其各自缺点的方式统一这两种方法。
This specification describes just such a unified approach. It uses the mechanism described in [SMTP] to describe an extension to the SMTP protocol. Using this extension, an SMTP client can specify the e-mail address of the entity most recently responsible for submitting the message to the SMTP client in a new SUBMITTER parameter of the SMTP MAIL command. SMTP servers can use this information to validate that the SMTP client is authorized to transmit e-mail on behalf of the Internet domain contained in the SUBMITTER parameter.
本规范描述的就是这样一种统一的方法。它使用[SMTP]中描述的机制来描述SMTP协议的扩展。如果使用此SMTP客户端的SMTP扩展名，则可以使用“最近提交邮件到”命令中的“最新负责邮件的SMTP客户端”参数指定该SMTP客户端的SMTP扩展名。SMTP服务器可以使用此信息验证SMTP客户端是否有权代表SUBMITTER参数中包含的Internet域传输电子邮件。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
The following SMTP service extension is hereby defined:
特此定义以下SMTP服务扩展：
(1) The name of this SMTP service extension is "Responsible Submitter";
(1) 此SMTP服务扩展名为“负责提交者”；
(2) The EHLO keyword value associated with this extension is "SUBMITTER";
(2) 与此扩展关联的EHLO关键字值为“SUBMITTER”；
(3) The SUBMITTER keyword has no parameters;
(3) 提交者关键字没有参数；
(4) No additional SMTP verbs are defined by this extension;
(4) 此扩展未定义其他SMTP谓词；
(5) An optional parameter is added to the MAIL command using the esmtp-keyword "SUBMITTER", and is used to specify the e-mail address of the entity responsible for submitting the message for delivery;
(5) 使用esmtp关键字“SUBMITTER”将可选参数添加到MAIL命令中，用于指定负责提交邮件以进行传递的实体的电子邮件地址；
(6) This extension is appropriate for the submission protocol [SUBMIT].
(6) 此扩展适用于提交协议[SUBMIT]。
An SMTP server includes the SUBMITTER keyword in its EHLO response to tell the SMTP client that the SUBMITTER service extension is supported.
SMTP服务器在其EHLO响应中包含SUBMITTER关键字，以告知SMTP客户端支持SUBMITTER服务扩展。
The SUBMITTER keyword has no parameters.
SUBMITTER关键字没有参数。
The syntax of the SUBMITTER parameter is
SUBMITTER参数的语法为
"SUBMITTER=" Mailbox
“SUBMITTER=”邮箱
where Mailbox is the Augmented Backus-Naur Form (ABNF) [ABNF] production defined in Section 4.1.2 of [SMTP]. Characters such as SP, "+", and "=" that may occur in Mailbox but are not permitted in ESMTP parameter values MUST be encoded as "xtext" as described in Section 4 of [DSN].
其中，邮箱是[SMTP]第4.1.2节中定义的扩充巴科斯诺尔表格（ABNF）[ABNF]产品。如[DSN]第4节所述，邮箱中可能出现但ESMTP参数值中不允许使用的SP、“+”和“=”等字符必须编码为“xtext”。
The purpose of the SUBMITTER parameter is to allow the SMTP client to indicate to the server the purported responsible address of the message directly in the RFC 2821 protocol.
SUBMITTER参数的用途是允许SMTP客户端直接在RFC 2821协议中向服务器指示消息的声称负责地址。
Therefore, SMTP clients that support the Responsible Submitter extension MUST include the SUBMITTER parameter on all messages. This includes messages containing a null reverse-path in the MAIL command.
因此，支持负责提交者扩展的SMTP客户端必须在所有邮件上包含提交者参数。这包括邮件命令中包含空反向路径的邮件。
SMTP clients MUST set the SUBMITTER parameter value to the purported responsible address of the message as defined in [PRA]. This also applies to messages containing a null reverse-path.
SMTP客户端必须将提交者参数值设置为[PRA]中定义的邮件的声称负责地址。这也适用于包含空反向路径的消息。
In some circumstances, described in Section 7 of [SENDER-ID], SMTP clients may need to add RFC 2822 headers to the message in order to ensure that the correct SUBMITTER parameter value can be set.
在某些情况下，如[SENDER-ID]第7节所述，SMTP客户端可能需要向邮件添加RFC 2822头，以确保可以设置正确的提交者参数值。
Receivers of e-mail messages sent with the SUBMITTER parameter SHOULD select the domain part of the SUBMITTER address value as the purported responsible domain of the message, and SHOULD perform such tests, including those defined in [SENDER-ID], as are deemed necessary to determine whether the connecting SMTP client is authorized to transmit e-mail messages on behalf of that domain.
使用SUBMITTER参数发送的电子邮件的接收者应选择SUBMITTER address值的域部分作为消息的声称责任域，并应执行此类测试，包括[SENDER-ID]中定义的测试，确定连接的SMTP客户端是否被授权代表该域传输电子邮件消息所必需的。
If these tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter not allowed."
如果这些测试表明连接的SMTP客户端未被授权代表提交者域发送电子邮件，则接收SMTP服务器应拒绝该邮件，并且在拒绝时必须使用“550 5.7.1不允许提交者”
If the receiving SMTP server allows the connecting SMTP client to transmit message data, then the server SHOULD determine the purported responsible address of the message by examining the RFC 2822 message headers as described in [PRA]. If this purported responsible address does not match the address appearing in the SUBMITTER parameter, the receiving SMTP server MUST reject the message and when rejecting MUST use "550 5.7.1 Submitter does not match header."
如果接收SMTP服务器允许连接SMTP客户端传输消息数据，则服务器应通过检查[PRA]中所述的RFC 2822消息头来确定消息的声称负责地址。如果该声称负责的地址与SUBMITTER参数中显示的地址不匹配，则接收SMTP服务器必须拒绝该邮件，并且在拒绝时必须使用“550 5.7.1 SUBMITTER not match header”
If no purported responsible address is found according to the procedure defined in [PRA], the SMTP server SHOULD reject the message and when rejecting MUST use "554 5.7.7 Cannot verify submitter address."
如果根据[PRA]中定义的程序未找到声称的责任地址，SMTP服务器应拒绝该邮件，拒绝时必须使用“554 5.7.7无法验证提交者地址”
Verifying Mail Transfer Agents (MTAs) are strongly urged to validate the SUBMITTER parameter against the RFC 2822 headers; otherwise, an attacker can trivially defeat the algorithm.
强烈建议验证邮件传输代理（MTA）根据RFC 2822头验证提交者参数；否则，攻击者可以轻易地击败该算法。
Note that the presence of the SUBMITTER parameter on the MAIL command MUST NOT change the effective reverse-path of a message. Any delivery status notifications must be sent to the reverse-path, if one exists, as per Section 3.7 of [SMTP] regardless of the presence of a SUBMITTER parameter. If the reverse-path is null, delivery status notifications MUST NOT be sent to the SUBMITTER address.
请注意，MAIL命令中存在SUBMITTER参数不得更改消息的有效反向路径。根据[SMTP]第3.7节，无论是否存在提交者参数，必须将任何传递状态通知发送到反向路径（如果存在）。如果反向路径为空，则传递状态通知不得发送到提交者地址。
Likewise, the SUBMITTER parameter MUST NOT change the effective reply address of a message. Replies MUST be sent to the From address or the Reply-To address, if present, as described in Section 3.6.2 of [MSG-FORMAT] regardless of the presence of a SUBMITTER parameter.
同样，SUBMITTER参数不得更改消息的有效回复地址。回复必须发送至发件人地址或回复地址（如有），如[MSG-FORMAT]第3.6.2节所述，无论是否存在提交人参数。
Notwithstanding the provisions of Section 4.1 above, when an MTA transmits a message to another MTA that does not support the SUBMITTER extension, the forwarding MTA MUST transmit the message without the SUBMITTER parameter. This should involve no information loss, since the SUBMITTER parameter is required to contain information derived from the message headers.
尽管有上述第4.1节的规定，当MTA向不支持提交者扩展名的另一MTA传输邮件时，转发MTA必须在不使用提交者参数的情况下传输邮件。这应该不涉及信息丢失，因为SUBMITTER参数需要包含从消息头派生的信息。
This section provides examples of how the SUBMITTER parameter would be used. The following dramatis personae appear in the examples:
本节提供了如何使用SUBMITTER参数的示例。以下人物角色出现在示例中：
alice@example.com: the original sender of each e-mail message.
alice@example.com：每封电子邮件的原始发件人。
bob@company.com.example: the final recipient of each e-mail.
bob@company.com.example：每封电子邮件的最终收件人。
bob@almamater.edu.example: an e-mail address used by Bob that he has configured to forward mail to his office account at bob@company.com.example.
bob@almamater.edu.example：Bob使用的电子邮件地址，已配置为将邮件转发到其位于的办公室帐户bob@company.com.example.
alice@mobile.net.example: an e-mail account provided to Alice by her mobile e-mail network carrier.
alice@mobile.net.example：由Alice的移动电子邮件网络运营商提供给她的电子邮件帐户。
Under normal circumstances, Alice would configure her MUA to submit her message to the mail system using the SUBMIT protocol [SUBMIT]. The MUA would transmit the message without the SUBMITTER parameter. The SUBMIT server would validate that the MUA is allowed to submit a message through some external scheme, perhaps SMTP Authentication [SMTPAUTH]. Under most circumstances, this would look like a normal, authenticated SMTP transaction. The SUBMIT server would extract her name from the RFC 2822 headers for use in the SUBMITTER parameters of subsequent transmissions of the message.
在正常情况下，Alice会将她的MUA配置为使用提交协议[submit]向邮件系统提交邮件。MUA将在没有提交者参数的情况下传输消息。提交服务器将验证是否允许MUA通过某种外部方案（可能是SMTP身份验证[SMTPAUTH]）提交消息。在大多数情况下，这看起来像一个正常的、经过身份验证的SMTP事务。提交服务器将从RFC 2822头中提取她的名字，用于后续消息传输的提交者参数。
When Alice sends a message to Bob at his almamater.edu.example account, the SMTP session from her SUBMIT server might look something like this:
当Alice通过Bob的almamater.edu.example帐户向Bob发送消息时，来自其提交服务器的SMTP会话可能如下所示：
S: 220 almamater.edu.example ESMTP server ready
C: EHLO example.com
S: 250-almamater.edu.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com> SUBMITTER=alice@example.com
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@almamater.edu.example>
S: 250 <bob@almamater.edu.example> recipient ok
C: DATA
S: 354 okay, send message
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
S: 220 almamater.edu.example ESMTP server ready
C: EHLO example.com
S: 250-almamater.edu.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com> SUBMITTER=alice@example.com
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@almamater.edu.example>
S: 250 <bob@almamater.edu.example> recipient ok
C: DATA
S: 354 okay, send message
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
The almamater.edu.example MTA must now forward this message to bob@company.com.example. Although the original sender of the message is alice@example.com, Alice is not responsible for this most recent retransmission of the message. That role is filled by bob@almamater.edu.example, who established the forwarding of mail to bob@company.com.example. Therefore, the almamater.edu.example MTA determines a new purported responsible address for the message, namely, bob@almamater.edu.example, and sets the SUBMITTER parameter accordingly. The forwarding MTA also inserts a Resent-From header in the message body to ensure the purported responsible address derived from the RFC 2822 headers matches the SUBMITTER address.
almamater.edu.example MTA现在必须将此消息转发给bob@company.com.example. 虽然邮件的原始发件人是alice@example.com，Alice不对最近的消息重传负责。这个角色由bob@almamater.edu.example，谁将邮件转发给bob@company.com.example. 因此，almamater.edu.example MTA将为邮件确定一个新的据称负责的地址，即，bob@almamater.edu.example，并相应地设置提交者参数。转发MTA还在邮件正文中插入“重新发送自”标头，以确保从RFC 2822标头派生的声称负责的地址与提交者地址匹配。
S: 220 company.com.example ESMTP server ready
C: EHLO almamater.edu.example
S: 250-company.com.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com>
SUBMITTER=bob@almamater.edu.example
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@company.com.example>
S: 250 <bob@company.com.example> recipient ok
C: DATA
S: 354 okay, send message
C: Resent-From: bob@almamater.edu.example
C: Received By: ...
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
S: 220 company.com.example ESMTP server ready
C: EHLO almamater.edu.example
S: 250-company.com.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com>
SUBMITTER=bob@almamater.edu.example
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@company.com.example>
S: 250 <bob@company.com.example> recipient ok
C: DATA
S: 354 okay, send message
C: Resent-From: bob@almamater.edu.example
C: Received By: ...
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
Alice is at the airport and uses her mobile e-mail device to send a message to Bob. The message travels through the carrier network provided by mobile.net.example, but Alice uses her example.com address on the From line of all her messages so that replies go to her office mailbox.
艾丽丝在机场，用她的移动电子邮件设备向鲍勃发送信息。邮件通过mobile.net.example提供的运营商网络传输，但Alice在所有邮件的发件人行中使用她的example.com地址，以便将回复发送到她的办公室邮箱。
Here is an example of the SMTP session between the MTAs at mobile.net.example and almamater.edu.example.
下面是mobile.net.example和almamater.edu.example上MTA之间SMTP会话的示例。
S: 220 almamater.edu.example ESMTP server ready
C: EHLO mobile.net.example
S: 250-almamater.edu.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com>
SUBMITTER=alice@mobile.net.example
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@almamater.edu.example>
S: 250 <bob@almamater.edu.example> recipient ok
C: DATA
S: 354 okay, send message
C: Sender: alice@mobile.net.example
C: Received By: ...
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
S: 220 almamater.edu.example ESMTP server ready
C: EHLO mobile.net.example
S: 250-almamater.edu.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com>
SUBMITTER=alice@mobile.net.example
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@almamater.edu.example>
S: 250 <bob@almamater.edu.example> recipient ok
C: DATA
S: 354 okay, send message
C: Sender: alice@mobile.net.example
C: Received By: ...
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
Note that mobile.net.example uses the SUBMITTER parameter to designate alice@mobile.net.example as the responsible submitter for this message. Further, this MTA also inserts a Sender header to ensure the purported responsible address derived from the RFC 2822 headers matches the SUBMITTER address.
请注意，mobile.net.example使用SUBMITTER参数指定alice@mobile.net.example作为此邮件的负责提交者。此外，此MTA还插入发件人标头，以确保从RFC 2822标头派生的声称负责的地址与提交人地址匹配。
Likewise, conventional ISPs may also choose to use the SUBMITTER parameter to designate as the responsible submitter the user's address on the ISP's network if that address is different from the MAIL FROM address. This may be especially useful for ISPs that host multiple domains or otherwise share MTAs among multiple domains.
类似地，如果ISP网络上的用户地址与邮件发件人地址不同，传统ISP也可以选择使用SUBMITTER参数将该地址指定为负责提交者。这对于承载多个域或在多个域之间共享MTA的ISP特别有用。
When the message is subsequently forwarded by the almamater.edu.example MTA, that MTA will replace the SUBMITTER parameter with bob@almamater.edu.example as in Section 5.2 and add its own Resent-From header.
当邮件随后由almamater.edu.example MTA转发时，该MTA将用bob@almamater.edu.example如第5.2节所述，并添加其自己的“重新发送自”标题。
While on a business trip, Alice uses the broadband access facilities provided by the Exemplar Hotel to connect to the Internet and send e-mail. The hotel routes all outbound e-mail through its own SMTP server, email.hotel.com.example.
在出差期间，Alice使用Examplar酒店提供的宽带接入设施连接到互联网并发送电子邮件。酒店通过自己的SMTP服务器email.hotel.com.example路由所有出站电子邮件。
The SMTP session for Alice's message to Bob from the Exemplar Hotel would look like this:
从Examplar Hotel向Bob发送Alice邮件的SMTP会话如下所示：
S: 220 almamater.edu.example ESMTP server ready
C: EHLO email.hotel.com.example
S: 250-almamater.edu.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com>
SUBMITTER=guest.services@email.hotel.com.example
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@almamater.edu.example>
S: 250 <bob@almamater.edu.example> recipient ok
C: DATA
S: 354 okay, send message
C: Resent-From: guest.services@email.hotel.com.example
C: Received By: ...
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
S: 220 almamater.edu.example ESMTP server ready
C: EHLO email.hotel.com.example
S: 250-almamater.edu.example
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<alice@example.com>
SUBMITTER=guest.services@email.hotel.com.example
S: 250 <alice@example.com> sender ok
C: RCPT TO:<bob@almamater.edu.example>
S: 250 <bob@almamater.edu.example> recipient ok
C: DATA
S: 354 okay, send message
C: Resent-From: guest.services@email.hotel.com.example
C: Received By: ...
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
Note that email.hotel.com.example uses the SUBMITTER parameter to designate a generic account guest.services@email.hotel.com.example as the responsible submitter address for this message. A generic account is used since Alice herself does not have an account at that domain. Furthermore, this client also inserts a Resent-From header to ensure the purported responsible address derived from the RFC 2822 headers with the SUBMITTER address.
请注意，email.hotel.com.example使用SUBMITTER参数指定一个通用帐户guest。services@email.hotel.com.example作为此邮件的负责提交者地址。由于Alice本人在该域中没有帐户，因此使用通用帐户。此外，该客户端还插入一个REENT From头，以确保从RFC 2822头派生的声称负责的地址具有提交者地址。
As before, when the message is subsequently forwarded by the almamater.edu.example MTA, that MTA will replace the SUBMITTER parameter with bob@almamater.edu.example as in Section 5.2 and add its own Resent-From header.
如前所述，当almamater.edu.example MTA随后转发消息时，该MTA将用bob@almamater.edu.example如第5.2节所述，并添加其自己的“重新发送自”标题。
Alice sends an incorrectly addressed e-mail message and receives a non-delivery report from a SUBMITTER-compliant server.
Alice发送地址不正确的电子邮件，并从符合提交者要求的服务器接收未送达报告。
S: 220 example.com ESMTP server ready
C: EHLO almamater.edu.example
S: 250-example.com
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<> SUBMITTER=mailer-daemon@almamater.edu.example
S: 250 OK
C: RCPT TO:<alice@example.com>
S: 250 OK
C: DATA
S: 354 OK, send message
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
S: 220 example.com ESMTP server ready
C: EHLO almamater.edu.example
S: 250-example.com
S: 250-DSN
S: 250-AUTH
S: 250-SUBMITTER
S: 250 SIZE
C: MAIL FROM:<> SUBMITTER=mailer-daemon@almamater.edu.example
S: 250 OK
C: RCPT TO:<alice@example.com>
S: 250 OK
C: DATA
S: 354 OK, send message
C: (message body goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
This extension provides an optimization to allow an SMTP client to identify the responsible submitter of an e-mail message in the SMTP protocol, and to enable SMTP servers to perform efficient validation of that identity before the message contents are transmitted.
此扩展提供了一种优化，允许SMTP客户端在SMTP协议中标识电子邮件的负责提交者，并允许SMTP服务器在发送邮件内容之前对该标识执行有效验证。
It is, however, quite possible for an attacker to forge the value of the SUBMITTER parameter. Furthermore, it is possible for an attacker to transmit an e-mail message whose SUBMITTER parameter does not match the purported responsible address of the message as derived from the RFC 2822 headers. Therefore, the presence of the SUBMITTER parameter provides, by itself, no assurance of the authenticity of the message or the responsible submitter. Rather, the SUBMITTER parameter is intended to provide additional information to receiving e-mail systems to enable them to efficiently determine the validity of the responsible submitter, and specifically, whether the SMTP client is authorized to transmit e-mail on behalf of the purported responsible submitter's domain. Section 4.2 describes how receiving e-mail systems should process the SUBMITTER parameter.
但是，攻击者很可能伪造提交者参数的值。此外，攻击者还可能发送其提交者参数与源自RFC 2822头的消息的声称负责地址不匹配的电子邮件。因此，提交者参数的存在本身并不能保证消息或负责提交者的真实性。相反，SUBMITTER参数旨在向接收电子邮件系统提供附加信息，使其能够有效地确定责任提交者的有效性，特别是SMTP客户端是否被授权代表声称的责任提交者的域传输电子邮件。第4.2节描述了接收电子邮件系统应如何处理提交者参数。
The idea of an ESMTP extension to convey the identity of the responsible sender of an e-mail message has many progenitors. Nick Shelness suggested the idea in a private conversation with one of the authors. Pete Resnick suggested a variant on the MARID mailing list. The idea was also discussed on the Anti-Spam Research Group (ASRG) mailing list.
ESMTP扩展以传递电子邮件负责发送者的身份的想法有许多先祖。Nick Shelness在与其中一位作者的私人谈话中提出了这个想法。Pete Resnick建议在MARID邮件列表上添加一个变体。反垃圾邮件研究小组（ASRG）邮件列表中也讨论了这一想法。
The authors would also like to thank the participants of the MARID working group and the following individuals for their comments and suggestions, which greatly improved this document:
作者还要感谢MARID工作组的与会者和以下个人的意见和建议，这些意见和建议大大改进了本文件：
Robert Atkinson, Simon Attwell, Roy Badami, Greg Connor, Dave Crocker, Matthew Elvey, Tony Finch, Ned Freed, Mark Lentczner, Jim Lyon, Bruce McMillan, Sam Neely, Daryl Odnert, Margaret Olson, Pete Resnick, Hector Santos, Nick Shelness, Rand Wacker, and Meng Weng Wong.
罗伯特·阿特金森、西蒙·阿特威尔、罗伊·巴达米、格雷格·康纳、戴夫·克罗克、马修·埃尔维、托尼·芬奇、内德·弗里德、马克·伦茨纳、吉姆·里昂、布鲁斯·麦克米兰、萨姆·尼利、达里尔·奥德纳特、玛格丽特·奥尔森、皮特·雷斯尼克、赫克托·桑托斯、尼克·谢尔内斯、兰德·瓦克和孟翁·王。
The IANA has registered the SUBMITTER SMTP service extension.
IANA已注册提交者SMTP服务扩展。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年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月。
[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月。
[MSG-FORMAT] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[MSG-FORMAT]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[PRA] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[PRA]Lyon，J.，“电子邮件中声称的责任地址”，RFC 4407，2006年4月。
[SENDER-ID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[SENDER-ID]Lyon，J.和M.Wong，“发件人ID:验证电子邮件”，RFC 4406，2006年4月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提交]Gellens，R.和J.Klensin，“邮件信息提交”，RFC 4409，2006年4月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTPAUTH]迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
Authors' Addresses
作者地址
Eric Allman Sendmail, Inc. 6425 Christie Ave, Suite 400 Emeryville, CA 94608 USA
Eric Allman Sendmail，Inc.美国加利福尼亚州埃默里维尔克里斯蒂大道6425号400室，邮编94608
EMail: eric@sendmail.com
EMail: eric@sendmail.com
Harry Katz Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA
Harry Katz微软公司美国华盛顿州雷德蒙微软路1号，邮编：98052
EMail: hkatz@microsoft.com
EMail: hkatz@microsoft.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）提供。