Internet Engineering Task Force (IETF) F. Martin, Ed.
Request for Comments: 7960 LinkedIn
Category: Informational E. Lear, Ed.
ISSN: 2070-1721 Cisco Systems GmbH
T. Draegen, Ed.
dmarcian, inc.
E. Zwicky, Ed.
Yahoo
K. Andersen, Ed.
LinkedIn
September 2016
Internet Engineering Task Force (IETF) F. Martin, Ed.
Request for Comments: 7960 LinkedIn
Category: Informational E. Lear, Ed.
ISSN: 2070-1721 Cisco Systems GmbH
T. Draegen, Ed.
dmarcian, inc.
E. Zwicky, Ed.
Yahoo
K. Andersen, Ed.
LinkedIn
September 2016
Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows
基于域的消息验证、报告和一致性（DMARC）与间接电子邮件流之间的互操作性问题
Abstract
摘要
Domain-based Message Authentication, Reporting, and Conformance (DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients. Collectively, these email flows are referred to as "indirect email flows". This document describes these interoperability issues and presents possible methods for addressing them.
基于域的消息验证、报告和一致性（DMARC）引入了一种机制，用于表示域级别的策略和首选项，以进行电子邮件验证、处置和报告。但是，当消息不直接从作者的管理域流向最终收件人时，DMARC机制会导致潜在的破坏性互操作性问题。这些电子邮件流统称为“间接电子邮件流”。本文档描述了这些互操作性问题，并介绍了解决这些问题的可能方法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7960.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7960.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Document Conventions .......................................4
2. Causes of Interoperability Issues ...............................4
2.1. Identifier Alignment .......................................4
2.1.1. DKIM Identifier(s) ..................................5
2.1.2. SPF Identifier(s) ...................................6
2.1.3. Multiple RFC5322.From Addresses .....................6
2.2. Message Forwarding .........................................6
2.3. Message Modification .......................................7
3. Internet Mail Architecture, DMARC, and Indirect Email Flows .....8
3.1. Message Handling System ....................................8
3.1.1. Message Submission Agents ...........................8
3.1.2. Message Transfer Agents .............................9
3.1.2.1. Message Encoding ...........................9
3.1.2.2. Header Standardization ....................10
3.1.2.3. Content Validation ........................10
3.1.3. Message Delivery Agents ............................10
3.2. Mediators .................................................11
3.2.1. Alias ..............................................11
3.2.2. ReSenders ..........................................12
3.2.3. Mailing Lists ......................................12
3.2.3.1. Mailing List Operational Effects ..........13
3.2.4. Gateways ...........................................13
3.2.5. Boundary Filters ...................................14
3.3. Combinations ..............................................15
4. Possible Mitigations of Interoperability Issues ................15
4.1. Mitigations in Current Use ................................16
4.1.1. Mitigations for Senders ............................16
4.1.1.1. Identifier Alignment ......................16
4.1.1.2. Message Modification ......................17
4.1.2. Mitigations for Receivers ..........................17
1. Introduction ....................................................3
1.1. Document Conventions .......................................4
2. Causes of Interoperability Issues ...............................4
2.1. Identifier Alignment .......................................4
2.1.1. DKIM Identifier(s) ..................................5
2.1.2. SPF Identifier(s) ...................................6
2.1.3. Multiple RFC5322.From Addresses .....................6
2.2. Message Forwarding .........................................6
2.3. Message Modification .......................................7
3. Internet Mail Architecture, DMARC, and Indirect Email Flows .....8
3.1. Message Handling System ....................................8
3.1.1. Message Submission Agents ...........................8
3.1.2. Message Transfer Agents .............................9
3.1.2.1. Message Encoding ...........................9
3.1.2.2. Header Standardization ....................10
3.1.2.3. Content Validation ........................10
3.1.3. Message Delivery Agents ............................10
3.2. Mediators .................................................11
3.2.1. Alias ..............................................11
3.2.2. ReSenders ..........................................12
3.2.3. Mailing Lists ......................................12
3.2.3.1. Mailing List Operational Effects ..........13
3.2.4. Gateways ...........................................13
3.2.5. Boundary Filters ...................................14
3.3. Combinations ..............................................15
4. Possible Mitigations of Interoperability Issues ................15
4.1. Mitigations in Current Use ................................16
4.1.1. Mitigations for Senders ............................16
4.1.1.1. Identifier Alignment ......................16
4.1.1.2. Message Modification ......................17
4.1.2. Mitigations for Receivers ..........................17
4.1.2.1. Identifier Alignment ......................17
4.1.2.2. Policy Override ...........................17
4.1.3. Mitigations for ReSenders ..........................18
4.1.3.1. Changes to the RFC5322.From ...............18
4.1.3.2. Avoiding Message Modification .............18
4.1.3.3. Mailing Lists .............................18
4.2. Proposed and In-Progress Mitigations ......................20
4.2.1. Getting More Radical: Requiring New
Communication Paths between MUAs ...................21
5. Security Considerations ........................................21
6. References .....................................................22
6.1. Normative References ......................................22
6.2. Informative References ....................................23
Appendix A. Example SPF Bounce ...................................24
A.1. Initial Message ...........................................24
A.2. Notification Message ......................................25
Acknowledgments ...................................................26
Authors' Addresses ................................................27
4.1.2.1. Identifier Alignment ......................17
4.1.2.2. Policy Override ...........................17
4.1.3. Mitigations for ReSenders ..........................18
4.1.3.1. Changes to the RFC5322.From ...............18
4.1.3.2. Avoiding Message Modification .............18
4.1.3.3. Mailing Lists .............................18
4.2. Proposed and In-Progress Mitigations ......................20
4.2.1. Getting More Radical: Requiring New
Communication Paths between MUAs ...................21
5. Security Considerations ........................................21
6. References .....................................................22
6.1. Normative References ......................................22
6.2. Informative References ....................................23
Appendix A. Example SPF Bounce ...................................24
A.1. Initial Message ...........................................24
A.2. Notification Message ......................................25
Acknowledgments ...................................................26
Authors' Addresses ................................................27
DMARC [RFC7489] introduces a mechanism for expressing domain-level policies and preferences for message validation, disposition, and reporting. The DMARC mechanism, especially when employed with restrictive policies, encounters several different types of interoperability issues due to third-party message sourcing, message transformation, or rerouting. In particular, DMARC with restrictive policies causes problems for many Mailing Lists.
DMARC[RFC7489]引入了一种机制，用于表示域级策略和消息验证、处置和报告的首选项。由于第三方消息源、消息转换或重新路由，DMARC机制（尤其是与限制性策略一起使用时）会遇到几种不同类型的互操作性问题。特别是，带有限制性策略的DMARC会给许多邮件列表带来问题。
At the time of writing this document, the DMARC base specification has been published as Informational RFC 7489 [RFC7489] and has seen significant deployment within the email community.
在编写本文档时，DMARC基本规范已作为信息RFC 7489[RFC7489]发布，并在电子邮件社区中得到了大量部署。
Cases in which email does not flow directly from the author's administrative domain to the recipient's domain(s) are collectively referred to in this document as "indirect email flows". Due to existing and increasing adoption of DMARC, the impact of DMARC-based email rejection policies on indirect email flows can be significant for a select subset of general email traffic.
在本文档中，电子邮件不会直接从作者的管理域流向收件人的域的情况统称为“间接电子邮件流”。由于DMARC的存在和越来越多的采用，基于DMARC的电子邮件拒绝策略对间接电子邮件流的影响对于一般电子邮件流量的选定子集可能非常重要。
Several known causes of interoperability issues are presented, followed by a description of components within the Internet Mail Architecture [RFC5598] where interoperability issues can arise.
介绍了互操作性问题的几个已知原因，然后介绍了Internet邮件体系结构[RFC5598]中可能出现互操作性问题的组件。
Finally, known and possible methods for addressing interoperability issues are presented. There are often multiple ways to address any given interoperability issue. While this document strives to be comprehensive in its review, it should not be treated as complete.
最后，介绍了解决互操作性问题的已知和可能的方法。通常有多种方法来解决任何给定的互操作性问题。虽然本文件力求全面审查，但不应视为完整。
Note that some practices that are in use at the time of this document may or may not be "best practices", especially as future standards evolve.
请注意，在编写本文件时使用的一些实践可能是也可能不是“最佳实践”，特别是随着未来标准的发展。
The notation used in this document for structured fields is taken from [RFC5598], Section 1.3.
本文件中结构化字段使用的符号取自[RFC5598]，第1.3节。
The term "notification message" ([RFC5321], Section 4.5.5) is used to refer to a message with a null RFC5321.MailFrom.
术语“通知消息”（[RFC5321]，第4.5.5节）用于指RFC5321.MailFrom为空的消息。
The terms "Organizational Domain" and "Authenticated Identifiers" are specified in DMARC ([RFC7489], Section 3).
DMARC（[RFC7489]，第3节）中规定了术语“组织域”和“认证标识符”。
All words that begin with capital letters take their formal meanings from these references.
所有以大写字母开头的单词的正式含义都来自这些参考文献。
Interoperability issues between DMARC and indirect email flows arise when conformance to the DMARC specification leads a receiving implementation to apply DMARC-based policy restrictions to messages that are both compliant with the architecture as specified in [RFC5598] and viewed as legitimate by the intended Recipient.
当与DMARC规范的一致性导致接收实施将基于DMARC的策略限制应用于符合[RFC5598]中规定的体系结构并被预期收件人视为合法的邮件时，DMARC和间接电子邮件流之间的互操作性问题就会出现。
Note that domains that assert a "p=none" policy and email messages that pass standard DMARC validation do not have any interoperability issues.
请注意，声明“p=none”策略的域和通过标准DMARC验证的电子邮件没有任何互操作性问题。
Email messages that do not conform to IETF email specifications but are considered legitimate by the intended Recipients are not discussed in this document.
本文件不讨论不符合IETF电子邮件规范但被预期收件人视为合法的电子邮件。
The rest of this section describes several conceptual causes of interoperability issues.
本节的其余部分描述了互操作性问题的几个概念原因。
Note to operators and administrators: The identifiers that are used by the Sender Policy Framework (SPF) are technical components of the transport process for SMTP. They may or may not, as described below, bear a meaningful relationship to the content or source of the message itself. This "relationship by proximity" can be a point of confusion for non-technical end users, either recipients or senders.
操作员和管理员注意：发件人策略框架（SPF）使用的标识符是SMTP传输过程的技术组件。如下文所述，它们可能与信息本身的内容或来源存在或不存在有意义的关系。这种“近距离关系”可能会让非技术性最终用户（收件人或发件人）感到困惑。
DMARC relies on DomainKeys Identified Mail (DKIM) [RFC6376] and SPF [RFC7208] to perform message source validation. The DMARC [RFC7489] specification refers to source domains that are validated by DKIM or SPF as "Authenticated Identifiers". To be used by DMARC, an "Authenticated Identifier" must also be related to the domain found in the message's RFC5322.From header field [RFC5322]. This relationship between an Authenticated Identifier's domain and the domain of the RFC5322.From is referred to as "Identifier Alignment".
DMARC依靠域密钥标识邮件（DKIM）[RFC6376]和SPF[RFC7208]来执行消息源验证。DMARC[RFC7489]规范将DKIM或SPF验证为“经过身份验证的标识符”的源域称为源域。要由DMARC使用，“经过身份验证的标识符”还必须与在消息的RFC5322.From标头字段[RFC5322]中找到的域相关。已验证标识符的域与RFC5322.From域之间的这种关系称为“标识符对齐”。
DMARC allows for Identifier Alignment to be determined in two different modes: strict and relaxed. Strict mode requires an exact match between the domain of any of the Authenticated Identifiers and the message's RFC5322.From header field [RFC5322]. Relaxed mode allows for Identifier Alignment if Authenticated Identifiers and the message's RFC5322.From header field [RFC5322] share the same Organizational Domain. In general, DMARC interoperability issues are the same for both strict and relaxed alignment, but strict alignment constrains the possible solutions because of the more rigorous matching requirement. Some of the mitigations described in this document only work with the relaxed mode of Identifier Alignment.
DMARC允许在两种不同的模式下确定标识符对齐：严格模式和放松模式。严格模式要求任何经过身份验证的标识符的域与消息的RFC5322.From标头字段[RFC5322]完全匹配。如果经过身份验证的标识符和消息的RFC5322.From标头字段[RFC5322]共享同一组织域，则松弛模式允许标识符对齐。一般来说，DMARC互操作性问题对于严格对齐和放松对齐都是相同的，但是严格对齐限制了可能的解决方案，因为更严格的匹配要求。本文档中描述的一些缓解措施仅适用于标识符对齐的放松模式。
DKIM provides a cryptographic means for one or more domain identifiers to be associated with a particular message. As a standalone technology, DKIM identifiers are not required to be related to the source of the message's content. However, for a DKIM identifier to align in DMARC, the signing domain of a valid signature must be part of the same Organizational Domain as the domain in the RFC5322.From header field [RFC5322].
DKIM为与特定消息关联的一个或多个域标识符提供加密手段。作为一种独立技术，DKIM标识符不需要与消息内容的源相关。但是，要使DKIM标识符在DMARC中对齐，有效签名的签名域必须与RFC5322中的域属于同一组织域。从标头字段[RFC5322]。
In addition, DKIM allows for the possibility of multiple valid signatures. These multiple signatures may be from the same or different domains; there are no restrictions within the DKIM specification. The DMARC mechanism will process Authenticated Identifiers that are based on DKIM signatures until an aligned Authenticated Identifier is found (if any). However, operational experience has shown that some implementations have difficulty processing multiple signatures. Implementations that cannot process multiple DKIM signatures may incorrectly flag messages as "not passing" (DMARC alignment) and erroneously apply DMARC-based policy to otherwise conforming messages.
此外，DKIM允许多个有效签名。这些多个签名可能来自相同或不同的域；DKIM规范中没有任何限制。DMARC机制将处理基于DKIM签名的认证标识符，直到找到对齐的认证标识符（如果有）。然而，运行经验表明，一些实现难以处理多个签名。无法处理多个DKIM签名的实现可能会错误地将消息标记为“未通过”（DMARC对齐），并错误地将基于DMARC的策略应用于其他一致性消息。
The SPF specification [RFC7208] defines two Authenticated Identifiers for each message. These identifiers derive from:
SPF规范[RFC7208]为每条消息定义了两个经过身份验证的标识符。这些标识符源自：
a. the RFC5321.MailFrom [RFC5321] domain, and
a. [RFC5321]域中的RFC5321.MailFrom，以及
b. the RFC5321.HELO/.EHLO SMTP domain.
b. RFC5321.HELO/.EHLO SMTP域。
In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is defined to be based on RFC5321.MailFrom unless that value is absent (as in the case of notification messages), in which case, the second (RFC5321.HELO/.EHLO) identifier value is used. This "fallback" definition has occasionally been misunderstood by operators of MTA systems since notification messages are often an "automatic" feature of MTA software. Some MTA software does not provide the ability to apply a DKIM signature to such notification messages.
在SPF规范中，RFC7208.MAILFROM[RFC7208]值定义为基于RFC5321.MAILFROM，除非该值不存在（如通知消息的情况），在这种情况下，使用第二个（RFC5321.HELO/.EHLO）标识符值。MTA系统的操作员偶尔会误解此“回退”定义，因为通知消息通常是MTA软件的“自动”功能。某些MTA软件不提供将DKIM签名应用于此类通知邮件的功能。
See Appendix A for an example treatment of this scenario.
有关此场景的示例处理，请参见附录A。
For the purposes of DMARC validation/alignment, the hybrid RFC7208.MAILFROM [RFC7208] identifier's domain is used if and only if it is aligned with the RFC5322.From [RFC5322] domain. The alignment of the validated domain is determined based on the DMARC record's "strict" or "relaxed" designation as described above for the DKIM identifiers and in [RFC7489].
出于DMARC验证/校准的目的，当且仅当混合RFC7208.MAILFROM[RFC7208]标识符的域与RFC5322.From[RFC5322]域对齐时，才使用混合RFC7208.MAILFROM[RFC7208]标识符的域。验证域的对齐是基于DMARC记录的“严格”或“放松”指定来确定的，如上述DKIM标识符和[RFC7489]中所述。
[RFC5322] permits only one From header field, but it may contain multiple mailboxes. Since this is an extremely rare usage, DMARC specifies that the handling of this situation is implementation dependent.
[RFC5322]只允许一个发件人字段，但它可能包含多个邮箱。由于这是一种极为罕见的用法，DMARC指定这种情况的处理取决于实现。
Because the presence of multiple domains can be used by an attacker (an attacker could add their domain to the RFC5322.From field, provide arbitrary new content, and sign the message), the DMARC specification recommends that the strictest policy be applied to such messages (Section 6.6.1 of [RFC7489]).
由于攻击者可以使用多个域（攻击者可以将其域添加到RFC5322.From字段，提供任意新内容，并对消息进行签名），DMARC规范建议对此类消息应用最严格的策略（RFC7489第6.6.1节）。
Section 3 describes forwarding behavior as it relates to the components of the Internet Mail Architecture.
第3节描述了与Internet邮件体系结构组件相关的转发行为。
All forwarding operations involve the retransmission of email. As discussed above, in order for SPF to yield an Authenticated Identifier that is pertinent to DMARC, the domain of the
所有转发操作都涉及电子邮件的重新传输。如上所述，为了使SPF生成与DMARC相关的经过身份验证的标识符
RFC7208.MAILFROM must be in alignment with the RFC5322.From header field. Forwarding introduces specific issues to the availability of SPF-based Authenticated Identifiers:
RFC7208.MAILFROM必须与RFC5322.From标头字段对齐。转发给基于SPF的身份验证标识符的可用性带来了特定问题：
o If the RFC5321.MailFrom is present and the forwarder maintains the original RFC5321.MailFrom, SPF validation will fail unless the forwarder is an authorized part of the originator's email sending infrastructure. If the forwarder replaces the RFC5321.MailFrom with its own domain, SPF might pass, but Identifier Alignment with the RFC5322.From header field will fail.
o 如果存在RFC5321.MailFrom并且转发器维护原始RFC5321.MailFrom，则SPF验证将失败，除非转发器是发端人电子邮件发送基础结构的授权部分。如果转发器使用自己的域替换RFC5321.MailFrom，SPF可能会通过，但与RFC5322.From标头字段的标识符对齐将失败。
o If the RFC5321.MailFrom is empty (as in the case of Delivery Status Notifications), the RFC5321.HELO/.EHLO domain of the forwarder will likely be in a different Organizational Domain than the original RFC5322.From header field's domain. SPF may pass, but Identifier Alignment with the RFC5322.From header field will fail.
o 如果RFC5321.MailFrom为空（与传递状态通知的情况相同），则转发器的RFC5321.HELO/.EHLO域可能位于与原始RFC5322.From标头字段域不同的组织域中。SPF可能会通过，但与RFC5322.From标头字段的标识符对齐将失败。
In both cases, SPF cannot yield relevant Authenticated Identifiers, and DKIM must be relied upon to produce results that are relevant to DMARC.
在这两种情况下，SPF都不能生成相关的经过身份验证的标识符，必须依赖DKIM生成与DMARC相关的结果。
Modification of email content invalidates most DKIM signatures, and many message-forwarding systems modify email content. Mailing List processors are a common example of such systems, but other forwarding systems also make modifications.
修改电子邮件内容会使大多数DKIM签名无效，许多邮件转发系统会修改电子邮件内容。邮件列表处理器是此类系统的常见示例，但其他转发系统也会进行修改。
Although DKIM provides a length flag so that content can be appended without invalidating the signature, in practice, particularly with MIME-encoded [RFC2045] messages, a Mailing List processor will do more than simply append content (see Section 5.3 of [RFC5598] for details). Furthermore, the length flag is seldom used due to security issues (see Section 8.2 of [RFC6376] for additional security considerations). Therefore, this method is only mentioned here for completeness.
尽管DKIM提供了一个长度标志，以便可以在不使签名无效的情况下追加内容，但在实践中，特别是对于MIME编码的[RFC2045]消息，邮件列表处理器将做的不仅仅是追加内容（有关详细信息，请参阅[RFC5598]的第5.3节）。此外，由于安全问题，很少使用长度标志（更多安全注意事项参见[RFC6376]第8.2节）。因此，此处仅提及此方法是为了完整性。
DKIM describes two canonicalizations for use when preparing the header and body for DKIM processing: simple and relaxed. The latter is designed to accommodate trivial modifications to whitespace and folding that, at least in the header case, generally have no semantic significance. However, the relaxed canonicalization is more computationally intensive and may not have been preferred in the early deployment of DKIM, leaving some deployments using the less forgiving "simple" canonicalization. While the prevalence is unknown, there are some DKIM verifiers that have problems evaluating relaxed canonicalization correctly.
DKIM描述了为DKIM处理准备标头和正文时使用的两种规范化：简单和轻松。后者被设计来适应对空白和折叠的细微修改，至少在标题的情况下，这些修改通常没有语义意义。然而，宽松的规范化在计算上更为密集，在DKIM的早期部署中可能不是首选，因此有些部署使用的是不太宽容的“简单”规范化。虽然患病率未知，但仍有一些DKIM验证者在正确评估松弛规范化方面存在问题。
This section describes components within the Internet Mail Architecture [RFC5598] where interoperability issues between DMARC and indirect email flows can be found.
本节介绍Internet邮件体系结构[RFC5598]中的组件，其中可以发现DMARC和间接电子邮件流之间的互操作性问题。
Section 4 of [RFC5598] describes six basic components that make up the Message Handling System (MHS):
[RFC5598]第4节描述了构成信息处理系统（MHS）的六个基本组件：
o Message
o 消息
o Message User Agent (MUA)
o 消息用户代理（MUA）
o Message Submission Agent (MSA)
o 邮件提交代理（MSA）
o Message Transfer Agent (MTA)
o 邮件传输代理（MTA）
o Message Delivery Agent (MDA)
o 消息传递代理（MDA）
o Message Store (MS)
o 消息存储（MS）
Of these components, MSA, MTA, and MDA are discussed in relation to interoperability with DMARC.
在这些组件中，MSA、MTA和MDA与DMARC的互操作性有关。
Section 5 of [RFC5598] also defines a Mediator as a hybrid of several component types. A Mediator is given special consideration in this section due to the unique issues they face when attempting to interoperate with DMARC.
[RFC5598]第5节还将中介定义为几种组件类型的混合。由于调解人在尝试与DMARC互操作时面临的独特问题，本节特别考虑调解人。
An MSA accepts messages submitted by a Message User Agent (MUA) and enforces the policies of the hosting ADministrative Management Domain (ADMD) and the requirements of Internet standards.
MSA接受由消息用户代理（MUA）提交的消息，并强制执行托管管理域（ADMD）的策略和Internet标准的要求。
MSAs are split into two sub-components:
MSA分为两个子组件：
o Author-focused MSA functions (aMSA)
o 以作者为中心的MSA功能（aMSA）
o MHS-focused MSA functions (hMSA)
o MHS聚焦MSA功能（hMSA）
MSA interoperability issues with DMARC begin when an aMSA accepts a message where the RFC5322.From header field contains a domain that is outside of the ADMD of the MSA. This situation manifests in one of several ways, such as when someone uses a mail service with their own domain but has failed to properly configure an SPF record or when an
当aMSA接受RFC5322.From标头字段包含MSA ADMD之外的域的消息时，DMARC的MSA互操作性问题开始出现。这种情况以几种方式之一表现出来，例如，当某人在自己的域中使用邮件服务时，但未能正确配置SPF记录，或者
MUA attempts to transmit mail as someone else. Examples of the latter situation include "forward-to-friend" functionality commonly found on news/article websites or "send-as" functionality present on some MUAs.
MUA试图以其他人的身份发送邮件。后一种情况的示例包括新闻/文章网站上常见的“转发给朋友”功能或某些MUA上的“发送为”功能。
When an hMSA takes responsibility for transit of a message containing a domain in the RFC5322.From header field that is outside of the hMSA's ADMD, the hMSA faces DMARC interoperability issues if the domain publishes a DMARC policy of "quarantine" or "reject". These issues are marked by the inherent difficulty of establishing alignment with the domain present in a message's RFC5322.From header field. Examples of this issue include:
当hMSA负责传输RFC5322中包含域的消息时。从hMSA的ADMD之外的标头字段，如果域发布“隔离”或“拒绝”的DMARC策略，hMSA将面临DMARC互操作性问题。这些问题的特点是与消息的RFC5322.From标头字段中存在的域建立对齐的固有困难。这一问题的例子包括：
o Partially open relays - a residential ISP that allows its customers to relay non-local domains through its infrastructure.
o 部分开放中继-一个住宅ISP，允许其客户通过其基础设施中继非本地域。
o Embedded devices - cable/DSL modems, firewalls, wireless access points, and printers that send email using hardcoded domains.
o 嵌入式设备-使用硬编码域发送电子邮件的电缆/DSL调制解调器、防火墙、无线接入点和打印机。
o Devices that send mail on behalf of a user - scanners, security cameras, and alarms that send mail as their owner or a device user.
o 代表用户发送邮件的设备-扫描仪、安全摄像头和作为其所有者或设备用户发送邮件的报警器。
o Email service providers - ESPs that service customers who are using domains that publish a DMARC "reject" policy.
o 电子邮件服务提供商-为使用发布DMARC“拒绝”策略的域的客户提供服务的ESP。
o Calendaring software - an invited member of an event modifies the event, causing the calendaring software to emit an update that claims to come from the creator of the event.
o 日历软件-事件的受邀成员修改事件，导致日历软件发出声称来自事件创建者的更新。
MTAs relay a message until the message reaches a destination MDA. Some common message-handling strategies break the integrity of DKIM signatures. A restrictive DMARC policy along with a broken DKIM signature causes latent interoperability problems to become overt problems.
MTA中继邮件，直到邮件到达目标MDA。一些常见的消息处理策略破坏了DKIM签名的完整性。限制性的DMARC策略以及损坏的DKIM签名会导致潜在的互操作性问题成为公开的问题。
An MTA may modify the message encoding, for instance, by converting 8-bit MIME sections to quoted-printable 7-bit sections. This modification is outside the scope of DKIM canonicalization and will invalidate DKIM signatures that include message content.
MTA可以修改邮件编码，例如，将8位MIME节转换为带引号的可打印7位节。此修改不在DKIM规范化的范围内，将使包含消息内容的DKIM签名无效。
An MTA could also re-encode the message without changing the encoding type: receiving a MIME-encoded message and producing a semantically and semiotically equivalent MIME body that is not identical to the original. This is characteristic of systems that use some other message representation internally.
MTA还可以在不更改编码类型的情况下对消息进行重新编码：接收MIME编码的消息并生成语义和符号上等价的MIME正文，该正文与原始正文不同。这是在内部使用其他消息表示的系统的特征。
An MTA may rewrite headers to bring them into compliance with existing RFCs. For example, some common MTAs will correct comprehensible but non-compliant date formats to compliant ones.
MTA可以重写标题，使其符合现有RFC。例如，一些常见的MTA会将可理解但不符合要求的日期格式更正为符合要求的格式。
Header rewriting is outside the scope of DKIM canonicalization and will invalidate DKIM signatures. All downstream DMARC processing with be unable to utilize DKIM to yield Authenticated Identifiers due to header rewriting.
头重写超出了DKIM规范化的范围，将使DKIM签名无效。由于标头重写，所有下游DMARC处理无法利用DKIM生成经过身份验证的标识符。
Providing solutions for issues relating to non-RFC-compliant emails is outside the scope of this document.
为与不符合RFC的电子邮件相关的问题提供解决方案超出了本文档的范围。
An MTA may also implement security-motivated changes to the content of email messages, dropping or altering sections of messages, causing breakage of DKIM signatures.
MTA还可以对电子邮件内容实施出于安全考虑的更改，删除或更改邮件的部分，从而导致DKIM签名被破坏。
The MDA transfers a message from the MHS to a mailbox. Like the MSA, the MDA consists of two sub-components:
MDA将消息从MHS传输到邮箱。与MSA一样，MDA由两个子组件组成：
o MHS-focused MDA functions (hMDA)
o 以MHS为重点的MDA功能（hMDA）
o Recipient-focused MDA functions (rMDA)
o 以收件人为中心的MDA功能（rMDA）
Both the hMDA and the rMDA can redirect a message to an alternative address. DMARC interoperability issues related to redirecting of messages are described in Section 3.2.
hMDA和rMDA都可以将消息重定向到备用地址。第3.2节描述了与消息重定向相关的DMARC互操作性问题。
Sieve [RFC5228] functionality often lives in the rMDA sub-component and can cause DMARC interoperability issues. The Sieve 'addheader' and 'deleteheader' filtering actions can modify messages and invalidate DKIM signatures, removing DKIM-supplied Authenticated Identifiers as inputs to the DMARC mechanism. There are also Sieve extensions [RFC5703] that modify the body. Sieve alterations may only become an issue when the email is reintroduced into the transport infrastructure.
筛选[RFC5228]功能通常存在于rMDA子组件中，并可能导致DMARC互操作性问题。筛选“addheader”和“deleteheader”过滤操作可以修改消息并使DKIM签名无效，删除DKIM提供的身份验证标识符作为DMARC机制的输入。还有一些筛网扩展[RFC5703]可以修改主体。只有在将电子邮件重新引入传输基础设施时，筛选更改才可能成为一个问题。
Mediators [RFC5598] forward messages through a re-posting process. Mediators share some functionality with basic MTA relaying but have greater flexibility in both addressing and content modifications.
调解人[RFC5598]通过重新发布过程转发消息。中介与基本MTA中继共享一些功能，但在寻址和内容修改方面具有更大的灵活性。
DMARC interoperability issues are common within the context of Mediators, which are often used precisely for their ability to modify messages.
DMARC互操作性问题在中介的上下文中很常见，通常正是因为中介具有修改消息的能力。
The DMARC design does not cope with some Mediator functionality such as content modifications that invalidate DKIM signatures and RFC5321.MailFrom rewriting to support SPF authentication of re-sent mail when the new Recipient receives the message from the Mediator rather than the initial organization.
DMARC设计不处理某些中介功能，如内容修改，使DKIM签名和RFC5321.MailFrom重写无效，以支持新收件人从中介（而非初始组织）接收消息时重新发送的邮件的SPF身份验证。
An Alias is a simple re-addressing facility that provides one or more new Internet Mail addresses, rather than a single, internal one. A message continues through the transfer service for delivery to one or more alternative addresses.
别名是一种简单的重新寻址功能，它提供一个或多个新的Internet邮件地址，而不是单个内部地址。消息继续通过传输服务传递到一个或多个备选地址。
Aliases can be implemented by mailbox-level forwarding (e.g., through "dot-forwarding"), Sieve-level forwarding (through the Sieve "redirect" action), or other methods. When an Alias preserves message content and does not make significant header changes, DKIM signatures may remain valid. However, Aliases often extend the delivery path outside of the scope covered by the originating ADMD's SPF record(s).
别名可以通过邮箱级转发（例如，通过“点转发”）、筛级转发（通过筛“重定向”操作）或其他方法实现。当别名保留消息内容且未对消息头进行重大更改时，DKIM签名可能仍然有效。但是，别名通常会将传递路径扩展到原始ADMD的SPF记录所涵盖的范围之外。
Examples of Aliasing include:
别名的示例包括：
o Forwarding email between free email (freemail) providers to try different interfaces while maintaining an original email address;
o 在免费电子邮件（freemail）提供商之间转发电子邮件，以在保持原始电子邮件地址的同时尝试不同的界面；
o Consolidating many email addresses into a single account to centralize processing; and
o 将多个电子邮件地址合并到单个帐户以集中处理；和
o Services that provide "activity-based", "role-based", "vanity", or "temporary" email addresses such as universities and professional associations. For instance, professional or alumni institutions may offer their members an Alias for the duration of their membership but may not want to deal with the long-term storage of emails.
o 提供“基于活动”、“基于角色”、“虚荣”或“临时”电子邮件地址的服务，如大学和专业协会。例如，专业或校友机构可能会在其会员资格有效期内为其会员提供别名，但可能不想处理电子邮件的长期存储问题。
In most cases, the aMSA providing Alias services has no administrative relationship to the ADMD of the originator or the Final Recipient, so solutions to Alias-related DMARC failure should not assume such a relationship.
在大多数情况下，提供别名服务的aMSA与发起人或最终接收人的ADMD没有管理关系，因此与别名相关的DMARC故障的解决方案不应假设这种关系。
ReSenders "splice" a message's addressing information to connect the Author of the original message with the Recipient(s) of the new message. The new Recipient sees the message as being from the original Author, even if the Mediator adds commentary.
重新发送“拼接”邮件的地址信息，以将原始邮件的作者与新邮件的收件人连接起来。即使调解人添加了注释，新接收人也会将消息视为来自原始作者。
Without Authenticated Identifiers aligned with the Author's RFC5322.From header field domain, the new Recipient has no way to achieve a passing DMARC evaluation.
如果没有与作者的RFC5322对齐的经过身份验证的标识符。从标题字段域，新收件人将无法实现通过的DMARC评估。
Examples of ReSenders include MUA-level forwarding by resending a message to a new Recipient or by forwarding a message "inline" to a new Recipient (this does not include forwarding a message "as an attachment"). An additional example comes in the form of calendaring software that allows a meeting attendee (not the meeting organizer) to modify the content of an invite generating new invitations that claim to be reissued from the meeting organizer.
重发的示例包括通过将消息重发给新收件人或通过将消息“内联”转发给新收件人的MUA级别转发（这不包括将消息“作为附件”转发）。另一个示例是日历软件，它允许会议与会者（而不是会议组织者）修改邀请的内容，生成新的邀请，并声明将从会议组织者处重新发出。
A Mailing List receives messages as an explicit addressee and then reposts them to a list of subscribed members. The Mailing List performs a task that can be viewed as an elaboration of the ReSender actions.
邮件列表以显式收件人的身份接收消息，然后将其重新发送到已订阅成员的列表中。邮件列表执行的任务可以看作是重新发送操作的详细说明。
Mailing Lists share the same DMARC interoperability issues as ReSenders (Section 3.2.2) and very commonly modify headers or message content in ways that will cause DKIM to fail, including:
邮件列表与重发邮件具有相同的DMARC互操作性问题（第3.2.2节），并且通常会以导致DKIM失败的方式修改邮件头或邮件内容，包括：
o prepending the RFC5322.Subject header field with a tag, to allow the Recipient to easily identify the Mailing List within a subject line listing;
o 在RFC5322.主题标题字段前面加上标记，以允许收件人轻松识别主题行列表中的邮件列表；
o adding a footer to the email body to contain administrative instructions;
o 向电子邮件正文添加页脚，以包含管理说明；
o removing some MIME-parts from the email or converting the message to text only;
o 从电子邮件中删除一些MIME部分或仅将邮件转换为文本；
o encrypting the body with the Recipient's key using PGP (Pretty Good Privacy) or S/MIME;
o 使用PGP（相当好的隐私）或s/MIME使用收件人的密钥加密正文；
o enforcing community standards by rewriting banned words; and
o 通过改写被禁止的词语来执行社区标准；和
o allowing moderators to add arbitrary commentary to messages (discussed in [RFC6377]).
o 允许版主向消息添加任意评论（在[RFC6377]中讨论）。
Any such modifications would invalidate a DKIM signature.
任何此类修改都将使DKIM签名无效。
Header and content modifications are common for many Mailing Lists and are often central to present Mailing List functionality and usage. Furthermore, MUAs have come to rely on Mailing List message modifications to present messages to end users in expected ways.
标题和内容修改在许多邮件列表中很常见，并且通常是显示邮件列表功能和用法的核心。此外，MUA已经开始依赖邮件列表消息修改，以预期的方式向最终用户呈现消息。
Mailing Lists may also have the following DMARC interoperability issues:
邮件列表还可能存在以下DMARC互操作性问题：
o Subscribed members may not receive email from members that post using domains that publish a DMARC "p=reject" policy.
o 订阅的成员可能不会收到来自使用发布DMARC“p=reject”策略的域发布的成员的电子邮件。
o Mailing Lists may interpret DMARC-related email rejections as an inability to deliver email to the Recipients that are checking and enforcing DMARC policy. This processing may cause subscribers that are checking and enforcing DMARC policy to be inadvertently suspended or removed from the Mailing List.
o 邮件列表可能会将DMARC相关的电子邮件拒绝解释为无法向正在检查和实施DMARC策略的收件人发送电子邮件。此处理可能会导致正在检查和强制实施DMARC策略的订阅者意外挂起或从邮件列表中删除。
A Gateway performs the basic routing and transfer work of message relaying, but it is also permitted to modify content, structure, addressing, and/or other attributes as needed to send the message into a messaging environment that operates under different standards or potentially incompatible policies.
网关执行消息中继的基本路由和传输工作，但也允许根据需要修改内容、结构、寻址和/或其他属性，以将消息发送到在不同标准或潜在不兼容策略下运行的消息环境中。
Gateways share the same DMARC interoperability issues as ReSenders (Section 3.2.2).
网关与重发器具有相同的DMARC互操作性问题（第3.2.2节）。
Gateways may also share the same DMARC interoperability issues as MTAs (Section 3.1.2).
网关也可能与MTA共享相同的DMARC互操作性问题（第3.1.2节）。
Receiver systems on the non-SMTP side of a protocol Gateway may be unable to evaluate DKIM and SPF. If a message passes through a second protocol Gateway back into the SMTP domain, the transformations commonly break the original DKIM signature(s).
协议网关非SMTP端的接收器系统可能无法评估DKIM和SPF。如果消息通过第二个协议网关返回SMTP域，则转换通常会破坏原始DKIM签名。
Gateway-level forwarding can introduce DMARC interoperability issues if the Gateway is configured to rewrite the message into alternate receiving domains. For example, an acquisition may lead an acquiring
如果网关配置为将消息重写到备用接收域中，网关级转发可能会引入DMARC互操作性问题。例如，收购可能导致收购
company to decide to decommission the acquired company's domains by rewriting messages to use the domain of the acquiring company. Since the RFC5322.To header field is usually DKIM-signed, this kind of rewriting will invalidate such DKIM signatures.
公司决定通过重写消息以使用收购公司的域来解除被收购公司的域。由于RFC5322.To标头字段通常是DKIM签名的，因此这种重写将使此类DKIM签名无效。
To enforce security boundaries, organizations can subject messages to analysis for conformance with their safety policies. A filter might alter the content to render it safe, such as by removing or otherwise altering content deemed unacceptable.
为了加强安全边界，组织可以对消息进行分析，以确保其符合安全策略。过滤器可能会更改内容以使其安全，例如删除或以其他方式更改被认为不可接受的内容。
Boundary Filters share the same DMARC interoperability issues as ReSenders.
边界过滤器与重发器具有相同的DMARC互操作性问题。
Issues may arise with SPF and DKIM evaluation if performed after filter modifications.
如果在修改过滤器后执行SPF和DKIM评估，可能会出现问题。
Examples of Boundary Filters include:
边界过滤器的示例包括：
o Malware scanning: To protect readers and its reputation, an MTA that transfers a message may remove content believed to be harmful from messages, reformulate content to canonical formats in order to make them more trustworthy or easier to scan, and/or add text in the body to indicate the message has been scanned. Any such modifications would invalidate a DKIM signature.
o 恶意软件扫描：为了保护读者及其声誉，传输邮件的MTA可能会删除邮件中被认为有害的内容，将内容重新格式化为规范格式以使其更可信或更易于扫描，和/或在正文中添加文本以指示邮件已被扫描。任何此类修改都将使DKIM签名无效。
o Spam filtering: To protect its reputation and assist other MTAs, an MTA may modify a message to indicate its decision that the message is likely to be unwanted and/or add text in the body to indicate that such filtering has been done.
o 垃圾邮件过滤：为了保护其声誉并帮助其他MTA，MTA可以修改邮件以表明其决定该邮件可能是不需要的，和/或在正文中添加文本以表明已完成此类过滤。
o Other text additions: An MTA may add an organizational disclaimer or advertisement, for instance.
o 其他文本添加：例如，MTA可能会添加组织免责声明或广告。
o URL alteration: Some systems will rewrite or alter embedded URLs as a way to control the potential threat from malware.
o URL更改：一些系统将重写或更改嵌入式URL，以控制恶意软件的潜在威胁。
o Secondary MX services: The secondary MX for an organization may be external to the normal mail processing for the organization, and it may queue and forward to the primary when it becomes available. This will not invalidate DKIM but will prevent the primary from validating SPF normally. In this case, however, it is inappropriate for a primary MX server to perform an SPF check against its own secondaries. Rather, the secondary MX should perform this function and employ some trusted mechanism to communicate the results of the SPF, DKIM, and DMARC evaluation(s) to the primary MX server.
o 辅助MX服务：一个组织的辅助MX可能在该组织的正常邮件处理之外，并且当它可用时，它可能会排队并转发到主MX。这不会使DKIM无效，但会阻止主服务器正常验证SPF。但是，在这种情况下，主MX服务器不适合对其自己的辅助服务器执行SPF检查。相反，次要MX应执行此功能，并采用某种可信机制将SPF、DKIM和DMARC评估结果传达给主要MX服务器。
Indirect email flows can be combined. For example, a university student may subscribe to a Mailing List (using his university email address) while this university email address is configured to forward all emails to a freemail or a post-education corporate account provider where a more permanent email address for this student exists.
可以组合间接电子邮件流。例如，大学生可以订阅邮件列表（使用其大学电子邮件地址），而该大学电子邮件地址被配置为将所有电子邮件转发给免费邮件或教育后公司帐户提供商，其中存在该学生更永久的电子邮件地址。
Within an organization, the message may pass through various MTAs (Section 3.1.2), each of which performs a different function (authentication, filtering, distribution, etc.).
在组织内，邮件可能会通过各种MTA（第3.1.2节），每个MTA执行不同的功能（身份验证、筛选、分发等）。
Solutions to interoperability issues between DMARC and indirect email flows vary widely in their scope and implications. They range from improvements to underlying processing, such as proper handling of multiple DKIM signatures, to more radical changes to the messaging architecture. This section describes possible ways to address interoperability issues. Note that these particular mechanisms may not be considered "best practices" and may, in some cases, violate various conventions or expectations.
DMARC和间接电子邮件流之间互操作性问题的解决方案在范围和含义上存在很大差异。它们包括对底层处理的改进，如正确处理多个DKIM签名，以及对消息传递体系结构的更彻底的更改。本节介绍解决互操作性问题的可能方法。请注意，这些特定机制可能不被视为“最佳做法”，在某些情况下可能违反各种公约或期望。
Receivers sometimes need to deliver email messages that do not conform to any standard or protocol, but are otherwise desired by end users. Mitigating the impact of DMARC on indirect email flows is especially important to receivers that operate services where ease of use and compatibility with existing email flows is a priority.
接收者有时需要发送不符合任何标准或协议，但最终用户需要的电子邮件。减轻DMARC对间接电子邮件流的影响对于运营服务的接收者来说尤其重要，在这些服务中，易用性和与现有电子邮件流的兼容性是一个优先事项。
DMARC provides a mechanism (local policy) for receivers to make decisions about identity alignment acceptability based on information outside DMARC and communicate those decisions as "overrides" to the sender. This facility can be used to ease some interoperability issues, although care is needed to ensure that this does not create loopholes for abuse.
DMARC为接收者提供了一种机制（本地策略），使其能够根据DMARC之外的信息做出关于身份对齐可接受性的决定，并将这些决定作为“覆盖”传达给发送者。此功能可用于缓解某些互操作性问题，但需要小心确保这不会造成滥用漏洞。
To further complicate the usage of mitigations, mitigation may not be desired if the email in question is of a certain category of high value or high risk (security-related) transactional messages (dealing with financial transactions or medical records, for example). In these cases, mitigating the impact of DMARC due to indirect email flows may not be desirable (counterproductive or allowing for abuse).
为了使缓解措施的使用更加复杂，如果所讨论的电子邮件属于某类高价值或高风险（安全相关）交易消息（例如，处理金融交易或医疗记录），则可能不需要缓解措施。在这些情况下，由于间接电子邮件流而减轻DMARC的影响可能是不可取的（适得其反或允许滥用）。
As a final note, mail systems are diverse and widely deployed. Systems of various ages and capabilities are expected to preserve interoperability with the rest of the SMTP ecosystem. For instance, Qmail is still used, although the base code has not been updated
最后，邮件系统多种多样，部署广泛。不同年龄和能力的系统有望保持与SMTP生态系统其余部分的互操作性。例如，Qmail仍在使用，尽管基本代码尚未更新
since 1998. ezmlm, a once popular MLM, is still deployed but has not been updated since 1997, although a new version (ezmlm-idx) exists. Old versions of other open- and closed-source MTAs are still commonly in operation. When dealing with aging or unsupported systems, some solutions may be time-consuming and/or disruptive to implement.
自1998年以来。ezmlm，一个曾经流行的传销，虽然有一个新版本（ezmlm idx），但仍在部署，但自1997年以来没有更新。其他开源和开源MTA的旧版本仍然在运行。在处理老化或不受支持的系统时，某些解决方案可能会耗时和/或中断实施。
Because DMARC is already widely deployed, many operators already have mitigations in use. These mitigations vary in their effectiveness and side effects but have the advantage that they are currently available.
由于DMARC已经广泛部署，许多运营商已经在使用缓解措施。这些缓解措施的有效性和副作用各不相同，但其优点是目前可用。
o MTAs handling multiple domains may choose to change RFC5321.MailFrom to align with RFC5322.From to improve SPF usability for DMARC.
o 处理多个域的MTA可以选择将RFC5321.MailFrom更改为与RFC5322.From对齐，以提高DMARC的SPF可用性。
o MTAs handling multiple domains may also choose to align RFC5321.HELO/.EHLO to RFC5322.From, particularly when sending notification messages. Dynamically adjusting the RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible for some MTA software.
o 处理多个域的MTA也可以选择将RFC5321.HELO/.EHLO与RFC5322.From对齐，尤其是在发送通知消息时。某些MTA软件可能无法基于RFC5322.From动态调整RFC5321.HELO/.EHLO。
o MTAs may choose to DKIM-sign notification messages with an aligned domain to allow a DKIM-based DMARC pass.
o MTA可以选择使用对齐的域对通知消息进行DKIM签名，以允许基于DKIM的DMARC传递。
o MTAs sending email on behalf of multiple domains may require Domain Owners to provide DKIM keys to use DKIM to avoid SPF validation issues, given the requirement for DMARC alignment with the RFC5322.From header field. Managing DKIM keys with a third party has security risks that should be carefully managed (see also [RFC6376], Section 8). Methods involving CNAMEs and/or subdomains may alleviate some risks.
o MTA代表多个域发送电子邮件可能要求域所有者提供DKIM密钥，以使用DKIM避免SPF验证问题，因为DMARC需要与RFC5322.From标头字段对齐。与第三方管理DKIM密钥存在安全风险，应谨慎管理（另请参见[RFC6376]第8节）。涉及CNAMEs和/或子域的方法可能会减轻一些风险。
o Senders who are sending on behalf of users in other administrative domains may choose to use an RFC5322.From under the sender's control. The new From can be either a forwarding address in a domain controlled by the Sender or a placeholder address, with the original user's address in an RFC5322.Reply-to header field. However, performing this modification may cause the Recipient's MUA to deviate from customary behavior.
o 代表其他管理域中的用户发送的发件人可以选择在发件人的控制下使用RFC5322。新发件人可以是发件人控制的域中的转发地址，也可以是占位符地址，原始用户地址位于RFC5322.Reply-to标头字段中。然而，执行此修改可能会导致接收者的MUA偏离习惯行为。
o When implementing "forward-to-friend" functionality, one approach to avoid DMARC failures is to pass a well-formed message to the user's MUA so that it may fill in an appropriate identity and submit through its own MSA.
o 在实现“转发给朋友”功能时，避免DMARC失败的一种方法是将格式良好的消息传递给用户的MUA，以便其可以填写适当的标识并通过自己的MSA提交。
o Senders can use domains with distinct DMARC policies for email sent directly and email known to use indirect mail flows. However, for most well-known brands, all active domains are likely to be targeted equally by abusers.
o 对于直接发送的电子邮件和已知使用间接邮件流的电子邮件，发件人可以使用具有不同DMARC策略的域。然而，对于大多数知名品牌而言，所有活跃域名都可能成为滥用者的平等目标。
o Senders can maximize survivability of DKIM signatures by limiting the header fields they sign and using relaxed canonicalization. Using the DKIM length tag to allow appended signatures is discouraged due to the security risk created by allowing arbitrary content to be appended to legitimate email.
o 发送方可以通过限制其签名的头字段并使用宽松的规范化来最大化DKIM签名的生存性。不鼓励使用DKIM长度标记来允许附加签名，因为允许将任意内容附加到合法电子邮件会带来安全风险。
o Senders can also maximize survivability by starting with RFC-compliant headers and common body formats.
o 发送方还可以从符合RFC的头文件和通用正文格式开始，最大限度地提高生存能力。
o In order to minimize transport-based conversions, Senders can convert messages to a lowest denominator MIME content-transfer encoding such as quoted-printable or base64 before signing ([RFC6376], Section 5.3).
o 为了尽量减少基于传输的转换，发件人可以在签名之前将消息转换为最小分母的MIME内容传输编码，如quoted printable或base64（[RFC6376]，第5.3节）。
o Receivers should update DKIM handling libraries to ensure that they process all valid DKIM signatures and check each signature for alignment.
o 接收者应更新DKIM处理库，以确保他们处理所有有效的DKIM签名，并检查每个签名是否对齐。
o Receivers can amalgamate data from their user base to create lists of forwarders and use such lists to inform DMARC local policy overrides. This process may be easier for large receivers where data and resources to create such lists are more readily available than at smaller sites, where there are fewer accounts that receive forwarded mail and other resources may be scarce.
o 接收者可以合并来自其用户群的数据，创建转发器列表，并使用此类列表通知DMARC本地策略覆盖。对于大型接收者来说，这一过程可能更容易，因为创建此类列表的数据和资源比小型站点更容易获得，因为小型站点接收转发邮件的帐户较少，而其他资源可能很少。
Many ReSender issues can be avoided by using an RFC5322.From header field under the ReSender's control, instead of the initial RFC5322.From. This will correct Identifier Alignment issues and allow arbitrary message modification as long as the ReSender signs the message with an aligned domain signature. When ReSenders change the RFC5322.From, it is desirable to preserve the information about the original initiator of the message.
通过使用重发器控制下的RFC5322.From报头字段，而不是初始的RFC5322.From，可以避免许多重发问题。这将纠正标识符对齐问题，并允许任意修改消息，只要重新发送者使用对齐的域签名对消息进行签名。当重新发送更改RFC5322.From时，需要保留有关消息原始发起方的信息。
A first option is to use the Original-From [RFC5703] (or X-Original-From) header field for this purpose in various contexts (X- header field names are discouraged by [RFC6648]). However, handling of Original-From (or X-Original-From) is not defined anywhere. It is not currently used consistently or displayed to the user, and in any situation where it is used, it is a new unauthenticated identifier available for exploitation unless included within the scope of the new DKIM signature(s).
第一个选项是在各种上下文中使用原始发件人[RFC5703]（或X-Original-From）头字段用于此目的（X-头字段名称不受[RFC6648]的鼓励）。但是，任何地方都没有定义原始来源（或X原始来源）的处理。它当前未被一致使用或显示给用户，并且在使用它的任何情况下，它是一个新的未经验证的标识符，可供利用，除非包含在新DKIM签名的范围内。
Another option for ReSenders is to rewrite the RFC5322.From header field address to a locally controlled address that will be forwarded back to the original sender (subject to its own ReSender forwarding mitigations).
重发的另一个选项是将RFC5322.从报头字段地址重写为本地控制的地址，该地址将转发回原始发送方（取决于其自身的重发转发缓解措施）。
o Forwarders can choose to add email header fields instead of modifying existing headers or bodies, for instance, to indicate a message may be spam.
o 例如，转发器可以选择添加电子邮件标题字段，而不是修改现有的标题或正文，以指示邮件可能是垃圾邮件。
o Forwarders can minimize the circumstances in which they choose to fix messages, preferring to preserve non-compliant headers to creating DKIM failures.
o 转发器可以最大限度地减少选择修复邮件的情况，宁愿保留不符合要求的头，也不愿创建DKIM故障。
o Forwarders can choose to reject messages with suspect or harmful content instead of modifying them.
o 转发器可以选择拒绝包含可疑或有害内容的邮件，而不是修改它们。
[RFC6377] provides some guidance on using DKIM with Mailing lists. The following mitigation techniques can be used to ease interoperability issues with DMARC and Mailing lists:
[RFC6377]提供了有关将DKIM与邮件列表一起使用的一些指导。以下缓解技术可用于缓解DMARC和邮件列表的互操作性问题：
o Configuring the Mailing List Manager (MLM) to alter the RFC5322.From header field to use the domain of the MLM is a mitigation policy that is now present in several different Mailing
o 配置邮件列表管理器（MLM）以更改RFC5322.From标头字段以使用MLM的域是一种缓解策略，目前存在于多个不同的邮件列表中
List software distributions. Since most list subscribers prefer to know the identity of the Author of the original message, typically this information may be provided in the display name part of the RFC5322.From header field. This display name needs to be carefully crafted so as to not collide with the original display name of the Author, nor contain something that looks like an email address or domain name. These modifications may to some extent defeat the purpose of DMARC itself. It may make it difficult to ensure that users of all email clients can easily reply to the Author, the list, or all using the email client features provided for that purpose. Use of the RFC5322.Reply-To header field can alleviate this problem depending on whether the Mailing List is configured to reply-to-list, reply-to-author, or reply-to-fixed-address; however, it is important to note that this header field can take multiple email addresses. When altering the RFC5322.From, there are three possibilities:
列出软件发行版。由于大多数列表订阅者希望知道原始消息作者的身份，因此通常可以在RFC5322.From标头字段的显示名称部分提供此信息。此显示名需要精心编制，以避免与作者的原始显示名冲突，也不会包含类似电子邮件地址或域名的内容。这些修改可能在某种程度上违背DMARC本身的目的。这可能会导致难以确保所有电子邮件客户端的用户都可以使用为此目的提供的电子邮件客户端功能轻松回复作者、列表或所有用户。根据邮件列表是否配置为回复列表、回复作者或回复固定地址，使用RFC5322.Reply-To-header字段可以缓解此问题；但是，需要注意的是，此标题字段可以包含多个电子邮件地址。从更改RFC5322.时，有三种可能性：
1. change it to put the Mailing List email address,
1. 将其更改为放置邮件列表电子邮件地址，
2. change it to a locally defined address that will be forwarded back to the original sender, or
2. 将其更改为本地定义的地址，该地址将转发回原始发件人，或
3. "break" the address by modifying the domain to a non-existent domain (such as by adding a suffix like ".invalid").
3. 通过将域修改为不存在的域（例如添加后缀“.invalid”）来“断开”地址。
The latter modification may create issues because it is an invalid domain name, and some MTAs may pay particular attention to the validity of email addresses in RFC5322.From and the reputation of the domains present there.
后一种修改可能会产生问题，因为它是一个无效的域名，一些MTA可能会特别注意RFC5322.From中电子邮件地址的有效性以及存在于其中的域的信誉。
o Configuring the MLM to "wrap" the message in a MIME message/rfc822 part and to send as the Mailing List email address. Many email clients (as of the publication of this document), especially mobile clients, have difficulty reading such messages, and this is not expected to change soon.
o 将传销配置为在MIME消息/rfc822部分中“包装”消息，并作为邮件列表电子邮件地址发送。许多电子邮件客户端（截至本文档发布之日），尤其是移动客户端，阅读此类邮件有困难，预计不会很快改变。
o Configuring the MLM to not modify the message so that the DKIM signature remains valid. Some Mailing Lists are set up this way and require few additional changes to ensure the DKIM signature is preserved. Moving lists that currently modify mail to a policy like this may be too much of a change for the members of such lists.
o 将MLM配置为不修改消息，以便DKIM签名保持有效。有些邮件列表是这样设置的，需要很少的额外更改以确保保留DKIM签名。将当前修改邮件的列表移动到这样的策略中可能会对此类列表的成员造成太大的更改。
o Rejecting posts or membership requests from domains with a DMARC policy other than "p=none". However, members or potential members of such Mailing Lists may complain of unfair exclusion.
o 拒绝来自DMARC策略为“p=none”以外的域的帖子或成员资格请求。但是，此类邮件列表的成员或潜在成员可能会抱怨不公平的排除。
o To alleviate unsubscribes to the Mailing List due to the messages bouncing because of DMARC, the MLM needs to not act on notification messages due to message authentication issues. [RFC3463] specifies Enhanced Mail System Status Codes, which help differentiate between various failure conditions. Correctly interpreting Extended SMTP error messages is useful in this case. In particular, extended status codes for SPF and DKIM causes are defined in [RFC7372], and DMARC-related failure indications are discussed in DMARC ([RFC7489], Section 10.3).
o 为了缓解由于DMARC导致的邮件反弹而导致的邮件列表取消订阅，传销需要不对由于邮件身份验证问题而发出的通知邮件采取行动。[RFC3463]指定增强的邮件系统状态代码，这有助于区分各种故障情况。在这种情况下，正确解释扩展SMTP错误消息非常有用。具体而言，[RFC7372]中定义了SPF和DKIM原因的扩展状态代码，DMARC（[RFC7489]第10.3节）中讨论了与DMARC相关的故障指示。
All these techniques may provide some specific challenges to MUAs and different operational usages for end users (like rewriting filters to sort emails in folders). There will be some time before all implications are understood and accommodated.
所有这些技术可能会给MUA带来一些特定的挑战，并为最终用户提供不同的操作用途（如重写过滤器以对文件夹中的电子邮件进行排序）。在理解和适应所有影响之前，还有一段时间。
The following mitigations are based on Internet-Drafts (I-Ds) that are still in process. They are described here to offer an exploratory path for solutions. These solutions should not be used in a production environment. Because of the transient nature of I-Ds, specific citations are not included because a number of them will inevitably become obsolete, and those that gain consensus in the community will become RFCs and should be discovered as such.
以下缓解措施基于仍在进行中的互联网草案（I-D）。这里描述它们是为了提供解决方案的探索路径。这些解决方案不应在生产环境中使用。由于I-D的暂时性，不包括具体的引用，因为其中一些引用将不可避免地过时，而那些在社区中获得共识的引用将成为RFC，因此应该被发现。
o Third-party authorization schemes provide ways to extend Identifier Alignment under control of the Domain Owner.
o 第三方授权方案提供了在域所有者控制下扩展标识符对齐的方法。
o Ways to canonicalize messages that transit Mailing Lists so that their alterations can be isolated from the original signed content.
o 将传输邮件列表的邮件规范化的方法，以便将其更改与原始签名内容隔离开来。
o Mechanisms to record message transformations applied at each hop so they can be reversed and the original signed content recovered.
o 记录每个跃点上应用的消息转换的机制，以便可以反转这些转换并恢复原始签名内容。
o "Conditional" DKIM signatures, whereby the Author domain indicates its signature is only good if accompanied by a signature from an expected downstream relay.
o “有条件”DKIM签名，其中作者域仅在伴随来自预期下游中继的签名时指示其签名是好的。
o Mechanisms to extend Authentication-Results [RFC7601] to multiple hops, creating a provable chain of custody as well as a view of message authentication results at each handling step.
o 将身份验证结果[RFC7601]扩展到多个跃点的机制，创建可证明的保管链以及每个处理步骤的消息身份验证结果视图。
4.2.1. Getting More Radical: Requiring New Communication Paths between MUAs
4.2.1. 变得更激进：需要MUA之间的新通信路径
In practice, a number of operators are using strict alignment mode in DMARC in order to avoid receiving new and innovative forms of unwanted and unauthentic email through systems purporting to be Mailing List handlers. The receiving ADMD has no knowledge of which lists the user has subscribed to and which they have not. One avenue of exploration would be for the user to authorize Mailing Lists as proxies for authentication, at which point the receiving ADMD would be vesting some trust in the Mailing List service. The creators of DKIM foresaw precisely this possibility at the time by not tightly binding any semantics to the RFC5322.From header field. Some experimental work has taken place in this area, as mentioned above. Additional work might examine a new communication path to the user to authorize some form of transitive trust.
实际上，许多运营商在DMARC中使用严格的对齐模式，以避免通过声称是邮件列表处理程序的系统接收新的和创新的形式的不需要的和不真实的电子邮件。接收ADMD不知道用户已订阅和未订阅的列表。一种探索途径是用户授权邮件列表作为身份验证的代理，此时接收ADMD将授予邮件列表服务某种信任。DKIM的创建者当时没有将任何语义紧密绑定到RFC5322.From头字段，因此准确地预见到了这种可能性。如上所述，在这方面进行了一些实验工作。额外的工作可能会检查用户的新通信路径，以授权某种形式的可传递信任。
This document is an analysis of DMARC's impact on indirect email flows. It describes the possibility of accidental denial of service that can be created by rejections of messages by DMARC-aware mail receivers.
本文档分析了DMARC对间接电子邮件流的影响。它描述了DMARC感知邮件接收者拒绝邮件可能造成的意外拒绝服务的可能性。
Section 4.1.1.1 discusses the importance of appropriate DKIM key management vis-a-vis third-party email senders.
第4.1.1.1节讨论了针对第三方电子邮件发件人的适当DKIM密钥管理的重要性。
Section 4.1.3.3 warns that rewriting the RFC5322.From header field to create an artificial domain name should not be done with any domain.
第4.1.3.3节警告，不应在任何域中重写RFC5322.From标头字段以创建人工域名。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 2045，DOI 10.17487/RFC20451996年11月<http://www.rfc-editor.org/info/rfc2045>.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, DOI 10.17487/RFC3463, January 2003, <http://www.rfc-editor.org/info/rfc3463>.
[RFC3463]Vaudreuil，G.，“增强邮件系统状态代码”，RFC 3463，DOI 10.17487/RFC3463，2003年1月<http://www.rfc-editor.org/info/rfc3463>.
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, January 2008, <http://www.rfc-editor.org/info/rfc5228>.
[RFC5228]Guenther，P.，Ed.和T.Showalter，Ed.，“筛选：电子邮件过滤语言”，RFC 5228，DOI 10.17487/RFC5228，2008年1月<http://www.rfc-editor.org/info/rfc5228>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<http://www.rfc-editor.org/info/rfc5322>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC 5598，DOI 10.17487/RFC5598，2009年7月<http://www.rfc-editor.org/info/rfc5598>.
[RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure", RFC 5703, DOI 10.17487/RFC5703, October 2009, <http://www.rfc-editor.org/info/rfc5703>.
[RFC5703]Hansen，T.和C.Daboo，“筛选电子邮件过滤：MIME部分测试、迭代、提取、替换和封装”，RFC 5703，DOI 10.17487/RFC5703，2009年10月<http://www.rfc-editor.org/info/rfc5703>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <http://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<http://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, September 2011, <http://www.rfc-editor.org/info/rfc6377>.
[RFC6377]Kucherawy，M.，“域密钥识别邮件（DKIM）和邮件列表”，BCP 167，RFC 6377，DOI 10.17487/RFC6377，2011年9月<http://www.rfc-editor.org/info/rfc6377>.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, <http://www.rfc-editor.org/info/rfc6648>.
[RFC6648]圣安德烈，P.，克罗克，D.，和M.诺丁汉，“反对应用协议中的“X-”前缀和类似结构”，BCP 178，RFC 6648，DOI 10.17487/RFC6648，2012年6月<http://www.rfc-editor.org/info/rfc6648>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <http://www.rfc-editor.org/info/rfc7208>.
[RFC7208]Kitterman，S.，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 7208，DOI 10.17487/RFC7208，2014年4月<http://www.rfc-editor.org/info/rfc7208>.
[RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC 7372, DOI 10.17487/RFC7372, September 2014, <http://www.rfc-editor.org/info/rfc7372>.
[RFC7372]Kucherawy，M.，“电子邮件身份验证状态代码”，RFC 7372，DOI 10.17487/RFC7372，2014年9月<http://www.rfc-editor.org/info/rfc7372>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <http://www.rfc-editor.org/info/rfc7489>.
[RFC7489]Kucherawy，M.，Ed.和E.Zwicky，Ed.，“基于域的消息验证、报告和一致性（DMARC）”，RFC 7489，DOI 10.17487/RFC7489，2015年3月<http://www.rfc-editor.org/info/rfc7489>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015, <http://www.rfc-editor.org/info/rfc7601>.
[RFC7601]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 7601，DOI 10.17487/RFC7601，2015年8月<http://www.rfc-editor.org/info/rfc7601>.
This example illustrates a notification message "bounce".
此示例演示了一条通知消息“bounce”。
Here is the message as it exits the Origin MTA (segv.d1.example):
以下是退出原始MTA时的消息（segv.d1.example）：
Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org
Subject: Example 1
Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org
Subject: Example 1
Hey gang, This is a test message. --J.
嘿，伙计们，这是一条测试信息--J
When dmarc.org rejects the message without a DKIM signature, it specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local, which has no SPF record. dmarc.org has a reject policy in place for such non-passing cases. Since there is no DKIM signature on the notification message, the failed SPF lookup results in a dmarc=fail, and d1.example could be expected to discard the notification message itself:
当dmarc.org拒绝没有DKIM签名的消息时，它将RFC5321.HELO/.EHLO域指定为dmarc.org.local，该域没有SPF记录。dmarc.org为此类不合格案例制定了拒绝政策。由于通知消息上没有DKIM签名，失败的SPF查找将导致dmarc=fail，d1.example可能会放弃通知消息本身：
Return-Path: <>
Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1])
by mx.d1.example with ESMTPS id Lkm25302jJR5
for <jqd@d1.example>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 14 Jan 2015 15:00:24 -0800 (PST)
Authentication-Results: mx.d1.example;
spf=none (d1.example: dmarc.org.local does not designate
permitted sender hosts) smtp.mail=;
dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org
MIME-Version: 1.0
Received: from segv.d1.example (segv.d1.example [198.51.100.1])
by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu,
14 Jan 2015 15:00:24 -0800 (PST)
From: Mail Delivery Subsystem <mailer-daemon@dmarc.org>
To: jqd@d1.example
Subject: Delivery Status Notification (Failure)
Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org>
Date: Thu, 14 Jan 2016 23:00:24 +0000
Content-Type: text/plain; charset=UTF-8
Return-Path: <>
Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1])
by mx.d1.example with ESMTPS id Lkm25302jJR5
for <jqd@d1.example>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 14 Jan 2015 15:00:24 -0800 (PST)
Authentication-Results: mx.d1.example;
spf=none (d1.example: dmarc.org.local does not designate
permitted sender hosts) smtp.mail=;
dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org
MIME-Version: 1.0
Received: from segv.d1.example (segv.d1.example [198.51.100.1])
by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu,
14 Jan 2015 15:00:24 -0800 (PST)
From: Mail Delivery Subsystem <mailer-daemon@dmarc.org>
To: jqd@d1.example
Subject: Delivery Status Notification (Failure)
Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org>
Date: Thu, 14 Jan 2016 23:00:24 +0000
Content-Type: text/plain; charset=UTF-8
This is an automatically generated Delivery Status Notification
这是自动生成的传递状态通知
Delivery to the following recipient failed permanently:
向以下收件人的传递永久失败：
no-recipient@dmarc.org
没有-recipient@dmarc.org
Technical details of permanent failure: Your message was rejected by the server for the recipient domain dmarc.org by mail.dmarc.org [192.0.2.1].
永久性失败的技术详细信息：您的邮件被mail.dmarc.org[192.0.2.1]拒绝，收件人域为dmarc.org。
The error that the other server returned was:
550 5.1.1 <no-recipient@dmarc.org>... User unknown
The error that the other server returned was:
550 5.1.1 <no-recipient@dmarc.org>... User unknown
----- Original message -----
Return-Path: <jqd@d1.example>
Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com
[203.252.0.131]) (authenticated bits=0)
----- Original message -----
Return-Path: <jqd@d1.example>
Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com
[203.252.0.131]) (authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org
Subject: Example 1
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org
Subject: Example 1
Hey gang, This is a test message. --J.
嘿，伙计们，这是一条测试信息--J
Acknowledgments
致谢
Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Rolf E. Sonneveld, Tim Draegen, and Franck Martin contributed to the IETF DMARC Working Group's wiki page listing all known interoperability issues with DMARC and indirect email flows.
Miles Fidelman、John Levine、David Crocker、Stephen J.Turnbull、Rolf E.Sonneveld、Tim Draegen和Franck Martin参与了IETF DMARC工作组的wiki页面，列出了DMARC和间接电子邮件流的所有已知互操作性问题。
Tim Draegen created the first draft of this document from these contributions and by ham-fistedly mapping contributions into the language of [RFC5598].
Tim Draegen根据这些贡献创建了本文件的初稿，并将贡献巧妙地映射为[RFC5598]语言。
Authors' Addresses
作者地址
Franck Martin (editor) LinkedIn Mountain View, CA United States of America
Franck Martin（编辑）美国加利福尼亚州LinkedIn Mountain View
Email: fmartin@linkedin.com
Email: fmartin@linkedin.com
Eliot Lear (editor) Cisco Systems GmbH Richtistrasse 7 Wallisellen, ZH CH-8304 Switzerland
Eliot Lear（编辑）思科系统股份有限公司Richtistrasse 7 Wallisellen，ZH CH-8304瑞士
Phone: +41 44 878 9200
Email: lear@cisco.com
Phone: +41 44 878 9200
Email: lear@cisco.com
Tim Draegen (editor) dmarcian, inc. PO Box 1007 Brevard, NC 28712 United States of America
蒂姆·德雷根（编辑）美国北卡罗来纳州布雷瓦德市德马西安公司邮政信箱1007号，邮编：28712
Email: tim@dmarcian.com
Email: tim@dmarcian.com
Elizabeth Zwicky (editor) Yahoo Sunnyvale, CA United States of America
Elizabeth Zwicky（编辑）Yahoo Sunnyvale，加利福尼亚州，美利坚合众国
Email: zwicky@yahoo-inc.com
Email: zwicky@yahoo-inc.com
Kurt Andersen (editor) LinkedIn 2029 Stierlin Court Mountain View, CA 94043 United States of America
库尔特·安德森（编辑）LinkedIn 2029 Stierlin Court Mountain View，加利福尼亚州94043，美利坚合众国
Email: kandersen@linkedin.com
Email: kandersen@linkedin.com