Independent Submission M. Kucherawy, Ed.
Request for Comments: 7489
Category: Informational E. Zwicky, Ed.
ISSN: 2070-1721 Yahoo!
March 2015
Independent Submission M. Kucherawy, Ed.
Request for Comments: 7489
Category: Informational E. Zwicky, Ed.
ISSN: 2070-1721 Yahoo!
March 2015
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
基于域的消息身份验证、报告和一致性（DMARC）
Abstract
摘要
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.
基于域的邮件验证、报告和一致性（DMARC）是一种可扩展的机制，通过该机制，邮件发起组织可以表示邮件验证、处置和报告的域级策略和首选项，邮件接收组织可以使用这些策略和首选项来改进邮件处理。
Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.
Internet邮件的发起者需要能够将可靠且经过身份验证的域标识符与邮件相关联，交流有关使用这些标识符的邮件的策略，并报告使用这些标识符的邮件。这些能力有几个好处：接收者可以向域名所有者提供有关其域名使用情况的反馈；此反馈可提供有关内部运营管理和外部域名滥用情况的宝贵见解。
DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.
DMARC不会产生或鼓励提高已验证电子邮件的传递权限。DMARC是一种策略分发机制，它支持越来越严格地处理未通过身份验证检查的消息，从不执行任何操作、更改传递到消息拒绝。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7489.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7489.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements ....................................................5
2.1. High-Level Goals ...........................................5
2.2. Out of Scope ...............................................6
2.3. Scalability ................................................6
2.4. Anti-Phishing ..............................................7
3. Terminology and Definitions .....................................7
3.1. Identifier Alignment .......................................8
3.2. Organizational Domain .....................................11
4. Overview .......................................................12
4.1. Authentication Mechanisms .................................12
4.2. Key Concepts ..............................................12
4.3. Flow Diagram ..............................................13
5. Use of RFC5322.From ............................................15
6. Policy .........................................................15
6.1. DMARC Policy Record .......................................16
6.2. DMARC URIs ................................................16
6.3. General Record Format .....................................17
6.4. Formal Definition .........................................21
6.5. Domain Owner Actions ......................................22
6.6. Mail Receiver Actions .....................................23
6.7. Policy Enforcement Considerations .........................27
7. DMARC Feedback .................................................28
7.1. Verifying External Destinations ...........................28
7.2. Aggregate Reports .........................................30
7.3. Failure Reports ...........................................36
8. Minimum Implementations ........................................37
9. Privacy Considerations .........................................38
9.1. Data Exposure Considerations ..............................38
9.2. Report Recipients .........................................39
1. Introduction ....................................................3
2. Requirements ....................................................5
2.1. High-Level Goals ...........................................5
2.2. Out of Scope ...............................................6
2.3. Scalability ................................................6
2.4. Anti-Phishing ..............................................7
3. Terminology and Definitions .....................................7
3.1. Identifier Alignment .......................................8
3.2. Organizational Domain .....................................11
4. Overview .......................................................12
4.1. Authentication Mechanisms .................................12
4.2. Key Concepts ..............................................12
4.3. Flow Diagram ..............................................13
5. Use of RFC5322.From ............................................15
6. Policy .........................................................15
6.1. DMARC Policy Record .......................................16
6.2. DMARC URIs ................................................16
6.3. General Record Format .....................................17
6.4. Formal Definition .........................................21
6.5. Domain Owner Actions ......................................22
6.6. Mail Receiver Actions .....................................23
6.7. Policy Enforcement Considerations .........................27
7. DMARC Feedback .................................................28
7.1. Verifying External Destinations ...........................28
7.2. Aggregate Reports .........................................30
7.3. Failure Reports ...........................................36
8. Minimum Implementations ........................................37
9. Privacy Considerations .........................................38
9.1. Data Exposure Considerations ..............................38
9.2. Report Recipients .........................................39
10. Other Topics ..................................................39
10.1. Issues Specific to SPF ...................................39
10.2. DNS Load and Caching .....................................40
10.3. Rejecting Messages .......................................40
10.4. Identifier Alignment Considerations ......................41
10.5. Interoperability Issues ..................................41
11. IANA Considerations ...........................................42
11.1. Authentication-Results Method Registry Update ............42
11.2. Authentication-Results Result Registry Update ............42
11.3. Feedback Report Header Fields Registry Update ............44
11.4. DMARC Tag Registry .......................................44
11.5. DMARC Report Format Registry .............................45
12. Security Considerations .......................................46
12.1. Authentication Methods ...................................46
12.2. Attacks on Reporting URIs ................................46
12.3. DNS Security .............................................47
12.4. Display Name Attacks .....................................47
12.5. External Reporting Addresses .............................48
12.6. Secure Protocols .........................................48
13. References ....................................................49
13.1. Normative References .....................................49
13.2. Informative References ...................................50
Appendix A. Technology Considerations .............................52
A.1. S/MIME .....................................................52
A.2. Method Exclusion ...........................................53
A.3. Sender Header Field ........................................53
A.4. Domain Existence Test ......................................54
A.5. Issues with ADSP in Operation ..............................54
A.6. Organizational Domain Discovery Issues .....................55
Appendix B. Examples ..............................................56
B.1. Identifier Alignment Examples ..............................56
B.2. Domain Owner Example .......................................58
B.3. Mail Receiver Example .....................................63
B.4. Utilization of Aggregate Feedback: Example .................64
B.5. mailto Transport Example ...................................65
Appendix C. DMARC XML Schema ......................................66
Acknowledgements ..................................................73
Authors' Addresses ................................................73
10. Other Topics ..................................................39
10.1. Issues Specific to SPF ...................................39
10.2. DNS Load and Caching .....................................40
10.3. Rejecting Messages .......................................40
10.4. Identifier Alignment Considerations ......................41
10.5. Interoperability Issues ..................................41
11. IANA Considerations ...........................................42
11.1. Authentication-Results Method Registry Update ............42
11.2. Authentication-Results Result Registry Update ............42
11.3. Feedback Report Header Fields Registry Update ............44
11.4. DMARC Tag Registry .......................................44
11.5. DMARC Report Format Registry .............................45
12. Security Considerations .......................................46
12.1. Authentication Methods ...................................46
12.2. Attacks on Reporting URIs ................................46
12.3. DNS Security .............................................47
12.4. Display Name Attacks .....................................47
12.5. External Reporting Addresses .............................48
12.6. Secure Protocols .........................................48
13. References ....................................................49
13.1. Normative References .....................................49
13.2. Informative References ...................................50
Appendix A. Technology Considerations .............................52
A.1. S/MIME .....................................................52
A.2. Method Exclusion ...........................................53
A.3. Sender Header Field ........................................53
A.4. Domain Existence Test ......................................54
A.5. Issues with ADSP in Operation ..............................54
A.6. Organizational Domain Discovery Issues .....................55
Appendix B. Examples ..............................................56
B.1. Identifier Alignment Examples ..............................56
B.2. Domain Owner Example .......................................58
B.3. Mail Receiver Example .....................................63
B.4. Utilization of Aggregate Feedback: Example .................64
B.5. mailto Transport Example ...................................65
Appendix C. DMARC XML Schema ......................................66
Acknowledgements ..................................................73
Authors' Addresses ................................................73
The Sender Policy Framework ([SPF]) and DomainKeys Identified Mail ([DKIM]) provide domain-level authentication. They enable cooperating email receivers to detect mail authorized to use the domain name, which can permit differential handling. (A detailed discussion of the threats these systems attempt to address can be found in [DKIM-THREATS].) However, there has been no single widely accepted or publicly available mechanism to communication of
发件人策略框架（[SPF]）和域密钥标识邮件（[DKIM]）提供域级身份验证。它们使合作的电子邮件接收者能够检测到授权使用域名的邮件，从而允许差异处理。（关于这些系统试图解决的威胁的详细讨论，请参见[DKIM-threats]）然而，目前还没有一个被广泛接受或公开的机制来进行信息交流
domain-specific message-handling policies for receivers, or to request reporting of authentication and disposition of received mail. Absent the ability to obtain feedback reports, originators who have implemented email authentication have difficulty determining how effective their authentication is. As a consequence, use of authentication failures to filter mail typically does not succeed.
收件人的特定于域的邮件处理策略，或请求报告已接收邮件的身份验证和处置。由于无法获得反馈报告，实施电子邮件身份验证的发起人很难确定其身份验证的有效性。因此，使用身份验证失败来过滤邮件通常不会成功。
Over time, one-on-one relationships were established between select senders and receivers with privately communicated means to assert policy and receive message traffic and authentication disposition reporting. Although these ad hoc practices have been generally successful, they require significant manual coordination between parties, and this model does not scale for general use on the Internet.
随着时间的推移，在选定的发送者和接收者之间建立了一对一的关系，这些发送者和接收者通过私人通信的方式来维护策略，并接收消息流量和身份验证处理报告。虽然这些临时做法总体上是成功的，但它们需要缔约方之间进行大量的手动协调，而且这种模式无法在互联网上推广使用。
This document defines Domain-based Message Authentication, Reporting, and Conformance (DMARC), a mechanism by which email operators leverage existing authentication and policy advertisement technologies to enable both message-stream feedback and enforcement of policies against unauthenticated email.
本文档定义了基于域的消息身份验证、报告和一致性（DMARC），这是一种电子邮件运营商利用现有身份验证和策略公告技术实现消息流反馈和针对未经身份验证的电子邮件实施策略的机制。
DMARC allows Domain Owners and receivers to collaborate by:
DMARC允许域所有者和接收者通过以下方式进行协作：
1. Providing receivers with assertions about Domain Owners' policies
1. 为接收者提供关于域所有者策略的断言
2. Providing feedback to senders so they can monitor authentication and judge threats
2. 向发件人提供反馈，以便他们能够监控身份验证和判断威胁
The basic outline of DMARC is as follows:
DMARC的基本轮廓如下：
1. Domain Owners publish policy assertions about domains via the DNS.
1. 域所有者通过DNS发布关于域的策略断言。
2. Receivers compare the RFC5322.From address in the mail to the SPF and DKIM results, if present, and the DMARC policy in DNS.
2. 接收者将邮件中的RFC5322.From地址与SPF和DKIM结果（如果存在）以及DNS中的DMARC策略进行比较。
3. These receivers can use these results to determine how the mail should be handled.
3. 这些接收者可以使用这些结果来确定如何处理邮件。
4. The receiver sends reports to the Domain Owner or its designee about mail claiming to be from their domain.
4. 接收方向域所有者或其指定人员发送关于声称来自其域的邮件的报告。
Security terms used in this document are defined in [SEC-TERMS].
本文件中使用的安全术语在[SEC-terms]中定义。
DMARC differs from previous approaches to policy advertisement (e.g., [SPF] and [ADSP]) in that:
DMARC与以前的政策宣传方法（如[SPF]和[ADSP]）的不同之处在于：
o Authentication technologies are:
o 认证技术包括：
1. decoupled from any technology-specific policy mechanisms, and
1. 与任何特定于技术的政策机制脱钩，以及
2. used solely to establish reliable per-message domain-level identifiers.
2. 仅用于建立可靠的每消息域级标识符。
o Multiple authentication technologies are used to:
o 多种身份验证技术用于：
1. reduce the impact of transient authentication errors
1. 减少瞬时身份验证错误的影响
2. reduce the impact of site-specific configuration errors and deployment gaps
2. 减少特定于站点的配置错误和部署差距的影响
3. enable more use cases than any individual technology supports alone
3. 实现比任何单独的技术支持更多的用例
o Receiver-generated feedback is supported, allowing senders to establish confidence in authentication practices.
o 支持接收方生成的反馈，允许发送方建立对身份验证实践的信心。
o The domain name extracted from a message's RFC5322.From field is the primary identifier in the DMARC mechanism. This identifier is used in conjunction with the results of the underlying authentication technologies to evaluate results under DMARC.
o 从消息的RFC5322.from字段中提取的域名是DMARC机制中的主要标识符。该标识符与底层身份验证技术的结果结合使用，以评估DMARC下的结果。
Experience with DMARC has revealed some issues of interoperability with email in general that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 10.
DMARC的经验揭示了一些与电子邮件的互操作性问题，这些问题通常需要在部署之前进行适当考虑，特别是在可能导致邮件被拒绝的配置中。这些将在第10节中讨论。
Specification of DMARC is guided by the following high-level goals, security dependencies, detailed requirements, and items that are documented as out of scope.
DMARC的规范由以下高层目标、安全依赖性、详细需求和记录为超出范围的项目指导。
DMARC has the following high-level goals:
DMARC有以下高层目标：
o Allow Domain Owners to assert the preferred handling of authentication failures, for messages purporting to have authorship within the domain.
o 允许域所有者为声称在域内具有作者身份的消息声明身份验证失败的首选处理。
o Allow Domain Owners to verify their authentication deployment.
o 允许域所有者验证其身份验证部署。
o Minimize implementation complexity for both senders and receivers, as well as the impact on handling and delivery of legitimate messages.
o 最小化发送方和接收方的实现复杂性，以及对合法消息的处理和传递的影响。
o Reduce the amount of successfully delivered spoofed email.
o 减少成功发送的伪造电子邮件的数量。
o Work at Internet scale.
o 在互联网上工作。
Several topics and issues are specifically out of scope for the initial version of this work. These include the following:
有几个主题和问题特别超出了本工作初始版本的范围。这些措施包括：
o different treatment of messages that are not authenticated versus those that fail authentication;
o 对未通过身份验证的消息和未通过身份验证的消息的不同处理；
o evaluation of anything other than RFC5322.From;
o 对RFC5322以外的任何内容进行评估；
o multiple reporting formats;
o 多种报告格式；
o publishing policy other than via the DNS;
o 通过DNS以外的方式发布策略；
o reporting or otherwise evaluating other than the last-hop IP address;
o 报告或以其他方式评估非最后一跳IP地址；
o attacks in the RFC5322.From field, also known as "display name" attacks;
o 攻击发生在RFC5322.From字段，也称为“显示名称”攻击；
o authentication of entities other than domains, since DMARC is built upon SPF and DKIM, which authenticate domains; and
o 对域以外的实体进行身份验证，因为DMARC是基于SPF和DKIM构建的，后者对域进行身份验证；和
o content analysis.
o 内容分析。
Scalability is a major issue for systems that need to operate in a system as widely deployed as current SMTP email. For this reason, DMARC seeks to avoid the need for third parties or pre-sending agreements between senders and receivers. This preserves the positive aspects of the current email infrastructure.
对于需要在像当前SMTP电子邮件一样广泛部署的系统中运行的系统来说，可伸缩性是一个主要问题。因此，DMARC寻求避免发送方和接收方之间需要第三方或预发送协议。这保留了当前电子邮件基础结构的积极方面。
Although DMARC does not introduce third-party senders (namely external agents authorized to send on behalf of an operator) to the email-handling flow, it also does not preclude them. Such third parties are free to provide services in conjunction with DMARC.
虽然DMARC没有将第三方发件人（即授权代表运营商发送邮件的外部代理）引入电子邮件处理流程，但也没有排除他们。此类第三方可与DMARC一起免费提供服务。
DMARC is designed to prevent bad actors from sending mail that claims to come from legitimate senders, particularly senders of transactional email (official mail that is about business transactions). One of the primary uses of this kind of spoofed mail is phishing (enticing users to provide information by pretending to be the legitimate service requesting the information). Thus, DMARC is significantly informed by ongoing efforts to enact large-scale, Internet-wide anti-phishing measures.
DMARC旨在防止不良行为者发送声称来自合法发件人的邮件，特别是事务性电子邮件（涉及商业交易的官方邮件）的发件人。这种欺骗邮件的主要用途之一是网络钓鱼（通过假装是请求信息的合法服务来引诱用户提供信息）。因此，DMARC在制定大规模、互联网范围的反网络钓鱼措施的持续努力中获得了重要信息。
Although DMARC can only be used to combat specific forms of exact-domain spoofing directly, the DMARC mechanism has been found to be useful in the creation of reliable and defensible message streams.
虽然DMARC只能用于直接打击特定形式的精确域欺骗，但已发现DMARC机制在创建可靠且可防御的消息流方面非常有用。
DMARC does not attempt to solve all problems with spoofed or otherwise fraudulent email. In particular, it does not address the use of visually similar domain names ("cousin domains") or abuse of the RFC5322.From human-readable <display-name>.
DMARC不会试图解决伪造或欺诈电子邮件的所有问题。特别是，它没有解决视觉上相似的域名（“表亲域”）的使用或人类可读的<display name>中RFC5322.的滥用问题。
This section defines terms used in the rest of the document.
本节定义了文档其余部分中使用的术语。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Readers are encouraged to be familiar with the contents of [EMAIL-ARCH]. In particular, that document defines various roles in the messaging infrastructure that can appear the same or separate in various contexts. For example, a Domain Owner could, via the messaging security mechanisms on which DMARC is based, delegate the ability to send mail as the Domain Owner to a third party with another role. This document does not address the distinctions among such roles; the reader is encouraged to become familiar with that material before continuing.
鼓励读者熟悉[EMAIL-ARCH]的内容。特别是，该文档定义了消息传递基础结构中的各种角色，这些角色在不同的上下文中可以相同或不同。例如，域所有者可以通过DMARC所基于的消息传递安全机制，将作为域所有者发送邮件的能力委托给具有其他角色的第三方。本文件不涉及此类角色之间的区别；鼓励读者在继续之前熟悉该材料。
The following terms are also used:
还使用了以下术语：
Authenticated Identifiers: Domain-level identifiers that are validated using authentication technologies are referred to as "Authenticated Identifiers". See Section 4.1 for details about the supported mechanisms.
已验证标识符：使用验证技术验证的域级标识符称为“已验证标识符”。有关受支持机制的详细信息，请参见第4.1节。
Author Domain: The domain name of the apparent author, as extracted from the RFC5322.From field.
作者域：从RFC5322.from字段中提取的明显作者的域名。
Domain Owner: An entity or organization that owns a DNS domain. The term "owns" here indicates that the entity or organization being referenced holds the registration of that DNS domain. Domain Owners range from complex, globally distributed organizations, to service providers working on behalf of non-technical clients, to individuals responsible for maintaining personal domains. This specification uses this term as analogous to an Administrative Management Domain as defined in [EMAIL-ARCH]. It can also refer to delegates, such as Report Receivers, when those are outside of their immediate management domain.
域所有者：拥有DNS域的实体或组织。这里的术语“拥有”表示被引用的实体或组织拥有该DNS域的注册。域所有者的范围从复杂的、全球分布的组织到代表非技术客户工作的服务提供商，再到负责维护个人域的个人。本规范使用此术语类似于[EMAIL-ARCH]中定义的管理域。当代理不在其直接管理域内时，它也可以指代代理，例如报告接收者。
Identifier Alignment: When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier Alignment.
标识符对齐：当RFC5322.From地址中的域与SPF或DKIM（或两者）验证的域匹配时，它具有标识符对齐。
Mail Receiver: The entity or organization that receives and processes email. Mail Receivers operate one or more Internet-facing Mail Transport Agents (MTAs).
邮件接收者：接收和处理电子邮件的实体或组织。邮件接收者操作一个或多个面向Internet的邮件传输代理（MTA）。
Organizational Domain: The domain that was registered with a domain name registrar. In the absence of more accurate methods, heuristics are used to determine this, since it is not always the case that the registered domain name is simply a top-level DNS domain plus one component (e.g., "example.com", where "com" is a top-level domain). The Organizational Domain is determined by applying the algorithm found in Section 3.2.
组织域：向域名注册机构注册的域。在没有更准确的方法的情况下，使用启发式方法来确定这一点，因为注册域名并不总是简单地是顶级DNS域加上一个组件（例如，“example.com”，其中“com”是顶级域）。通过应用第3.2节中的算法确定组织领域。
Report Receiver: An operator that receives reports from another operator implementing the reporting mechanism described in this document. Such an operator might be receiving reports about its own messages, or reports about messages related to another operator. This term applies collectively to the system components that receive and process these reports and the organizations that operate them.
报告接收者：从实施本文件所述报告机制的另一运营商处接收报告的运营商。这样的操作员可能正在接收关于其自身消息的报告，或者关于与另一个操作员相关的消息的报告。本术语共同适用于接收和处理这些报告的系统组件以及运行这些报告的组织。
Email authentication technologies authenticate various (and disparate) aspects of an individual message. For example, [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] can authenticate either the domain that appears in the RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/ HELO domain, or both. These may be different domains, and they are typically not visible to the end user.
电子邮件身份验证技术对单个邮件的不同方面进行身份验证。例如，[DKIM]对在邮件上附加签名的域进行身份验证，而[SPF]可以对[SMTP]的RFC5321.MailFrom（MAIL FROM）部分或RFC5321.EHLO/HELO域中出现的域进行身份验证，或者两者都进行身份验证。这些可能是不同的域，最终用户通常看不到它们。
DMARC authenticates use of the RFC5322.From domain by requiring that it match (be aligned with) an Authenticated Identifier. The RFC5322.From domain was selected as the central identity of the DMARC
DMARC通过要求RFC5322.From域匹配（与）经过身份验证的标识符来验证其使用。已选择RFC5322.From域作为DMARC的中心标识
mechanism because it is a required message header field and therefore guaranteed to be present in compliant messages, and most Mail User Agents (MUAs) represent the RFC5322.From field as the originator of the message and render some or all of this header field's content to end users.
机制，因为它是必需的消息头字段，因此保证出现在符合要求的消息中，并且大多数邮件用户代理（MUA）将RFC5322.From字段表示为消息的发起人，并将此头字段的部分或全部内容呈现给最终用户。
Thus, this field is the one used by end users to identify the source of the message and therefore is a prime target for abuse. Many high-profile email sources, such as email service providers, require that the sending agent have authenticated before email can be generated. Thus, for these mailboxes, the mechanism described in this document provides recipient end users with strong evidence that the message was indeed originated by the agent they associate with that mailbox, if the end user knows that these various protections have been provided.
因此，该字段是最终用户用来识别消息来源的字段，因此是滥用的主要目标。许多引人注目的电子邮件源，如电子邮件服务提供商，要求发送代理在生成电子邮件之前进行身份验证。因此，对于这些邮箱，本文档中描述的机制为收件人最终用户提供了强有力的证据，证明邮件确实是由他们与该邮箱关联的代理发出的，前提是最终用户知道已经提供了这些不同的保护。
Domain names in this context are to be compared in a case-insensitive manner, per [DNS-CASE].
根据[DNS-case]，此上下文中的域名将以不区分大小写的方式进行比较。
It is important to note that Identifier Alignment cannot occur with a message that is not valid per [MAIL], particularly one with a malformed, absent, or repeated RFC5322.From field, since in that case there is no reliable way to determine a DMARC policy that applies to the message. Accordingly, DMARC operation is predicated on the input being a valid RFC5322 message object, and handling of such non-compliant cases is outside of the scope of this specification. Further discussion of this can be found in Section 6.6.1.
需要注意的是，标识符对齐不能与每[邮件]无效的消息一起发生，尤其是带有格式错误、缺失或重复的RFC5322.From字段的消息，因为在这种情况下，没有可靠的方法来确定应用于该消息的DMARC策略。因此，DMARC操作的前提是输入是有效的RFC5322消息对象，此类不符合情况的处理不在本规范的范围内。第6.6.1节对此进行了进一步讨论。
Each of the underlying authentication technologies that DMARC takes as input yields authenticated domains as their outputs when they succeed. From the perspective of DMARC, each can be operated in a "strict" mode or a "relaxed" mode. A Domain Owner would normally select strict mode if it wanted Mail Receivers to apply DMARC processing only to messages bearing an RFC5322.From domain exactly matching the domains those mechanisms will verify. Relaxed mode can be used when the operator also wishes to affect message flows bearing subdomains of the verified domains.
DMARC作为输入的每一种底层身份验证技术在成功时都会产生经过身份验证的域作为其输出。从DMARC的角度来看，每个都可以在“严格”模式或“放松”模式下操作。如果域所有者希望邮件接收者仅对承载RFC5322的邮件应用DMARC处理，则通常会选择严格模式。从域中，这些机制将验证与域完全匹配的邮件。当操作员还希望影响承载已验证域子域的消息流时，可以使用松弛模式。
DMARC permits Identifier Alignment, based on the result of a DKIM authentication, to be strict or relaxed. (Note that these are not related to DKIM's "simple" and "relaxed" canonicalization modes.)
DMARC允许基于DKIM身份验证的结果严格或放松标识符对齐。（请注意，这些与DKIM的“简单”和“轻松”规范化模式无关。）
In relaxed mode, the Organizational Domains of both the [DKIM]- authenticated signing domain (taken from the value of the "d=" tag in the signature) and that of the RFC5322.From domain must be equal if the identifiers are to be considered aligned. In strict mode, only an exact match between both of the Fully Qualified Domain Names (FQDNs) is considered to produce Identifier Alignment.
在放松模式下，[DKIM]-认证签名域（取自签名中“d=”标记的值）和RFC5322的组织域。如果要将标识符视为对齐，则from域的组织域必须相等。在严格模式下，只有两个完全限定域名（FQDN）之间的精确匹配才被视为产生标识符对齐。
To illustrate, in relaxed mode, if a validated DKIM signature successfully verifies with a "d=" domain of "example.com", and the RFC5322.From address is "alerts@news.example.com", the DKIM "d=" domain and the RFC5322.From domain are considered to be "in alignment". In strict mode, this test would fail, since the "d=" domain does not exactly match the FQDN of the address.
举例说明，在放松模式下，如果已验证的DKIM签名使用“example.com”的“d=”域成功验证，并且RFC5322.From地址为“alerts@news.example.com，则DKIM“d=”域和RFC5322.From域被视为“对齐”。在严格模式下，此测试将失败，因为“d=”域与地址的FQDN不完全匹配。
However, a DKIM signature bearing a value of "d=com" would never allow an "in alignment" result, as "com" should appear on all public suffix lists (see Appendix A.6.1) and therefore cannot be an Organizational Domain.
但是，值为“d=com”的DKIM签名绝不允许出现“对齐”结果，因为“com”应出现在所有公共后缀列表中（见附录a.6.1），因此不能成为组织域。
Identifier Alignment is required because a message can bear a valid signature from any domain, including domains used by a mailing list or even a bad actor. Therefore, merely bearing a valid signature is not enough to infer authenticity of the Author Domain.
标识符对齐是必需的，因为消息可以包含来自任何域的有效签名，包括邮件列表使用的域，甚至是坏参与者使用的域。因此，仅携带有效签名不足以推断作者域的真实性。
Note that a single email can contain multiple DKIM signatures, and it is considered to be a DMARC "pass" if any DKIM signature is aligned and verifies.
请注意，一封电子邮件可以包含多个DKIM签名，如果任何DKIM签名对齐并进行验证，则被视为DMARC“通过”。
DMARC permits Identifier Alignment, based on the result of an SPF authentication, to be strict or relaxed.
DMARC允许根据SPF身份验证的结果严格或放松标识符对齐。
In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment.
在放松模式下，[SPF]-已验证域和RFC5322.From域必须具有相同的组织域。在严格模式下，仅考虑精确的DNS域匹配来产生标识符对齐。
Note that the RFC5321.HELO identity is not typically used in the context of DMARC (except when required to "fake" an otherwise null reverse-path), even though a "pure SPF" implementation according to [SPF] would check that identifier.
请注意，RFC5321.HELO标识通常不在DMARC上下文中使用（除非需要“伪造”否则为空的反向路径），即使根据[SPF]的“纯SPF”实现将检查该标识符。
For example, if a message passes an SPF check with an RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address portion of the RFC5322.From field contains "payments@example.com", the Authenticated RFC5321.MailFrom domain identifier and the RFC5322.From domain are considered to be "in alignment" in relaxed mode, but not in strict mode.
例如，如果消息通过了SPF检查，且RFC5321.MailFrom域为“cbg.bounces.example.com”，且RFC5322.From字段的地址部分包含“payments@example.com，已验证的RFC5321.MailFrom域标识符和RFC5322.From域在放松模式下被视为“对齐”，但在严格模式下不被视为对齐。
If in the future DMARC is extended to include the use of other authentication mechanisms, the extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified.
如果将来扩展DMARC以包括使用其他身份验证机制，则扩展将需要允许提取域标识符，以便验证与RFC5322.From域的对齐。
The Organizational Domain is determined using the following algorithm:
使用以下算法确定组织域：
1. Acquire a "public suffix" list, i.e., a list of DNS domain names reserved for registrations. Some country Top-Level Domains (TLDs) make specific registration requirements, e.g., the United Kingdom places company registrations under ".co.uk"; other TLDs such as ".com" appear in the IANA registry of top-level DNS domains. A public suffix list is the union of all of these. Appendix A.6.1 contains some discussion about obtaining a public suffix list.
1. 获取“公共后缀”列表，即保留用于注册的DNS域名列表。一些国家顶级域名（TLD）制定了具体的注册要求，例如，英国将公司注册置于“.co.uk”项下；其他TLD（如“.com”）出现在顶级DNS域的IANA注册表中。公共后缀列表是所有这些的联合。附录A.6.1包含关于获取公共后缀列表的一些讨论。
2. Break the subject DNS domain name into a set of "n" ordered labels. Number these labels from right to left; e.g., for "example.com", "com" would be label 1 and "example" would be label 2.
2. 将主题DNS域名拆分为一组“n”有序标签。从右到左为这些标签编号；e、 例如，对于“example.com”，“com”将是标签1，“example”将是标签2。
3. Search the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x".
3. 在公共后缀列表中搜索与主题DNS域中找到的最大标签数匹配的名称。让那个数字为“x”。
4. Construct a new DNS domain name using the name that matched from the public suffix list and prefixing to it the "x+1"th label from the subject domain. This new name is the Organizational Domain.
4. 使用公共后缀列表中匹配的名称并在其前面加上主题域中的“x+1”标签，构造一个新的DNS域名。此新名称是组织域。
Thus, since "com" is an IANA-registered TLD, a subject domain of "a.b.c.d.example.com" would have an Organizational Domain of "example.com".
因此，由于“com”是IANA注册的TLD，“a.b.c.d.example.com”的主题域将具有“example.com”的组织域。
The process of determining a suffix is currently a heuristic one. No list is guaranteed to be accurate or current.
确定后缀的过程目前是一个启发式的过程。不保证列表是准确的或最新的。
This section provides a general overview of the design and operation of the DMARC environment.
本节概述了DMARC环境的设计和操作。
The following mechanisms for determining Authenticated Identifiers are supported in this version of DMARC:
此版本的DMARC支持以下用于确定已验证标识符的机制：
o [DKIM], which provides a domain-level identifier in the content of the "d=" tag of a validated DKIM-Signature header field.
o [DKIM]，它在已验证的DKIM签名头字段的“d=”标记的内容中提供域级标识符。
o [SPF], which can authenticate both the domain found in an [SMTP] HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the result of SPF authentication of the MAIL FROM identity. Section 2.4 of [SPF] describes MAIL FROM processing for cases in which the MAIL command has a null path.
o [SPF]，它可以对[SMTP]HELO/EHLO命令中的域（HELO标识）和SMTP邮件命令中的域（邮件发件人标识）进行身份验证。DMARC使用来自身份的邮件的SPF身份验证结果。[SPF]的第2.4节描述了MAIL命令具有空路径的情况下的邮件处理。
DMARC policies are published by the Domain Owner, and retrieved by the Mail Receiver during the SMTP session, via the DNS.
DMARC策略由域所有者发布，并由邮件接收者在SMTP会话期间通过DNS检索。
DMARC's filtering function is based on whether the RFC5322.From field domain is aligned with (matches) an authenticated domain name from SPF or DKIM. When a DMARC policy is published for the domain name found in the RFC5322.From field, and that domain name is not validated through SPF or DKIM, the disposition of that message can be affected by that DMARC policy when delivered to a participating receiver.
DMARC的过滤功能基于RFC5322.From字段域是否与SPF或DKIM中经过身份验证的域名对齐（匹配）。如果为RFC5322.From字段中的域名发布了DMARC策略，并且该域名未通过SPF或DKIM验证，则在将该DMARC策略传递给参与接收方时，该消息的处置可能会受到该DMARC策略的影响。
It is important to note that the authentication mechanisms employed by DMARC authenticate only a DNS domain and do not authenticate the local-part of any email address identifier found in a message, nor do they validate the legitimacy of message content.
需要注意的是，DMARC采用的身份验证机制仅对DNS域进行身份验证，不验证消息中任何电子邮件地址标识符的本地部分，也不验证消息内容的合法性。
DMARC's feedback component involves the collection of information about received messages claiming to be from the Organizational Domain for periodic aggregate reports to the Domain Owner. The parameters and format for such reports are discussed in later sections of this document.
DMARC的反馈组件涉及收集有关声称来自组织域的已接收消息的信息，以便定期向域所有者提交聚合报告。此类报告的参数和格式将在本文件后面的章节中讨论。
A DMARC-enabled Mail Receiver might also generate per-message reports that contain information related to individual messages that fail SPF and/or DKIM. Per-message failure reports are a useful source of information when debugging deployments (if messages can be determined
启用DMARC的邮件接收器还可能生成每封邮件报告，其中包含与SPF和/或DKIM失败的单个邮件相关的信息。在调试部署时（如果可以确定消息），每消息失败报告是一个有用的信息源
to be legitimate even though failing authentication) or in analyzing attacks. The capability for such services is enabled by DMARC but defined in other referenced material such as [AFRF].
即使身份验证失败也是合法的）或在分析攻击时。此类服务的能力由DMARC启用，但在[AFRF]等其他参考资料中定义。
A message satisfies the DMARC checks if at least one of the supported authentication mechanisms:
消息满足DMARC检查是否至少有一个受支持的身份验证机制：
1. produces a "pass" result, and
1. 生成“通过”结果，并且
2. produces that result based on an identifier that is in alignment, as defined in Section 3.
2. 根据第3节中定义的对齐标识符生成该结果。
+---------------+
| Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
+---------------+ . . .
| . . .
V V V .
+-----------+ +--------+ +----------+ +----------+ .
| MSA |<***>| DKIM | | DKIM | | SPF | .
| Service | | Signer | | Verifier | | Verifier | .
+-----------+ +--------+ +----------+ +----------+ .
| ^ ^ .
| ************** .
V * .
+------+ (~~~~~~~~~~~~) +------+ * .
| sMTA |------->( other MTAs )----->| rMTA | * .
+------+ (~~~~~~~~~~~~) +------+ * .
| * ........
| * .
V * .
+-----------+ V V
+---------+ | MDA | +----------+
| User |<--| Filtering |<***>| DMARC |
| Mailbox | | Engine | | Verifier |
+---------+ +-----------+ +----------+
+---------------+
| Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
+---------------+ . . .
| . . .
V V V .
+-----------+ +--------+ +----------+ +----------+ .
| MSA |<***>| DKIM | | DKIM | | SPF | .
| Service | | Signer | | Verifier | | Verifier | .
+-----------+ +--------+ +----------+ +----------+ .
| ^ ^ .
| ************** .
V * .
+------+ (~~~~~~~~~~~~) +------+ * .
| sMTA |------->( other MTAs )----->| rMTA | * .
+------+ (~~~~~~~~~~~~) +------+ * .
| * ........
| * .
V * .
+-----------+ V V
+---------+ | MDA | +----------+
| User |<--| Filtering |<***>| DMARC |
| Mailbox | | Engine | | Verifier |
+---------+ +-----------+ +----------+
MSA = Mail Submission Agent MDA = Mail Delivery Agent
MSA=邮件提交代理MDA=邮件传递代理
The above diagram shows a simple flow of messages through a DMARC-aware system. Solid lines denote the actual message flow, dotted lines involve DNS queries used to retrieve message policy related to the supported message authentication schemes, and asterisk lines indicate data exchange between message-handling modules and message authentication modules. "sMTA" is the sending MTA, and "rMTA" is the receiving MTA.
上图显示了通过DMARC感知系统的简单消息流。实线表示实际的消息流，虚线表示用于检索与支持的消息身份验证方案相关的消息策略的DNS查询，星号线表示消息处理模块和消息身份验证模块之间的数据交换。“sMTA”是发送MTA，“rMTA”是接收MTA。
In essence, the steps are as follows:
实质上，步骤如下：
1. Domain Owner constructs an SPF policy and publishes it in its DNS database as per [SPF]. Domain Owner also configures its system for DKIM signing as described in [DKIM]. Finally, Domain Owner publishes via the DNS a DMARC message-handling policy.
1. 域所有者构造一个SPF策略，并根据[SPF]在其DNS数据库中发布该策略。域所有者还按照[DKIM]中的说明为DKIM签名配置其系统。最后，域所有者通过DNS发布DMARC消息处理策略。
2. Author generates a message and hands the message to Domain Owner's designated mail submission service.
2. 作者生成一封邮件，并将邮件交给域所有者指定的邮件提交服务。
3. Submission service passes relevant details to the DKIM signing module in order to generate a DKIM signature to be applied to the message.
3. 提交服务将相关细节传递给DKIM签名模块，以便生成应用于消息的DKIM签名。
4. Submission service relays the now-signed message to its designated transport service for routing to its intended recipient(s).
4. 提交服务将现在已签名的邮件中继到其指定的传输服务，以便路由到其预期收件人。
5. Message may pass through other relays but eventually arrives at a recipient's transport service.
5. 消息可能会通过其他中继，但最终会到达收件人的传输服务。
6. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which requires queries to the Author Domain's DNS data (when identifiers are aligned; see below).
6. 收件人传递服务通过将必要的数据传递到各自的模块来执行SPF和DKIM身份验证检查，每个模块都需要查询作者域的DNS数据（当标识符对齐时；请参见下文）。
7. The results of these are passed to the DMARC module along with the Author's domain. The DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.)
7. 这些结果将与作者的域一起传递到DMARC模块。DMARC模块尝试从该域的DNS检索策略。如果未找到，DMARC模块将确定组织域并重复尝试从DNS检索策略。（详见第6.6.3节。）
8. If a policy is found, it is combined with the Author's domain and the SPF and DKIM results to produce a DMARC policy result (a "pass" or "fail") and can optionally cause one of two kinds of reports to be generated (not shown).
8. 如果找到策略，它将与作者的域、SPF和DKIM结果相结合，以生成DMARC策略结果（“通过”或“失败”），并且可以选择生成两种报告中的一种（未显示）。
9. Recipient transport service either delivers the message to the recipient inbox or takes other local policy action based on the DMARC result (not shown).
9. 收件人传输服务将邮件发送到收件人收件箱，或根据DMARC结果（未显示）采取其他本地策略操作。
10. When requested, Recipient transport service collects data from the message delivery session to be used in providing feedback (see Section 7).
10. 当收到请求时，收件人传输服务从邮件传递会话收集数据，用于提供反馈（请参见第7节）。
One of the most obvious points of security scrutiny for DMARC is the choice to focus on an identifier, namely the RFC5322.From address, which is part of a body of data that has been trivially forged throughout the history of email.
DMARC最明显的安全审查要点之一是选择关注标识符，即RFC5322.From地址，它是电子邮件历史上被伪造的数据体的一部分。
Several points suggest that it is the most correct and safest thing to do in this context:
有几点表明，在这种情况下，这是最正确和最安全的做法：
o Of all the identifiers that are part of the message itself, this is the only one guaranteed to be present.
o 在作为消息本身一部分的所有标识符中，这是唯一保证存在的标识符。
o It seems the best choice of an identifier on which to focus, as most MUAs display some or all of the contents of that field in a manner strongly suggesting those data as reflective of the true originator of the message.
o 它似乎是关注的标识符的最佳选择，因为大多数MUA显示该字段的部分或全部内容的方式强烈表明这些数据反映了消息的真正发起者。
The absence of a single, properly formed RFC5322.From field renders the message invalid. Handling of such a message is outside of the scope of this specification.
如果缺少一个格式正确的RFC5322.From字段，则消息无效。此类消息的处理超出了本规范的范围。
Since the sorts of mail typically protected by DMARC participants tend to only have single Authors, DMARC participants generally operate under a slightly restricted profile of RFC5322 with respect to the expected syntax of this field. See Section 6.6 for details.
由于DMARC参与者通常保护的邮件类型往往只有一个作者，因此DMARC参与者通常在RFC5322的略微受限的配置文件下操作，该配置文件与此字段的预期语法有关。详见第6.6节。
DMARC policies are published by Domain Owners and applied by Mail Receivers.
DMARC策略由域所有者发布，并由邮件接收者应用。
A Domain Owner advertises DMARC participation of one or more of its domains by adding a DNS TXT record (described in Section 6.1) to those domains. In doing so, Domain Owners make specific requests of Mail Receivers regarding the disposition of messages purporting to be from one of the Domain Owner's domains and the provision of feedback about those messages.
域所有者通过向一个或多个域添加DNS TXT记录（如第6.1节所述）来宣传其一个或多个域的DMARC参与。在此过程中，域所有者向邮件接收者提出特定请求，要求处理声称来自域所有者域之一的邮件，并提供有关这些邮件的反馈。
A Domain Owner may choose not to participate in DMARC evaluation by Mail Receivers. In this case, the Domain Owner simply declines to advertise participation in those schemes. For example, if the results of path authorization checks ought not be considered as part of the overall DMARC result for a given Author Domain, then the Domain Owner does not publish an SPF policy record that can produce an SPF pass result.
域所有者可以选择不通过邮件接收者参与DMARC评估。在这种情况下，域名所有者只是拒绝公布参与这些计划的情况。例如，如果路径授权检查的结果不应被视为给定作者域的整体DMARC结果的一部分，则域所有者不会发布可以生成SPF通过结果的SPF策略记录。
A Mail Receiver implementing the DMARC mechanism SHOULD make a best-effort attempt to adhere to the Domain Owner's published DMARC policy when a message fails the DMARC test. Since email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.), Mail Receivers MAY deviate from a Domain Owner's published policy during message processing and SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report (see Section 7.2).
当消息未通过DMARC测试时，实现DMARC机制的邮件接收方应尽最大努力遵守域所有者发布的DMARC策略。由于电子邮件流可能很复杂（由于转发、现有RFC5322、域欺骗服务等），邮件接收者在邮件处理过程中可能会偏离域所有者发布的策略，并应通过反馈报告向域所有者提供偏离的事实和原因，特别是使用聚合报告的“PolicyOverride”功能（见第7.2节）。
Domain Owner DMARC preferences are stored as DNS TXT records in subdomains named "_dmarc". For example, the Domain Owner of "example.com" would post DMARC preferences in a TXT record at "_dmarc.example.com". Similarly, a Mail Receiver wishing to query for DMARC preferences regarding mail with an RFC5322.From domain of "example.com" would issue a TXT query to the DNS for the subdomain of "_dmarc.example.com". The DNS-located DMARC preference data will hereafter be called the "DMARC record".
域所有者DMARC首选项作为DNS TXT记录存储在名为“\u DMARC”的子域中。例如，“example.com”的域所有者将在“_DMARC.example.com”的TXT记录中发布DMARC首选项。类似地，希望查询关于“example.com”的RFC5322.From域的邮件的DMARC首选项的邮件接收者将向DNS发出一个TXT查询，查询“\u DMARC.example.com”的子域。DNS定位的DMARC首选项数据将在下文中称为“DMARC记录”。
DMARC's use of the Domain Name Service is driven by DMARC's use of domain names and the nature of the query it performs. The query requirement matches with the DNS, for obtaining simple parametric information. It uses an established method of storing the information, associated with the target domain name, namely an isolated TXT record that is restricted to the DMARC context. Use of the DNS as the query service has the benefit of reusing an extremely well-established operations, administration, and management infrastructure, rather than creating a new one.
DMARC对域名服务的使用取决于DMARC对域名的使用及其执行的查询的性质。查询要求与DNS匹配，以获得简单的参数信息。它使用已建立的方法存储与目标域名相关的信息，即仅限于DMARC上下文的独立TXT记录。将DNS用作查询服务的好处是可以重用非常完善的操作、管理和管理基础架构，而不是创建新的基础架构。
Per [DNS], a TXT record can comprise several "character-string" objects. Where this is the case, the module performing DMARC evaluation MUST concatenate these strings by joining together the objects in order and parsing the result as a single string.
根据[DNS]，TXT记录可以包含多个“字符串”对象。在这种情况下，执行DMARC计算的模块必须通过按顺序将对象连接在一起并将结果解析为单个字符串来连接这些字符串。
[URI] defines a generic syntax for identifying a resource. The DMARC mechanism uses this as the format by which a Domain Owner specifies the destination for the two report types that are supported.
[URI]定义用于标识资源的通用语法。DMARC机制使用此格式作为域所有者指定支持的两种报告类型的目标的格式。
The place such URIs are specified (see Section 6.3) allows a list of these to be provided. A report is normally sent to each listed URI in the order provided by the Domain Owner. Receivers MAY impose a limit on the number of URIs to which they will send reports but MUST support the ability to send to at least two. The list of URIs is separated by commas (ASCII 0x2C).
指定此类URI的位置（见第6.3节）允许提供这些URI的列表。报告通常按照域所有者提供的顺序发送到每个列出的URI。接收者可以对其将向其中发送报告的URI的数量施加限制，但必须支持至少向两个URI发送报告的能力。URI列表用逗号分隔（ASCII 0x2C）。
Each URI can have associated with it a maximum report size that may be sent to it. This is accomplished by appending an exclamation point (ASCII 0x21), followed by a maximum-size indication, before a separating comma or terminating semicolon.
每个URI都可以有一个可以发送给它的最大报告大小。这是通过在分隔逗号或分号之前添加感叹号（ASCII 0x21），后跟最大大小指示来实现的。
Thus, a DMARC URI is a URI within which any commas or exclamation points are percent-encoded per [URI], followed by an OPTIONAL exclamation point and a maximum-size specification, and, if there are additional reporting URIs in the list, a comma and the next URI.
因此，DMARC URI是一个URI，其中任何逗号或感叹号均按[URI]进行百分比编码，后跟可选感叹号和最大大小规范，如果列表中有其他报告URI，则为逗号和下一个URI。
For example, the URI "mailto:reports@example.com!50m" would request that a report be sent via email to "reports@example.com" so long as the report payload does not exceed 50 megabytes.
例如，URI“mailto:reports@example.com！50m“将请求通过电子邮件将报告发送至”reports@example.com“只要报告有效负载不超过50 MB。
A formal definition is provided in Section 6.4.
第6.4节提供了正式定义。
DMARC records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [DKIM].
DMARC记录遵循DKIM[DKIM]中定义的基于DNS的密钥记录的可扩展“标记值”语法。
Section 11 creates a registry for known DMARC tags and registers the initial set defined in this document. Only tags defined in this document or in later extensions, and thus added to that registry, are to be processed; unknown tags MUST be ignored.
第11节为已知DMARC标记创建注册表，并注册本文档中定义的初始集。仅处理本文件或后续扩展中定义的标签，并因此添加到该注册表中；必须忽略未知标记。
The following tags are introduced as the initial valid DMARC tags:
引入以下标记作为初始有效的DMARC标记：
adkim: (plain-text; OPTIONAL; default is "r".) Indicates whether strict or relaxed DKIM Identifier Alignment mode is required by the Domain Owner. See Section 3.1.1 for details. Valid values are as follows:
adkim：（纯文本；可选；默认值为“r”。）指示域所有者是否需要严格或宽松的DKIM标识符对齐模式。详见第3.1.1节。有效值如下所示：
r: relaxed mode
r:放松模式
s: strict mode
s:严格模式
aspf: (plain-text; OPTIONAL; default is "r".) Indicates whether strict or relaxed SPF Identifier Alignment mode is required by the Domain Owner. See Section 3.1.2 for details. Valid values are as follows:
aspf：（纯文本；可选；默认值为“r”。）指示域所有者是否需要严格或宽松的SPF标识符对齐模式。详见第3.1.2节。有效值如下所示：
r: relaxed mode
r:放松模式
s: strict mode
s:严格模式
fo: Failure reporting options (plain-text; OPTIONAL; default is "0") Provides requested options for generation of failure reports. Report generators MAY choose to adhere to the requested options. This tag's content MUST be ignored if a "ruf" tag (below) is not also specified. The value of this tag is a colon-separated list of characters that indicate failure reporting options as follows:
fo：故障报告选项（纯文本；可选；默认值为“0”）提供生成故障报告所需的选项。报表生成器可以选择遵循所请求的选项。如果未指定“ruf”标记（如下），则必须忽略此标记的内容。此标记的值是以冒号分隔的字符列表，表示故障报告选项，如下所示：
0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result.
0：如果所有基础身份验证机制都无法生成对齐的“通过”结果，则生成DMARC失败报告。
1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result.
1：如果任何底层身份验证机制产生的结果不是对齐的“通过”结果，则生成DMARC失败报告。
d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM-specific reporting is described in [AFRF-DKIM].
d：如果消息的签名未通过评估，则生成DKIM失败报告，无论其对齐方式如何。[AFRF-DKIM]中描述了DKIM的具体报告。
s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment. SPF-specific reporting is described in [AFRF-SPF].
s：如果消息未能通过SPF评估，则生成SPF失败报告，无论其对齐方式如何。[AFRF-SPF]中描述了SPF特定报告。
p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag. This tag is mandatory for policy records only, but not for third-party reporting records (see Section 7.1). Possible values are as follows:
p：请求的邮件收件人策略（纯文本；策略记录需要）。指示接收方应域所有者的请求制定的策略。策略应用于查询的域和子域，除非使用“sp”标记明确描述子域策略。此标签仅对政策记录是强制性的，但对第三方报告记录不是强制性的（见第7.1节）。可能的值如下所示：
none: The Domain Owner requests no specific action be taken regarding delivery of messages.
无：域所有者不要求对邮件的传递采取任何特定操作。
quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious".
隔离：域所有者希望邮件接收者将未通过DMARC机制检查的电子邮件视为可疑邮件。根据邮件接收者的能力，这可能意味着“放入垃圾邮件文件夹”、“以额外的强度进行仔细检查”和/或“标记为可疑”。
reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction. See Section 10.3 for some discussion of SMTP rejection methods and their implications.
拒绝：域所有者希望邮件接收者拒绝未通过DMARC机制检查的电子邮件。SMTP事务期间应发生拒绝。有关SMTP拒绝方法及其含义的一些讨论，请参见第10.3节。
pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; default is 100). Percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied. However,
pct：（0到100之间的纯文本整数，包括在内；可选；默认值为100）。将应用DMARC策略的域所有者邮件流中的邮件百分比。然而
this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered. The purpose of the "pct" tag is to allow Domain Owners to enact a slow rollout enforcement of the DMARC mechanism. The prospect of "all or nothing" is recognized as preventing many organizations from experimenting with strong authentication-based mechanisms. See Section 6.6.4 for details. Note that random selection based on this percentage, such as the following pseudocode, is adequate:
这不得应用于DMARC生成的报告，所有报告都必须不受阻碍地发送和接收。“pct”标记的目的是允许域所有者缓慢地实施DMARC机制。“全有或全无”的前景被认为是阻止许多组织尝试基于身份验证的强机制。详见第6.6.4节。请注意，基于此百分比的随机选择（如以下伪码）已足够：
if (random mod 100) < pct then selected = true else selected = false
如果（随机模式100）<pct则选择=真，否则选择=假
rf: Format to be used for message-specific failure reports (colon-separated plain-text list of values; OPTIONAL; default is "afrf"). The value of this tag is a list of one or more report formats as requested by the Domain Owner to be used when a message fails both [SPF] and [DKIM] tests to report details of the individual failure. The values MUST be present in the registry of reporting formats defined in Section 11; a Mail Receiver observing a different value SHOULD ignore it or MAY ignore the entire DMARC record. For this version, only "afrf" (the auth-failure report type defined in [AFRF]) is presently supported. See Section 7.3 for details. For interoperability, the Authentication Failure Reporting Format (AFRF) MUST be supported.
rf：用于特定于消息的故障报告的格式（以冒号分隔的纯文本值列表；可选；默认值为“afrf”）。此标记的值是域所有者请求的一个或多个报告格式的列表，当消息未能通过[SPF]和[DKIM]测试时，将使用这些格式来报告单个失败的详细信息。这些值必须存在于第11节定义的报告格式注册表中；观察到不同值的邮件接收者应忽略该值，或者可以忽略整个DMARC记录。对于此版本，目前仅支持“afrf”（在[afrf]中定义的身份验证失败报告类型）。详见第7.3节。为了实现互操作性，必须支持身份验证失败报告格式（AFRF）。
ri: Interval requested between aggregate reports (plain-text 32-bit unsigned integer; OPTIONAL; default is 86400). Indicates a request to Receivers to generate aggregate reports separated by no more than the requested number of seconds. DMARC implementations MUST be able to provide daily reports and SHOULD be able to provide hourly reports when requested. However, anything other than a daily report is understood to be accommodated on a best-effort basis.
ri：聚合报告之间请求的间隔（纯文本32位无符号整数；可选；默认值为86400）。指示向接收者发出的生成聚合报告的请求，聚合报告之间的间隔不超过请求的秒数。DMARC实施必须能够提供每日报告，并且应能够在请求时提供每小时报告。然而，除了每日报告之外的任何内容都应理解为在尽最大努力的基础上进行调整。
rua: Addresses to which aggregate feedback is to be sent (comma-separated plain-text list of DMARC URIs; OPTIONAL). A comma or exclamation point that is part of such a DMARC URI MUST be encoded per Section 2.1 of [URI] so as to distinguish it from the list delimiter or an OPTIONAL size limit. Section 7.1 discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. See Section 12.5 for additional considerations. Any valid URI can be specified. A Mail Receiver MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If not
rua：要向其发送聚合反馈的地址（DMARC URI的逗号分隔纯文本列表；可选）。作为此类DMARC URI一部分的逗号或感叹号必须按照[URI]第2.1节进行编码，以便与列表分隔符或可选大小限制区分开来。第7.1节讨论了当URI的域名不同于发布策略的域名时应注意的事项。其他注意事项见第12.5节。可以指定任何有效的URI。邮件接收者必须实现对“mailto:”URI的支持，即通过电子邮件发送DMARC报告的能力。如果不是
provided, Mail Receivers MUST NOT generate aggregate feedback reports. URIs not supported by Mail Receivers MUST be ignored. The aggregate feedback report format is described in Section 7.2.
但是，邮件收件人不得生成聚合反馈报告。必须忽略邮件收件人不支持的URI。第7.2节描述了汇总反馈报告格式。
ruf: Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL). If present, the Domain Owner is requesting Mail Receivers to send detailed failure reports about messages that fail the DMARC evaluation in specific ways (see the "fo" tag above). The format of the message to be generated MUST follow the format specified for the "rf" tag. Section 7.1 discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. A Mail Receiver MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If not provided, Mail Receivers MUST NOT generate failure reports. See Section 12.5 for additional considerations.
ruf：要向其报告特定于消息的故障信息的地址（DMARC URI的逗号分隔纯文本列表；可选）。如果存在，域所有者将请求邮件接收者发送有关以特定方式未通过DMARC评估的邮件的详细失败报告（请参阅上面的“fo”标记）。要生成的消息格式必须遵循为“rf”标记指定的格式。第7.1节讨论了当URI的域名不同于发布策略的域名时应注意的事项。邮件接收者必须实现对“mailto:”URI的支持，即通过电子邮件发送DMARC报告的能力。如果未提供，邮件接收者不得生成故障报告。其他注意事项见第12.5节。
sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried and not to the domain itself. Its syntax is identical to that of the "p" tag defined above. If absent, the policy specified by the "p" tag MUST be applied for subdomains. Note that "sp" will be ignored for DMARC records published on subdomains of Organizational Domains due to the effect of the DMARC policy discovery mechanism described in Section 6.6.3.
sp：所有子域的请求邮件接收器策略（纯文本；可选）。指示接收方应域所有者的请求制定的策略。它仅适用于所查询域的子域，而不适用于域本身。它的语法与上面定义的“p”标记的语法相同。如果不存在，则必须将“p”标记指定的策略应用于子域。请注意，由于第6.6.3节所述的DMARC策略发现机制的影响，在组织域的子域上发布的DMARC记录将忽略“sp”。
v: Version (plain-text; REQUIRED). Identifies the record retrieved as a DMARC record. It MUST have the value of "DMARC1". The value of this tag MUST match precisely; if it does not or it is absent, the entire retrieved record MUST be ignored. It MUST be the first tag in the list.
v：版本（纯文本；必填）。标识检索为DMARC记录的记录。它的值必须为“DMARC1”。此标记的值必须精确匹配；如果没有或不存在，则必须忽略整个检索到的记录。它必须是列表中的第一个标记。
A DMARC policy record MUST comply with the formal specification found in Section 6.4 in that the "v" and "p" tags MUST be present and MUST appear in that order. Unknown tags MUST be ignored. Syntax errors in the remainder of the record SHOULD be discarded in favor of default values (if any) or ignored outright.
DMARC政策记录必须符合第6.4节中的正式规范，即“v”和“p”标签必须存在，并且必须按该顺序出现。必须忽略未知标记。应放弃记录其余部分中的语法错误，改为默认值（如果有），或直接忽略。
Note that given the rules of the previous paragraph, addition of a new tag into the registered list of tags does not itself require a new version of DMARC to be generated (with a corresponding change to the "v" tag's value), but a change to any existing tags does require a new version of DMARC.
请注意，根据上一段的规则，将新标签添加到已注册标签列表中本身并不需要生成新版本的DMARC（对“v”标签的值进行相应更改），但对任何现有标签的更改都需要新版本的DMARC。
The formal definition of the DMARC format, using [ABNF], is as follows:
使用[ABNF]的DMARC格式的正式定义如下：
dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ]
; "URI" is imported from [URI]; commas (ASCII
; 0x2C) and exclamation points (ASCII 0x21)
; MUST be encoded; the numeric portion MUST fit
; within an unsigned 64-bit integer
dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ]
; "URI" is imported from [URI]; commas (ASCII
; 0x2C) and exclamation points (ASCII 0x21)
; MUST be encoded; the numeric portion MUST fit
; within an unsigned 64-bit integer
dmarc-record = dmarc-version dmarc-sep
[dmarc-request]
[dmarc-sep dmarc-srequest]
[dmarc-sep dmarc-auri]
[dmarc-sep dmarc-furi]
[dmarc-sep dmarc-adkim]
[dmarc-sep dmarc-aspf]
[dmarc-sep dmarc-ainterval]
[dmarc-sep dmarc-fo]
[dmarc-sep dmarc-rfmt]
[dmarc-sep dmarc-percent]
[dmarc-sep]
; components other than dmarc-version and
; dmarc-request may appear in any order
dmarc-record = dmarc-version dmarc-sep
[dmarc-request]
[dmarc-sep dmarc-srequest]
[dmarc-sep dmarc-auri]
[dmarc-sep dmarc-furi]
[dmarc-sep dmarc-adkim]
[dmarc-sep dmarc-aspf]
[dmarc-sep dmarc-ainterval]
[dmarc-sep dmarc-fo]
[dmarc-sep dmarc-rfmt]
[dmarc-sep dmarc-percent]
[dmarc-sep]
; components other than dmarc-version and
; dmarc-request may appear in any order
dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
dmarc-sep = *WSP %x3b *WSP
dmarc-sep = *WSP %x3b *WSP
dmarc-request = "p" *WSP "=" *WSP
( "none" / "quarantine" / "reject" )
dmarc-request = "p" *WSP "=" *WSP
( "none" / "quarantine" / "reject" )
dmarc-srequest = "sp" *WSP "=" *WSP
( "none" / "quarantine" / "reject" )
dmarc-srequest = "sp" *WSP "=" *WSP
( "none" / "quarantine" / "reject" )
dmarc-auri = "rua" *WSP "=" *WSP
dmarc-uri *(*WSP "," *WSP dmarc-uri)
dmarc-auri = "rua" *WSP "=" *WSP
dmarc-uri *(*WSP "," *WSP dmarc-uri)
dmarc-furi = "ruf" *WSP "=" *WSP
dmarc-uri *(*WSP "," *WSP dmarc-uri)
dmarc-furi = "ruf" *WSP "=" *WSP
dmarc-uri *(*WSP "," *WSP dmarc-uri)
dmarc-adkim = "adkim" *WSP "=" *WSP
( "r" / "s" )
dmarc-adkim = "adkim" *WSP "=" *WSP
( "r" / "s" )
dmarc-aspf = "aspf" *WSP "=" *WSP
( "r" / "s" )
dmarc-aspf = "aspf" *WSP "=" *WSP
( "r" / "s" )
dmarc-ainterval = "ri" *WSP "=" *WSP 1*DIGIT
dmarc-ainterval = "ri" *WSP "=" *WSP 1*DIGIT
dmarc-fo = "fo" *WSP "=" *WSP
( "0" / "1" / "d" / "s" )
*(*WSP ":" *WSP ( "0" / "1" / "d" / "s" ))
dmarc-fo = "fo" *WSP "=" *WSP
( "0" / "1" / "d" / "s" )
*(*WSP ":" *WSP ( "0" / "1" / "d" / "s" ))
dmarc-rfmt = "rf" *WSP "=" *WSP Keyword *(*WSP ":" Keyword)
; registered reporting formats only
dmarc-rfmt = "rf" *WSP "=" *WSP Keyword *(*WSP ":" Keyword)
; registered reporting formats only
dmarc-percent = "pct" *WSP "=" *WSP
1*3DIGIT
dmarc-percent = "pct" *WSP "=" *WSP
1*3DIGIT
"Keyword" is imported from Section 4.1.2 of [SMTP].
“关键字”是从[SMTP]的第4.1.2节导入的。
A size limitation in a dmarc-uri, if provided, is interpreted as a count of units followed by an OPTIONAL unit size ("k" for kilobytes, "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a unit, the number is presumed to be a basic byte count. Note that the units are considered to be powers of two; a kilobyte is 2^10, a megabyte is 2^20, etc.
dmarc uri中的大小限制（如果提供的话）被解释为单位计数，后跟可选单位大小（“k”表示千字节，“m”表示兆字节，“g”表示千兆字节，“t”表示兆字节）。如果没有单位，则假定该数字为基本字节计数。注意，这些单位被认为是二的幂；千字节等于2^10，兆字节等于2^20，以此类推。
To implement the DMARC mechanism, the only action required of a Domain Owner is the creation of the DMARC policy record in the DNS. However, in order to make meaningful use of DMARC, a Domain Owner must at minimum either establish an address to receive reports, or deploy authentication technologies and ensure Identifier Alignment. Most Domain Owners will want to do both.
要实现DMARC机制，域所有者所需的唯一操作是在DNS中创建DMARC策略记录。然而，为了有意义地使用DMARC，域所有者必须至少建立一个接收报告的地址，或者部署身份验证技术并确保标识符对齐。大多数域名所有者都希望做到这两个方面。
DMARC reports will be of significant size, and the addresses that receive them are publicly visible, so we encourage Domain Owners to set up dedicated email addresses to receive and process reports, and to deploy abuse countermeasures on those email addresses as appropriate.
DMARC报告将具有很大的规模，并且接收它们的地址是公开可见的，因此我们鼓励域所有者设置专用的电子邮件地址来接收和处理报告，并酌情在这些电子邮件地址上部署滥用对策。
Authentication technologies are discussed in [DKIM] (see also [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT]) and [SPF].
[DKIM]（另请参见[DKIM-OVERVIEW]和[DKIM-DEPLOYMENT]）和[SPF]中讨论了身份验证技术。
This section describes receiver actions in the DMARC environment.
本节介绍DMARC环境中的接收器操作。
The domain in the RFC5322.From field is extracted as the domain to be evaluated by DMARC. If the domain is encoded with UTF-8, the domain name must be converted to an A-label, as described in Section 2.3 of [IDNA], for further processing.
RFC5322.From字段中的域被提取为要由DMARC评估的域。如果域使用UTF-8编码，则必须将域名转换为A标签（如[IDNA]第2.3节所述），以便进一步处理。
In order to be processed by DMARC, a message typically needs to contain exactly one RFC5322.From domain (a single From: field with a single domain in it). Not all messages meet this requirement, and handling of them is outside of the scope of this document. Typical exceptions, and the way they have been historically handled by DMARC participants, are as follows:
为了由DMARC处理，消息通常需要正好包含一个RFC5322.From域（一个From:字段，其中包含一个域）。并非所有消息都符合此要求，对它们的处理超出了本文档的范围。典型的例外情况以及DMARC参与者以往处理这些例外情况的方式如下：
o Messages with multiple RFC5322.From fields are typically rejected, since that form is forbidden under RFC 5322 [MAIL];
o 带有多个RFC5322.From字段的消息通常会被拒绝，因为RFC5322[MAIL]禁止使用该表单；
o Messages bearing a single RFC5322.From field containing multiple addresses (and, thus, multiple domain names to be evaluated) are typically rejected because the sorts of mail normally protected by DMARC do not use this format;
o 带有一个RFC5322.From字段的邮件包含多个地址（因此，需要评估的多个域名）通常会被拒绝，因为通常受DMARC保护的邮件类型不使用此格式；
o Messages that have no RFC5322.From field at all are typically rejected, since that form is forbidden under RFC 5322 [MAIL];
o 根本没有RFC5322.From字段的消息通常会被拒绝，因为RFC5322[MAIL]禁止该表单；
o Messages with an RFC5322.From field that contains no meaningful domains, such as RFC 5322 [MAIL]'s "group" syntax, are typically ignored.
o 带有RFC5322.From字段且不包含任何有意义的域的消息，例如RFC 5322[MAIL]的“组”语法，通常会被忽略。
The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. The process in this case is to apply the DMARC check using each of those domains found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail.
语法有效的多值RFC5322.From字段的情况提出了一个特殊的挑战。本例中的过程是使用RFC5322.From字段中的每个域作为作者域应用DMARC检查，并应用在失败的检查中选择的最严格的策略。
To arrive at a policy for an individual message, Mail Receivers MUST perform the following actions or their semantic equivalents. Steps 2-4 MAY be done in parallel, whereas steps 5 and 6 require input from previous steps.
要获得单个邮件的策略，邮件接收者必须执行以下操作或其语义等效操作。步骤2-4可以并行完成，而步骤5和6需要前面步骤的输入。
The steps are as follows:
步骤如下：
1. Extract the RFC5322.From domain from the message (as above).
1. 从消息中提取RFC5322.From域（如上所述）。
2. Query the DNS for a DMARC policy record. Continue if one is found, or terminate DMARC evaluation otherwise. See Section 6.6.3 for details.
2. 在DNS中查询DMARC策略记录。如果找到一个，则继续，否则终止DMARC评估。详见第6.6.3节。
3. Perform DKIM signature verification checks. A single email could contain multiple DKIM signatures. The results of this step are passed to the remainder of the algorithm and MUST include the value of the "d=" tag from each checked DKIM signature.
3. 执行DKIM签名验证检查。一封电子邮件可以包含多个DKIM签名。此步骤的结果将传递给算法的其余部分，并且必须包含来自每个已检查DKIM签名的“d=”标记的值。
4. Perform SPF validation checks. The results of this step are passed to the remainder of the algorithm and MUST include the domain name used to complete the SPF check.
4. 执行SPF验证检查。此步骤的结果将传递给算法的其余部分，并且必须包括用于完成SPF检查的域名。
5. Conduct Identifier Alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks to see if Authenticated Identifiers fall into alignment as described in Section 3. If one or more of the Authenticated Identifiers align with the RFC5322.From domain, the message is considered to pass the DMARC mechanism check. All other conditions (authentication failures, identifier mismatches) are considered to be DMARC mechanism check failures.
5. 进行标识符对齐检查。在执行身份验证检查和策略发现后，邮件接收者会检查身份验证标识符是否符合第3节所述的一致性。如果一个或多个经过身份验证的标识符与RFC5322.From域对齐，则认为该消息通过了DMARC机制检查。所有其他条件（身份验证失败、标识符不匹配）都被视为DMARC机制检查失败。
6. Apply policy. Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 6.3 for details.
6. 应用策略。未通过DMARC机制检查的电子邮件将根据域所有者发现的DMARC策略进行处理。详见第6.3节。
Heuristics applied in the absence of use by a Domain Owner of either SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be the case that the Domain Owner wishes a Message Receiver not to consider the results of that underlying authentication protocol at all.
在不使用SPF或DKIM域所有者（例如，[最佳猜测SPF]）的情况下应用的启发式不应该被使用，因为可能是域所有者希望消息接收者根本不考虑该底层认证协议的结果的情况。
DMARC evaluation can only yield a "pass" result after one of the underlying authentication mechanisms passes for an aligned identifier. If neither passes and one or both of them fail due to a temporary error, the Receiver evaluating the message is unable to conclude that the DMARC mechanism had a permanent failure; they
DMARC评估只能在一个底层身份验证机制通过对齐标识符后生成“通过”结果。如果两次均未通过，且其中一次或两次均因临时错误而失败，则评估消息的接收方无法断定DMARC机制存在永久性故障；他们
therefore cannot apply the advertised DMARC policy. When otherwise appropriate, Receivers MAY send feedback reports regarding temporary errors.
因此，无法应用播发的DMARC策略。在其他适当的情况下，接收者可以发送关于临时错误的反馈报告。
Handling of messages for which SPF and/or DKIM evaluation encounter a permanent DNS error is left to the discretion of the Mail Receiver.
SPF和/或DKIM评估遇到永久DNS错误的邮件的处理由邮件接收方自行决定。
As stated above, the DMARC mechanism uses DNS TXT records to advertise policy. Policy discovery is accomplished via a method similar to the method used for SPF records. This method, and the important differences between DMARC and SPF mechanisms, are discussed below.
如上所述，DMARC机制使用DNS TXT记录来公布策略。策略发现是通过与SPF记录使用的方法类似的方法完成的。该方法以及DMARC和SPF机制之间的重要区别将在下文中讨论。
To balance the conflicting requirements of supporting wildcarding, allowing subdomain policy overrides, and limiting DNS query load, the following DNS lookup scheme is employed:
为了平衡支持通配符、允许子域策略覆盖和限制DNS查询负载的冲突要求，采用了以下DNS查找方案：
1. Mail Receivers MUST query the DNS for a DMARC TXT record at the DNS domain matching the one found in the RFC5322.From domain in the message. A possibly empty set of records is returned.
1. 邮件收件人必须在DNS域中查询与消息中RFC5322.From域中找到的记录匹配的DMARC TXT记录。返回一组可能为空的记录。
2. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded.
2. 不以标识DMARC当前版本的“v=”标记开头的记录将被丢弃。
3. If the set is now empty, the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the Organizational Domain in place of the RFC5322.From domain in the message (if different). This record can contain policy to be asserted for subdomains of the Organizational Domain. A possibly empty set of records is returned.
3. 如果集合现在为空，则邮件接收者必须在DNS域中查询DMARC TXT记录，该记录与组织域匹配，而不是消息中的RFC5322.From域（如果不同）。此记录可以包含要为组织域的子域声明的策略。返回一组可能为空的记录。
4. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded.
4. 不以标识DMARC当前版本的“v=”标记开头的记录将被丢弃。
5. If the remaining set contains multiple records or no records, policy discovery terminates and DMARC processing is not applied to this message.
5. 如果剩余的集合包含多条记录或没有记录，则策略发现将终止，并且DMARC处理不会应用于此消息。
6. If a retrieved policy record does not contain a valid "p" tag, or contains an "sp" tag that is not valid, then:
6. 如果检索到的策略记录不包含有效的“p”标记，或包含无效的“sp”标记，则：
1. if a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver SHOULD act as if a record containing a valid "v" tag and "p=none" was retrieved, and continue processing;
1. 如果存在“rua”标记并且包含至少一个语法上有效的报告URI，则邮件接收者应像检索到包含有效“v”标记和“p=none”的记录一样，继续处理；
2. otherwise, the Mail Receiver applies no DMARC processing to this message.
2. 否则，邮件接收者不会对此邮件应用DMARC处理。
If the set produced by the mechanism above contains no DMARC policy record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers SHOULD NOT apply the DMARC mechanism to the message.
如果上述机制生成的集合不包含DMARC策略记录（即，与瞬时DNS错误相反，没有此类记录的任何指示），则邮件接收者不应将DMARC机制应用于邮件。
Handling of DNS errors when querying for the DMARC policy record is left to the discretion of the Mail Receiver. For example, to ensure minimal disruption of mail flow, transient errors could result in delivery of the message ("fail open"), or they could result in the message being temporarily rejected (i.e., an SMTP 4yx reply), which invites the sending MTA to try again after the condition has possibly cleared, allowing a definite DMARC conclusion to be reached ("fail closed").
查询DMARC策略记录时DNS错误的处理由邮件接收方自行决定。例如，为确保邮件流中断最小化，暂时性错误可能导致邮件传递（“失败打开”），或者可能导致邮件被临时拒绝（即SMTP 4yx回复），这将邀请发送MTA在条件可能清除后重试，允许得出明确的DMARC结论（“故障关闭”）。
If the "pct" tag is present in the policy record, the Mail Receiver MUST NOT enact the requested policy ("p" tag or "sp" tag") on more than the stated percent of the totality of affected messages. However, regardless of whether or not the "pct" tag is present, the Mail Receiver MUST include all relevant message data in any reports produced.
如果“pct”标记出现在策略记录中，则邮件接收者不得对超过受影响邮件总数百分比的规定邮件执行请求的策略（“p”标记或“sp”标记）。但是，无论“pct”标记是否存在，邮件接收者都必须在生成的任何报告中包含所有相关的邮件数据。
If email is subject to the DMARC policy of "quarantine", the Mail Receiver SHOULD quarantine the message. If the email is not subject to the "quarantine" policy (due to the "pct" tag), the Mail Receiver SHOULD apply local message classification as normal.
如果电子邮件受DMARC“隔离”策略的约束，则邮件收件人应隔离邮件。如果电子邮件不受“隔离”策略的约束（由于“pct”标记），则邮件收件人应按照正常情况应用本地邮件分类。
If email is subject to the DMARC policy of "reject", the Mail Receiver SHOULD reject the message (see Section 10.3). If the email is not subject to the "reject" policy (due to the "pct" tag), the Mail Receiver SHOULD treat the email as though the "quarantine" policy applies. This behavior allows Domain Owners to experiment with progressively stronger policies without relaxing existing policy.
如果电子邮件受DMARC“拒绝”政策的约束，则邮件接收者应拒绝该邮件（见第10.3节）。如果电子邮件不受“拒绝”策略的约束（由于“pct”标记），则邮件收件人应将电子邮件视为“隔离”策略适用。此行为允许域所有者在不放松现有策略的情况下尝试逐渐增强的策略。
Mail Receivers implement "pct" via statistical mechanisms that achieve a close approximation to the requested percentage and provide a representative sample across a reporting period.
邮件接收人通过统计机制实现“pct”，该机制与请求的百分比非常接近，并在报告期内提供代表性样本。
The results of Mail Receiver-based DMARC processing should be stored for eventual presentation back to the Domain Owner in the form of aggregate feedback reports. Sections 6.3 and 7.2 discuss aggregate feedback.
基于邮件接收者的DMARC处理结果应存储起来，以便最终以聚合反馈报告的形式呈现给域所有者。第6.3节和第7.2节讨论了总体反馈。
Mail Receivers MAY choose to reject or quarantine email even if email passes the DMARC mechanism check. The DMARC mechanism does not inform Mail Receivers whether an email stream is "good". Mail Receivers are encouraged to maintain anti-abuse technologies to combat the possibility of DMARC-enabled criminal campaigns.
即使电子邮件通过DMARC机制检查，邮件接收者也可以选择拒绝或隔离电子邮件。DMARC机制不会通知邮件接收者电子邮件流是否“良好”。鼓励邮件接收者维护反滥用技术，以打击DMARC犯罪活动的可能性。
Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the Domain Owner has published a "reject" policy. Mail Receivers need to make a best effort not to increase the likelihood of accepting abusive mail if they choose not to comply with a Domain Owner's reject, against policy. At a minimum, addition of the Authentication-Results header field (see [AUTH-RESULTS]) is RECOMMENDED when delivery of failing mail is done. When this is done, the DNS domain name thus recorded MUST be encoded as an A-label.
即使域所有者发布了“拒绝”策略，邮件接收者也可以选择接受未通过DMARC机制检查的电子邮件。如果邮件接收者选择不遵守域名所有者的拒绝政策，他们需要尽最大努力不增加接收滥用邮件的可能性。在发送失败邮件时，建议至少添加“身份验证结果”标题字段（请参见[AUTH-Results]）。完成此操作后，这样记录的DNS域名必须编码为A标签。
Mail Receivers are only obligated to report reject or quarantine policy actions in aggregate feedback reports that are due to DMARC policy. They are not required to report reject or quarantine actions that are the result of local policy. If local policy information is exposed, abusers can gain insight into the effectiveness and delivery rates of spam campaigns.
邮件收件人只有义务在因DMARC策略而产生的聚合反馈报告中报告拒绝或隔离策略操作。他们无需报告当地政策导致的拒收或检疫行动。如果暴露当地政策信息，滥用者可以深入了解垃圾邮件活动的有效性和交付率。
Final disposition of a message is always a matter of local policy. An operator that wishes to favor DMARC policy over SPF policy, for example, will disregard the SPF policy, since enacting an SPF-determined rejection prevents evaluation of DKIM; DKIM might otherwise pass, satisfying the DMARC evaluation. There is a trade-off to doing so, namely acceptance and processing of the entire message body in exchange for the enhanced protection DMARC provides.
消息的最终处置始终是本地策略的问题。例如，希望支持DMARC政策而非SPF政策的运营商将忽略SPF政策，因为制定SPF决定的拒绝会阻止对DKIM的评估；否则，DKIM可能通过，满足DMARC评估。这样做需要权衡，即接受和处理整个消息体，以换取DMARC提供的增强保护。
DMARC-compliant Mail Receivers typically disregard any mail-handling directive discovered as part of an authentication mechanism (e.g., Author Domain Signing Practices (ADSP), SPF) where a DMARC record is also discovered that specifies a policy other than "none". Deviating
符合DMARC的邮件接收者通常会忽略作为身份验证机制（例如，作者域签名实践（ADSP）、SPF）的一部分发现的任何邮件处理指令，其中还发现了指定“无”以外策略的DMARC记录。偏离
from this practice introduces inconsistency among DMARC operators in terms of handling of the message. However, such deviation is not proscribed.
从这个实践中，DMARC操作符在消息处理方面引入了不一致性。然而，这种偏离并没有被禁止。
To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=none" SHOULD NOT modify existing mail disposition processing.
为了使域所有者能够在不影响现有邮件处理的情况下接收DMARC反馈，发现的“p=none”策略不应修改现有邮件处理。
Mail Receivers SHOULD also implement reporting instructions of DMARC, even in the absence of a request for DKIM reporting [AFRF-DKIM] or SPF reporting [AFRF-SPF]. Furthermore, the presence of such requests SHOULD NOT affect DMARC reporting.
即使没有DKIM报告[AFRF-DKIM]或SPF报告[AFRF-SPF]的请求，邮件接收者也应执行DMARC的报告说明。此外，此类请求的存在不应影响DMARC报告。
Providing Domain Owners with visibility into how Mail Receivers implement and enforce the DMARC mechanism in the form of feedback is critical to establishing and maintaining accurate authentication deployments. When Domain Owners can see what effect their policies and practices are having, they are better willing and able to use quarantine and reject policies.
让域所有者了解邮件接收者如何以反馈的形式实施和实施DMARC机制，对于建立和维护准确的身份验证部署至关重要。当域所有者能够看到他们的策略和实践产生了什么影响时，他们就更愿意并能够使用隔离和拒绝策略。
It is possible to specify destinations for the different reports that are outside the authority of the Domain Owner making the request. This allows domains that do not operate mail servers to request reports and have them go someplace that is able to receive and process them.
可以为发出请求的域所有者权限之外的不同报告指定目的地。这允许不运行邮件服务器的域请求报告，并让它们转到能够接收和处理报告的地方。
Without checks, this would allow a bad actor to publish a DMARC policy record that requests that reports be sent to a victim address, and then send a large volume of mail that will fail both DKIM and SPF checks to a wide variety of destinations; the victim will in turn be flooded with unwanted reports. Therefore, a verification mechanism is included.
如果不进行检查，这将允许不良参与者发布DMARC策略记录，请求将报告发送到受害者地址，然后将大量邮件发送到各种目的地，这些邮件将无法通过DKIM和SPF检查；受害者会收到大量不必要的报告。因此，包含了一个验证机制。
When a Mail Receiver discovers a DMARC policy in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [URI] specified in the "rua" or "ruf" tag, the following verification steps are to be taken:
当邮件接收者在DNS中发现DMARC策略，并且发现该记录的组织域与“rua”或“ruf”标记中指定的[URI]的权限组件的主机部分的组织域不相同时，将采取以下验证步骤：
1. Extract the host portion of the authority component of the URI. Call this the "destination host", as it refers to a Report Receiver.
1. 提取URI的授权组件的主机部分。将其称为“目标主机”，因为它指的是报告接收器。
2. Prepend the string "_report._dmarc".
2. 在字符串“\u report.\u dmarc”前面加上前缀。
3. Prepend the domain name from which the policy was retrieved, after conversion to an A-label if needed.
3. 在转换为A标签（如果需要）后，在从中检索策略的域名前面加上前缀。
4. Query the DNS for a TXT record at the constructed name. If the result of this request is a temporary DNS error of some kind (e.g., a timeout), the Mail Receiver MAY elect to temporarily fail the delivery so the verification test can be repeated later.
4. 在DNS中查询构造名称处的TXT记录。如果此请求的结果是某种类型的临时DNS错误（例如超时），则邮件接收器可能会选择暂时使传递失败，以便稍后可以重复验证测试。
5. For each record returned, parse the result as a series of "tag=value" pairs, i.e., the same overall format as the policy record (see Section 6.4). In particular, the "v=DMARC1" tag is mandatory and MUST appear first in the list. Discard any that do not pass this test.
5. 对于返回的每个记录，将结果解析为一系列“tag=value”对，即与策略记录相同的总体格式（参见第6.4节）。特别是，“v=DMARC1”标记是必需的，必须首先出现在列表中。丢弃任何未通过此测试的部件。
6. If the result includes no TXT resource records that pass basic parsing, a positive determination of the external reporting relationship cannot be made; stop.
6. 如果结果不包含通过基本解析的TXT资源记录，则无法确定外部报告关系；停止
7. If at least one TXT resource record remains in the set after parsing, then the external reporting arrangement was authorized by the Report Receiver.
7. 如果解析后集合中至少保留一条TXT资源记录，则外部报告安排由报告接收者授权。
8. If a "rua" or "ruf" tag is thus discovered, replace the corresponding value extracted from the domain's DMARC policy record with the one found in this record. This permits the Report Receiver to override the report destination. However, to prevent loops or indirect abuse, the overriding URI MUST use the same destination host from the first step.
8. 如果这样发现了“rua”或“ruf”标记，则将从域的DMARC策略记录中提取的相应值替换为在该记录中找到的值。这允许报告接收者覆盖报告目标。但是，为了防止循环或间接滥用，重写URI必须从第一步开始使用相同的目标主机。
For example, if a DMARC policy query for "blue.example.com" contained "rua=mailto:reports@red.example.net", the host extracted from the latter ("red.example.net") does not match "blue.example.com", so this procedure is enacted. A TXT query for "blue.example.com._report._dmarc.red.example.net" is issued. If a single reply comes back containing a tag of "v=DMARC1", then the relationship between the two is confirmed. Moreover, "red.example.net" has the opportunity to override the report destination requested by "blue.example.com" if needed.
例如，如果“blue.example.com”的DMARC策略查询包含“rua=mailto:reports@red.example.net，则从后者提取的主机（“red.example.net”）与“blue.example.com”不匹配，因此制定此过程。发布了“blue.example.com.\u report.\u dmarc.red.example.net”的TXT查询。如果返回的单个回复包含“v=DMARC1”标记，则确认两者之间的关系。此外，如果需要，“red.example.net”有机会覆盖“blue.example.com”请求的报告目标。
Where the above algorithm fails to confirm that the external reporting was authorized by the Report Receiver, the URI MUST be ignored by the Mail Receiver generating the report. Further, if the confirming record includes a URI whose host is again different than the domain publishing that override, the Mail Receiver generating the report MUST NOT generate a report to either the original or the override URI.
如果上述算法无法确认外部报告是由报告接收方授权的，则生成报告的邮件接收方必须忽略URI。此外，如果确认记录包括其主机再次不同于覆盖的域发布的URI，则生成报告的邮件接收方不得生成原始或覆盖URI的报告。
A Report Receiver publishes such a record in its DNS if it wishes to receive reports for other domains.
如果报表接收方希望接收其他域的报表，则会在其DNS中发布此类记录。
A Report Receiver that is willing to receive reports for any domain can use a wildcard DNS record. For example, a TXT resource record at "*._report._dmarc.example.com" containing at least "v=DMARC1" confirms that example.com is willing to receive DMARC reports for any domain.
愿意接收任何域的报告的报告接收器可以使用通配符DNS记录。例如，位于“*.\u report.\u dmarc.example.com”的TXT资源记录至少包含“v=DMARC1”确认example.com愿意接收任何域的dmarc报告。
If the Report Receiver is overcome by volume, it can simply remove the confirming DNS record. However, due to positive caching, the change could take as long as the time-to-live (TTL) on the record to go into effect.
如果报告接收器被卷所克服，它可以简单地删除确认DNS记录。但是，由于正向缓存，更改可能需要与记录上的生存时间（TTL）一样长的时间才能生效。
A Mail Receiver might decide not to enact this procedure if, for example, it relies on a local list of domains for which external reporting addresses are permitted.
例如，如果邮件收件人依赖于允许使用外部报告地址的域的本地列表，则可能会决定不执行此过程。
The DMARC aggregate feedback report is designed to provide Domain Owners with precise insight into:
DMARC聚合反馈报告旨在为域所有者提供以下方面的精确见解：
o authentication results,
o 验证结果，
o corrective action that needs to be taken by Domain Owners, and
o 域所有者需要采取的纠正措施，以及
o the effect of Domain Owner DMARC policy on email streams processed by Mail Receivers.
o 域所有者DMARC策略对邮件接收者处理的电子邮件流的影响。
Aggregate DMARC feedback provides visibility into real-world email streams that Domain Owners need to make informed decisions regarding the publication of DMARC policy. When Domain Owners know what legitimate mail they are sending, what the authentication results are on that mail, and what forged mail receivers are getting, they can make better decisions about the policies they need and the steps they need to take to enable those policies. When Domain Owners set policies appropriately and understand their effects, Mail Receivers can act on them confidently.
聚合DMARC反馈提供了对现实世界电子邮件流的可见性，域所有者需要对DMARC策略的发布做出明智的决策。当域所有者知道他们发送的是什么合法邮件、该邮件上的身份验证结果是什么以及伪造邮件接收者得到的是什么时，他们就可以更好地决定他们需要的策略以及启用这些策略需要采取的步骤。当域所有者适当地设置策略并理解它们的影响时，邮件接收者可以自信地执行这些策略。
Visibility comes in the form of daily (or more frequent) Mail Receiver-originated feedback reports that contain aggregate data on message streams relevant to the Domain Owner. This information includes data about messages that passed DMARC authentication as well as those that did not.
可见性以每日（或更频繁）由邮件接收者发起的反馈报告的形式出现，其中包含与域所有者相关的消息流的聚合数据。此信息包括有关通过DMARC身份验证和未通过DMARC身份验证的消息的数据。
The format for these reports is defined in Appendix C.
这些报告的格式见附录C。
The report SHOULD include the following data:
报告应包括以下数据：
o The DMARC policy discovered and applied, if any
o 发现并应用了DMARC策略（如果有）
o The selected message disposition
o 所选邮件的处置
o The identifier evaluated by SPF and the SPF result, if any
o SPF评估的标识符和SPF结果（如果有）
o The identifier evaluated by DKIM and the DKIM result, if any
o DKIM评估的标识符和DKIM结果（如果有）
o For both DKIM and SPF, an indication of whether the identifier was in alignment
o 对于DKIM和SPF，标识符是否对齐的指示
o Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy
o 每个域所有者子域的数据与发件人组织域的邮件分开，即使没有明确的子域策略
o Sending and receiving domains
o 发送和接收域
o The policy requested by the Domain Owner and the policy actually applied (if different)
o 域所有者请求的策略和实际应用的策略（如果不同）
o The number of successful authentications
o 成功身份验证的次数
o The counts of messages based on all messages received, even if their delivery is ultimately blocked by other filtering agents
o 基于接收到的所有消息的消息计数，即使它们的传递最终被其他筛选代理阻止
Note that Domain Owners or their agents may change the published DMARC policy for a domain or subdomain at any time. From a Mail Receiver's perspective, this will occur during a reporting period and may be noticed during that period, at the end of that period when reports are generated, or during a subsequent reporting period, all depending on the Mail Receiver's implementation. Under these conditions, it is possible that a Mail Receiver could do any of the following:
请注意，域所有者或其代理可以随时更改域或子域的已发布DMARC策略。从邮件接收人的角度来看，这将在报告期内发生，并可能在报告期内、报告生成时的期末或后续报告期内注意到，所有这些都取决于邮件接收人的实施情况。在这些情况下，邮件接收者可能会执行以下任一操作：
o generate for such a reporting period a single aggregate report that includes message dispositions based on the old policy, or a mix of the two policies, even though the report only contains a single "policy_published" element;
o 为该报告期生成单个聚合报告，其中包括基于旧策略的消息处理，或两个策略的组合，即使该报告仅包含单个“策略发布”元素；
o generate multiple reports for the same period, one for each published policy occurring during the reporting period;
o 为同一期间生成多个报告，报告期间发生的每个已发布的策略一个报告；
o generate a report whose end time occurs when the updated policy was detected, regardless of any requested report interval.
o 生成一个报告，其结束时间发生在检测到更新的策略时，而与任何请求的报告间隔无关。
Such policy changes are expected to be infrequent for any given domain, whereas more stringent policy monitoring requirements on the Mail Receiver would produce a very large burden at Internet scale. Therefore, it is the responsibility of report consumers and Domain Owners to be aware of this situation and allow for such mixed reports during the propagation of the new policy to Mail Receivers.
对于任何给定的域，此类策略更改都是不常见的，而对邮件接收者更严格的策略监控要求将在互联网规模上产生非常大的负担。因此，报告使用者和域所有者有责任了解这种情况，并在向邮件接收者传播新策略期间允许此类混合报告。
Aggregate reports are most useful when they all cover a common time period. By contrast, correlation of these reports from multiple generators when they cover incongruent time periods is difficult or impossible. Report generators SHOULD, wherever possible, adhere to hour boundaries for the reporting period they are using. For example, starting a per-day report at 00:00; starting per-hour reports at 00:00, 01:00, 02:00; etc. Report generators using a 24-hour report period are strongly encouraged to begin that period at 00:00 UTC, regardless of local timezone or time of report production, in order to facilitate correlation.
聚合报告在所有报告都涵盖一个公共时间段时最有用。相比之下，当这些报告涵盖不一致的时间段时，将来自多个生成器的报告进行关联是困难的或不可能的。报告生成器应尽可能遵守其使用的报告期间的小时界限。例如，在00:00开始每日报告；在00:00、01:00、02:00开始每小时报告；等等。强烈鼓励使用24小时报告周期的报告生成器在UTC 00:00开始该周期，无论本地时区或报告生成时间如何，以便于关联。
A Mail Receiver discovers reporting requests when it looks up a DMARC policy record that corresponds to an RFC5322.From domain on received mail. The presence of the "rua" tag specifies where to send feedback.
邮件接收者在收到邮件时查找与RFC5322.From域相对应的DMARC策略记录时发现报告请求。“rua”标记的存在指定了向何处发送反馈。
Where the URI specified in a "rua" tag does not specify otherwise, a Mail Receiver generating a feedback report SHOULD employ a secure transport mechanism.
如果“rua”标记中指定的URI没有另外指定，则生成反馈报告的邮件接收方应采用安全传输机制。
The Mail Receiver, after preparing a report, MUST evaluate the provided reporting URIs in the order given. Any reporting URI that includes a size limitation exceeded by the generated report (after compression and after any encoding required by the particular transport mechanism) MUST NOT be used. An attempt MUST be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs.
邮件接收者在准备报告后，必须按照给定的顺序评估提供的报告URI。任何包含生成的报告超出的大小限制的报告URI（在压缩之后以及在特定传输机制要求的任何编码之后）都不得使用。必须尝试向每个剩余的URI交付聚合报告，直到接收方对支持的URI的限制。
If transport is not possible because the services advertised by the published URIs are not able to accept reports (e.g., the URI refers to a service that is unreachable, or all provided URIs specify size limits exceeded by the generated record), the Mail Receiver SHOULD send a short report (see Section 7.2.2) indicating that a report is available but could not be sent. The Mail Receiver MAY cache that data and try again later, or MAY discard data that could not be sent.
如果由于发布的URI所公布的服务无法接受报告而无法进行传输（例如，URI指的是无法访问的服务，或者所有提供的URI都指定了生成的记录超出的大小限制），则邮件接收方应发送一份简短报告（见第7.2.2节）指示报告可用但无法发送。邮件接收者可能会缓存该数据并稍后重试，或者可能会丢弃无法发送的数据。
The message generated by the Mail Receiver MUST be a [MAIL] message formatted per [MIME]. The aggregate report itself MUST be included in one of the parts of the message. A human-readable portion MAY be included as a MIME part (such as a text/plain part).
邮件接收者生成的邮件必须是按[MIME]格式化的[Mail]邮件。聚合报告本身必须包含在消息的一个部分中。人类可读部分可以包括为MIME部分（例如文本/普通部分）。
The aggregate data MUST be an XML file that SHOULD be subjected to GZIP compression. Declining to apply compression can cause the report to be too large for a receiver to process (a commonly observed receiver limit is ten megabytes); doing the compression increases the chances of acceptance of the report at some compute cost. The aggregate data SHOULD be present using the media type "application/ gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The filename is typically constructed using the following ABNF:
聚合数据必须是应接受GZIP压缩的XML文件。拒绝应用压缩可能导致报告太大，接收器无法处理（通常观察到的接收器限制为10兆字节）；进行压缩增加了以一定计算成本接受报告的机会。如果压缩（请参见[gzip]），则聚合数据应使用媒体类型“application/gzip”，否则使用“text/xml”。文件名通常使用以下ABNF构造：
filename = receiver "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
filename = receiver "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
unique-id = 1*(ALPHA / DIGIT)
unique-id = 1*(ALPHA / DIGIT)
receiver = domain ; imported from [MAIL]
接收器=域；从[邮件]导入
policy-domain = domain
policy-domain = domain
begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained
; in the report
begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained
; in the report
end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained
; in the report
end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained
; in the report
extension = "xml" / "xml.gz"
extension = "xml" / "xml.gz"
The extension MUST be "xml" for a plain XML file, or "xml.gz" for an XML file compressed using GZIP.
对于普通xml文件，扩展名必须是“xml”，对于使用GZIP压缩的xml文件，扩展名必须是“xml.gz”。
"unique-id" allows an optional unique ID generated by the Mail Receiver to distinguish among multiple reports generated simultaneously by different sources within the same Domain Owner.
“唯一id”允许邮件接收者生成可选的唯一id，以区分同一域所有者内不同来源同时生成的多个报告。
For example, this is a possible filename for the gzip file of a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example":
例如，这是从邮件接收者“Mail.Receiver.example”发送给域所有者“example.com”的报告的gzip文件的可能文件名：
mail.receiver.example!example.com!1013662812!1013749130.gz
mail.receiver.example!example.com!1013662812!1013749130.gz
No specific MIME message structure is required. It is presumed that the aggregate reporting address will be equipped to extract MIME parts with the prescribed media type and filename and ignore the rest.
不需要特定的MIME消息结构。假定聚合报告地址将用于提取具有指定媒体类型和文件名的MIME部分，而忽略其余部分。
Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports.
携带DMARC反馈数据的电子邮件流必须符合DMARC机制，从而产生一致的“通过”（见第3.1节）。这种做法将报表使用者处理欺诈性报表的风险降至最低。
The RFC5322.Subject field for individual report submissions SHOULD conform to the following ABNF:
个别报告提交的RFC5322.主题字段应符合以下ABNF：
dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report"
%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:"
domain-name 1*FWS ; from RFC 6376
%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
1*FWS domain-name 1*FWS
%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
msg-id ; from RFC 5322
dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report"
%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:"
domain-name 1*FWS ; from RFC 6376
%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
1*FWS domain-name 1*FWS
%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
msg-id ; from RFC 5322
The first domain-name indicates the DNS domain name about which the report was generated. The second domain-name indicates the DNS domain name representing the Mail Receiver generating the report. The purpose of the Report-ID: portion of the field is to enable the Domain Owner to identify and ignore duplicate reports that might be sent by a Mail Receiver.
第一个域名表示生成报告的DNS域名。第二个域名表示代表生成报告的邮件收件人的DNS域名。该字段的Report ID:部分的用途是使域所有者能够识别和忽略邮件接收者可能发送的重复报告。
For instance, this is a possible Subject field for a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example". It is line-wrapped as allowed by [MAIL]:
例如，对于从邮件接收者“Mail.Receiver.example”向域所有者“example.com”提交的报告，这是一个可能的主题字段。它是[邮件]允许的行包装：
Subject: Report Domain: example.com
Submitter: mail.receiver.example
Report-ID: <2002.02.15.1>
Subject: Report Domain: example.com
Submitter: mail.receiver.example
Report-ID: <2002.02.15.1>
This transport mechanism potentially encounters a problem when feedback data size exceeds maximum allowable attachment sizes for either the generator or the consumer. See Section 7.2.2 for further discussion.
当反馈数据大小超过生成器或使用者允许的最大附件大小时，此传输机制可能会遇到问题。进一步讨论见第7.2.2节。
The specification as written allows for the addition of other registered URI schemes to be supported in later versions.
所编写的规范允许在更高版本中添加其他已注册的URI方案。
When a Mail Receiver is unable to complete delivery of a report via any of the URIs listed by the Domain Owner, the Mail Receiver SHOULD generate an error message. An attempt MUST be made to send this report to all listed "mailto" URIs, and it MAY also be sent to any or all other listed URIs.
当邮件接收方无法通过域所有者列出的任何URI完成报告传递时，邮件接收方应生成错误消息。必须尝试将此报告发送给所有列出的“mailto”URI，也可以发送给任何或所有其他列出的URI。
The error report MUST be formatted per [MIME]. A text/plain part MUST be included that contains field-value pairs such as those found in Section 2 of [DSN]. The fields required, which may appear in any order, are as follows:
错误报告的格式必须为[MIME]。必须包括包含字段值对（如[DSN]第2节中的字段值对）的文本/普通部分。所需字段可按任何顺序显示，如下所示：
Report-Date: A [MAIL]-formatted date expression indicating when the transport failure occurred.
报告日期：一个[MAIL]格式的日期表达式，指示传输失败发生的时间。
Report-Domain: The domain-name about which the failed report was generated.
报告域：生成失败报告的域名。
Report-ID: The Report-ID: that the report tried to use.
报表ID：报表尝试使用的报表ID。
Report-Size: The size, in bytes, of the report that was unable to be sent. This MUST represent the number of bytes that the Mail Receiver attempted to send. Where more than one transport system was attempted, the sizes may be different; in such cases, separate error reports MUST be generated so that this value matches the actual attempt that was made.
报表大小：无法发送的报表的大小（以字节为单位）。这必须表示邮件接收器尝试发送的字节数。如果尝试了多个运输系统，则尺寸可能不同；在这种情况下，必须生成单独的错误报告，以使该值与实际尝试的结果相匹配。
Submitter: The domain-name representing the Mail Receiver that generated, but was unable to submit, the report.
Submitter：表示生成但无法提交报告的邮件收件人的域名。
Submitting-URI: The URI(s) to which the Mail Receiver tried, but failed, to submit the report.
提交URI：邮件收件人尝试向其提交报告但失败的URI。
An additional text/plain part MAY be included that gives a human-readable explanation of the above and MAY also include a URI that can be used to seek assistance.
可以包括给出上述的人类可读解释的附加文本/普通部分，并且还可以包括可用于寻求帮助的URI。
Failure reports are normally generated and sent almost immediately after the Mail Receiver detects a DMARC failure. Rather than waiting for an aggregate report, these reports are useful for quickly notifying the Domain Owners when there is an authentication failure. Whether the failure is due to an infrastructure problem or the message is inauthentic, failure reports also provide more information about the failed message than is available in an aggregate report.
故障报告通常在邮件接收器检测到DMARC故障后立即生成和发送。这些报告有助于在身份验证失败时快速通知域所有者，而不是等待聚合报告。无论故障是由于基础结构问题还是消息不真实造成的，故障报告都会提供有关故障消息的更多信息，而不是聚合报告中提供的信息。
These reports SHOULD include any URI(s) from the message that failed authentication. These reports SHOULD include as much of the message and message header as is reasonable to support the Domain Owner's investigation into what caused the message to fail authentication and track down the sender.
这些报告应包括来自身份验证失败消息的任何URI。这些报告应包含尽可能多的消息和消息头，以支持域所有者调查导致消息验证失败的原因并跟踪发送者。
When a Domain Owner requests failure reports for the purpose of forensic analysis, and the Mail Receiver is willing to provide such reports, the Mail Receiver generates and sends a message using the format described in [AFRF]; this document updates that reporting format, as described in Section 7.3.1.
当域所有者出于取证分析的目的请求故障报告，并且邮件接收方愿意提供此类报告时，邮件接收方使用[AFRF]中描述的格式生成并发送消息；本文件更新了该报告格式，如第7.3.1节所述。
The destination(s) and nature of the reports are defined by the "ruf" and "fo" tags as defined in Section 6.3.
报告的目的地和性质由第6.3节中定义的“ruf”和“fo”标签定义。
Where multiple URIs are selected to receive failure reports, the report generator MUST make an attempt to deliver to each of them.
如果选择了多个URI来接收故障报告，则报告生成器必须尝试向其中每个URI交付。
An obvious consideration is the denial-of-service attack that can be perpetrated by an attacker who sends numerous messages purporting to be from the intended victim Domain Owner but that fail both SPF and DKIM; this would cause participating Mail Receivers to send failure reports to the Domain Owner or its delegate in potentially huge volumes. Accordingly, participating Mail Receivers are encouraged to aggregate these reports as much as is practical, using the Incidents field of the Abuse Reporting Format ([ARF]). Various aggregation techniques are possible, including the following:
一个明显的考虑因素是，攻击者可以实施拒绝服务攻击，该攻击发送大量消息，声称来自预期的受害者域所有者，但SPF和DKIM均失败；这将导致参与的邮件接收者向域所有者或其代表发送大量的失败报告。因此，鼓励参与邮件接收者使用滥用报告格式（[ARF]）的事件字段，尽可能地汇总这些报告。可以使用各种聚合技术，包括以下技术：
o only send a report to the first recipient of multi-recipient messages;
o 仅向多收件人邮件的第一个收件人发送报告；
o store reports for a period of time before sending them, allowing detection, collection, and reporting of like incidents;
o 在发送报告之前，将报告存储一段时间，以便检测、收集和报告类似事件；
o apply rate limiting, such as a maximum number of reports per minute that will be generated (and the remainder discarded).
o 应用速率限制，例如每分钟将生成的最大报告数（剩余部分将被丢弃）。
Operators implementing this specification also implement an augmented version of [AFRF] as follows:
实施本规范的运营商还实施了[AFRF]的扩充版本，如下所示：
1. A DMARC failure report includes the following ARF header fields, with the indicated normative requirement levels:
1. DMARC故障报告包括以下ARF标题字段，以及指定的标准要求级别：
* Identity-Alignment (REQUIRED; defined below)
* 标识对齐（必需；定义如下）
* Delivery-Result (OPTIONAL)
* 交付结果（可选）
* DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED if the message was signed by DKIM)
* DKIM域、DKIM标识、DKIM选择器（如果消息由DKIM签名，则为必需）
* DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL if the message was signed by DKIM)
* DKIM规范化标头、DKIM规范化正文（如果消息由DKIM签名，则可选）
* SPF-DNS (REQUIRED)
* SPF-DNS（必需）
2. The "Identity-Alignment" field is defined to contain a comma-separated list of authentication mechanism names that produced an aligned identity, or the keyword "none" if none did. ABNF:
2. “标识对齐”字段定义为包含以逗号分隔的身份验证机制名称列表，这些名称生成对齐的标识，如果没有，则包含关键字“none”。荷兰银行：
id-align = "Identity-Alignment:" [CFWS] ( "none" / dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) ) [CFWS]
id align=“标识对齐：”[CFWS]（[none”/dmarc方法*（[CFWS]”，“[CFWS]dmarc方法））[CFWS]
dmarc-method = ( "dkim" / "spf" )
; each may appear at most once in an id-align
dmarc-method = ( "dkim" / "spf" )
; each may appear at most once in an id-align
3. Authentication Failure Type "dmarc" is defined, which is to be used when a failure report is generated because some or all of the authentication mechanisms failed to produce aligned identifiers. Note that a failure report generator MAY also independently produce an AFRF message for any or all of the underlying authentication methods.
3. 定义了身份验证失败类型“dmarc”，该类型将在生成失败报告时使用，因为某些或所有身份验证机制无法生成对齐的标识符。请注意，故障报告生成器还可以独立地为任何或所有底层身份验证方法生成AFRF消息。
A minimum implementation of DMARC has the following characteristics:
DMARC的最低实现具有以下特征：
o Is able to send and/or receive reports at least daily;
o 能够至少每天发送和/或接收报告；
o Is able to send and/or receive reports using "mailto" URIs;
o 能够使用“mailto”URI发送和/或接收报告；
o Other than in exceptional circumstances such as resource exhaustion, can generate or accept a report up to ten megabytes in size;
o 除资源耗尽等特殊情况外，您可以生成或接受最大为10兆字节的报告；
o If acting as a Mail Receiver, fully implements the provisions of Section 6.6.
o 如果作为邮件接收人，则完全执行第6.6节的规定。
This section discusses security issues specific to private data that may be included in the interactions that are part of DMARC.
本节讨论特定于私有数据的安全问题，这些私有数据可能包含在作为DMARC一部分的交互中。
Aggregate reports are limited in scope to DMARC policy and disposition results, to information pertaining to the underlying authentication mechanisms, and to the identifiers involved in DMARC validation.
聚合报告的范围仅限于DMARC策略和处置结果、与底层身份验证机制有关的信息以及DMARC验证中涉及的标识符。
Failed-message reporting provides message-specific details pertaining to authentication failures. Individual reports can contain message content as well as trace header fields. Domain Owners are able to analyze individual reports and attempt to determine root causes of authentication mechanism failures, gain insight into misconfigurations or other problems with email and network infrastructure, or inspect messages for insight into abusive practices.
Failed message reporting提供与身份验证失败相关的特定于消息的详细信息。单个报告可以包含消息内容以及跟踪头字段。域所有者能够分析单个报告并尝试确定身份验证机制失败的根本原因，深入了解电子邮件和网络基础设施的错误配置或其他问题，或者检查邮件以深入了解滥用行为。
Both report types may expose sender and recipient identifiers (e.g., RFC5322.From addresses), and although the [AFRF] format used for failed-message reporting supports redaction, failed-message reporting is capable of exposing the entire message to the report recipient.
这两种报告类型都可以公开发送者和接收者标识符（例如，来自地址的RFC5322），尽管用于失败消息报告的[AFRF]格式支持编校，但失败消息报告能够向报告接收者公开整个消息。
Domain Owners requesting reports will receive information about mail claiming to be from them, which includes mail that was not, in fact, from them. Information about the final destination of mail where it might otherwise be obscured by intermediate systems will therefore be exposed.
请求报告的域所有者将收到有关声称来自他们的邮件的信息，其中包括事实上并非来自他们的邮件。因此，有关邮件最终目的地的信息（否则可能会被中间系统遮挡）将被公开。
When message-forwarding arrangements exist, Domain Owners requesting reports will also receive information about mail forwarded to domains that were not originally part of their messages' recipient lists. This means that destination domains previously unknown to the Domain Owner may now become visible.
当存在邮件转发安排时，请求报告的域所有者还将收到有关转发到域的邮件的信息，这些邮件最初不属于其邮件收件人列表的一部分。这意味着域所有者以前未知的目标域现在可能可见。
Disclosure of information about the messages is being requested by the entity generating the email in the first place, i.e., the Domain Owner and not the Mail Receiver, so this may not fit squarely within
首先生成电子邮件的实体（即域所有者而非邮件接收者）正在请求披露有关邮件的信息，因此这可能不符合
existing privacy policy provisions. For some providers, aggregate reporting and failed-message reporting are viewed as a function similar to complaint reporting about spamming or phishing and are treated similarly under the privacy policy. Report generators (i.e., Mail Receivers) are encouraged to review their reporting limitations under such policies before enabling DMARC reporting.
现行私隐政策条文。对于某些提供商而言，聚合报告和失败消息报告被视为一种类似于垃圾邮件或网络钓鱼投诉报告的功能，并在隐私政策下得到类似的处理。在启用DMARC报告之前，鼓励报告生成器（即邮件接收者）审查其在此类政策下的报告限制。
A DMARC record can specify that reports should be sent to an intermediary operating on behalf of the Domain Owner. This is done when the Domain Owner contracts with an entity to monitor mail streams for abuse and performance issues. Receipt by third parties of such data may or may not be permitted by the Mail Receiver's privacy policy, terms of use, or other similar governing document. Domain Owners and Mail Receivers should both review and understand if their own internal policies constrain the use and transmission of DMARC reporting.
DMARC记录可以指定将报告发送给代表域所有者运行的中介。当域所有者与实体签订合同以监控邮件流是否存在滥用和性能问题时，就会执行此操作。邮件接收人的隐私政策、使用条款或其他类似管理文件可能允许或不允许第三方接收此类数据。域所有者和邮件接收者都应该审查并了解他们自己的内部策略是否限制了DMARC报告的使用和传输。
Some potential exists for report recipients to perform traffic analysis, making it possible to obtain metadata about the Receiver's traffic. In addition to verifying compliance with policies, Receivers need to consider that before sending reports to a third party.
报表收件人可能需要执行流量分析，从而可以获取有关收件人流量的元数据。除了验证策略的符合性外，接收方在发送报告给第三方之前需要考虑这一点。
This section discusses some topics regarding choices made in the development of DMARC, largely to commit the history to record.
本节讨论了有关DMARC开发过程中所做选择的一些主题，主要是为了记录历史。
Though DMARC does not inherently change the semantics of an SPF policy record, historically lax enforcement of such policies has led many to publish extremely broad records containing many large network ranges. Domain Owners are strongly encouraged to carefully review their SPF records to understand which networks are authorized to send on behalf of the Domain Owner before publishing a DMARC record.
尽管DMARC并没有从本质上改变SPF策略记录的语义，但从历史上看，此类策略的执行松懈导致许多人发布包含许多大型网络范围的极其广泛的记录。强烈鼓励域所有者在发布DMARC记录之前仔细查看其SPF记录，以了解哪些网络被授权代表域所有者发送。
Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this.
某些接收器架构可能在任何DMARC操作之前实现SPF。这意味着发送方SPF机制上的“-”前缀（如“-all”）可能会导致拒绝在处理过程中尽早生效，从而在任何DMARC处理发生之前导致消息拒绝。选择使用“-all”的操作员应意识到这一点。
DMARC policies are communicated using the DNS and therefore inherit a number of considerations related to DNS caching. The inherent conflict between freshness and the impact of caching on the reduction of DNS-lookup overhead should be considered from the Mail Receiver's point of view. Should Domain Owners publish a DNS record with a very short TTL, Mail Receivers can be provoked through the injection of large volumes of messages to overwhelm the Domain Owner's DNS. Although this is not a concern specific to DMARC, the implications of a very short TTL should be considered when publishing DMARC policies.
DMARC策略使用DNS进行通信，因此继承了许多与DNS缓存相关的注意事项。从邮件接收者的角度来看，应该考虑新鲜度和缓存对减少DNS查找开销的影响之间的固有冲突。如果域所有者以非常短的TTL发布DNS记录，则可以通过注入大量消息来激发邮件接收者，以压倒域所有者的DNS。虽然这不是DMARC特有的问题，但在发布DMARC策略时，应考虑非常短的TTL的影响。
Conversely, long TTLs will cause records to be cached for long periods of time. This can cause a critical change to DMARC parameters advertised by a Domain Owner to go unnoticed for the length of the TTL (while waiting for DNS caches to expire). Avoiding this problem can mean shorter TTLs, with the potential problems described above. A balance should be sought to maintain responsiveness of DMARC preference changes while preserving the benefits of DNS caching.
相反，长TTL将导致记录被缓存很长一段时间。这可能会导致在TTL长度内（在等待DNS缓存过期时）未注意到域所有者公布的DMARC参数的关键更改。避免这个问题可能意味着缩短TTL，以及上述潜在问题。应寻求平衡，以保持DMARC首选项更改的响应能力，同时保留DNS缓存的好处。
This proposal calls for rejection of a message during the SMTP session under certain circumstances. This is preferable to generation of a Delivery Status Notification ([DSN]), since fraudulent messages caught and rejected using DMARC would then result in annoying generation of such failure reports that go back to the RFC5321.MailFrom address.
此建议要求在某些情况下在SMTP会话期间拒绝邮件。这比生成传递状态通知（[DSN]）更可取，因为使用DMARC捕获和拒绝的欺诈性邮件将导致生成此类故障报告，并返回到RFC5321.MailFrom地址，这很烦人。
This synchronous rejection is typically done in one of two ways:
这种同步拒绝通常通过以下两种方式之一进行：
o Full rejection, wherein the SMTP server issues a 5xy reply code as an indication to the SMTP client that the transaction failed; the SMTP client is then responsible for generating notification that delivery failed (see Section 4.2.5 of [SMTP]).
o 完全拒绝，其中SMTP服务器向SMTP客户端发出5xy回复代码，表示事务失败；然后，SMTP客户端负责生成传递失败的通知（请参阅[SMTP]第4.2.5节）。
o A "silent discard", wherein the SMTP server returns a 2xy reply code implying to the client that delivery (or, at least, relay) was successfully completed, but then simply discarding the message with no further action.
o 一种“静默丢弃”，其中SMTP服务器返回一个2xy回复代码，向客户端暗示传递（或至少中继）已成功完成，但随后简单地丢弃消息，无需进一步操作。
Each of these has a cost. For instance, a silent discard can help to prevent backscatter, but it also effectively means that the SMTP server has to be programmed to give a false result, which can confound external debugging efforts.
每一个都有成本。例如，静默丢弃有助于防止反向散射，但它也有效地意味着必须对SMTP服务器进行编程以给出错误的结果，这可能会混淆外部调试工作。
Similarly, the text portion of the SMTP reply may be important to consider. For example, when rejecting a message, revealing the reason for the rejection might give an attacker enough information to bypass those efforts on a later attempt, though it might also assist a legitimate client to determine the source of some local issue that caused the rejection.
类似地，SMTP应答的文本部分可能是重要的考虑因素。例如，在拒绝消息时，揭示拒绝原因可能会让攻击者获得足够的信息，以便在以后的尝试中绕过这些努力，但这也可能有助于合法客户端确定导致拒绝的某些本地问题的来源。
In the latter case, when doing an SMTP rejection, providing a clear hint can be useful in resolving issues. A receiver might indicate in plain text the reason for the rejection by using the word "DMARC" somewhere in the reply text. Many systems are able to scan the SMTP reply text to determine the nature of the rejection. Thus, providing a machine-detectable reason for rejection allows the problems causing rejections to be properly addressed by automated systems. For example:
在后一种情况下，在执行SMTP拒绝时，提供明确提示有助于解决问题。接收者可以在回复文本的某个地方使用“DMARC”一词，以纯文本形式指出拒绝的原因。许多系统能够扫描SMTP回复文本以确定拒绝的性质。因此，提供一个机器可检测的拒绝原因可以使导致拒绝的问题通过自动化系统得到适当解决。例如：
550 5.7.1 Email rejected per DMARC policy for example.com
550 5.7.1根据DMARC政策拒绝电子邮件，例如.com
If a Mail Receiver elects to defer delivery due to inability to retrieve or apply DMARC policy, this is best done with a 4xy SMTP reply code.
如果邮件接收人由于无法检索或应用DMARC策略而选择延迟传递，则最好使用4xy SMTP回复代码。
The DMARC mechanism allows both DKIM and SPF-authenticated identifiers to authenticate email on behalf of a Domain Owner and, possibly, on behalf of different subdomains. If malicious or unaware users can gain control of the SPF record or DKIM selector records for a subdomain, the subdomain can be used to generate DMARC-passing email on behalf of the Organizational Domain.
DMARC机制允许DKIM和SPF身份验证标识符代表域所有者以及可能代表不同子域对电子邮件进行身份验证。如果恶意或不知情的用户可以控制子域的SPF记录或DKIM选择器记录，则子域可用于代表组织域生成DMARC传递电子邮件。
For example, an attacker who controls the SPF record for "evil.example.com" can send mail with an RFC5322.From field containing "foo@example.com" that can pass both authentication and the DMARC check against "example.com".
例如，控制“evil.example.com”的SPF记录的攻击者可以使用RFC5322.From字段发送邮件，该字段包含“foo@example.com可以通过身份验证和对“example.com”的DMARC检查。
The Organizational Domain administrator should be careful not to delegate control of subdomains if this is an issue, and to consider using the "strict" Identifier Alignment option if appropriate.
如果这是一个问题，组织域管理员应该小心不要委托子域的控制，并且如果适当的话，考虑使用“严格”标识符对齐选项。
DMARC limits which end-to-end scenarios can achieve a "pass" result.
DMARC限制了哪些端到端场景可以实现“通过”结果。
Because DMARC relies on [SPF] and/or [DKIM] to achieve a "pass", their limitations also apply.
由于DMARC依靠[SPF]和/或[DKIM]实现“通过”，因此它们的限制也适用。
Additional DMARC constraints occur when a message is processed by some Mediators, such as mailing lists. Transiting a Mediator often causes either the authentication to fail or Identifier Alignment to be lost. These transformations may conform to standards but will still prevent a DMARC "pass".
当消息由某些中介（如邮件列表）处理时，会出现额外的DMARC约束。传递中介通常会导致身份验证失败或标识符对齐丢失。这些转换可能符合标准，但仍将阻止DMARC“通过”。
In addition to Mediators, mail that is sent by authorized, independent third parties might not be sent with Identifier Alignment, also preventing a "pass" result.
除了中介，由授权的独立第三方发送的邮件可能不会与标识符对齐，这也会阻止“通过”结果。
Issues specific to the use of policy mechanisms alongside DKIM are further discussed in [DKIM-LISTS], particularly Section 5.2.
[DKIM-LISTS]特别是第5.2节进一步讨论了与DKIM一起使用政策机制相关的具体问题。
This section describes actions completed by IANA.
本节介绍IANA完成的操作。
IANA has added the following to the "Email Authentication Methods" registry:
IANA已将以下内容添加到“电子邮件身份验证方法”注册表中：
Method: dmarc
方法：dmarc
Defined: RFC 7489
定义：RFC 7489
ptype: header
p类型：标题
Property: from
物业：来自
Value: the domain portion of the RFC5322.From field
值：RFC5322.From字段的域部分
Status: active
状态：活动
Version: 1
版本:1
IANA has added the following in the "Email Authentication Result Names" registry:
IANA在“电子邮件身份验证结果名称”注册表中添加了以下内容：
Code: none
代码：无
Existing/New Code: existing
现有/新代码：现有
Defined: [AUTH-RESULTS]
已定义：[验证结果]
Auth Method: dmarc (added)
验证方法：dmarc（已添加）
Meaning: No DMARC policy record was published for the aligned identifier, or no aligned identifier could be extracted.
含义：未发布对齐标识符的DMARC策略记录，或者无法提取对齐标识符。
Status: active
状态：活动
Code: pass
代码：pass
Existing/New Code: existing
现有/新代码：现有
Defined: [AUTH-RESULTS]
已定义：[验证结果]
Auth Method: dmarc (added)
验证方法：dmarc（已添加）
Meaning: A DMARC policy record was published for the aligned identifier, and at least one of the authentication mechanisms passed.
含义：已为对齐标识符发布DMARC策略记录，并且至少传递了一个身份验证机制。
Status: active
状态：活动
Code: fail
代码：失败
Existing/New Code: existing
现有/新代码：现有
Defined: [AUTH-RESULTS]
已定义：[验证结果]
Auth Method: dmarc (added)
验证方法：dmarc（已添加）
Meaning: A DMARC policy record was published for the aligned identifier, and none of the authentication mechanisms passed.
含义：已为对齐标识符发布DMARC策略记录，并且未传递任何身份验证机制。
Status: active
状态：活动
Code: temperror
代码：temperor
Existing/New Code: existing
现有/新代码：现有
Defined: [AUTH-RESULTS]
已定义：[验证结果]
Auth Method: dmarc (added)
验证方法：dmarc（已添加）
Meaning: A temporary error occurred during DMARC evaluation. A later attempt might produce a final result.
含义：在DMARC评估期间发生临时错误。稍后的尝试可能会产生最终结果。
Status: active
状态：活动
Code: permerror
代码：permerror
Existing/New Code: existing
现有/新代码：现有
Defined: [AUTH-RESULTS]
已定义：[验证结果]
Auth Method: dmarc (added)
验证方法：dmarc（已添加）
Meaning: A permanent error occurred during DMARC evaluation, such as encountering a syntactically incorrect DMARC record. A later attempt is unlikely to produce a final result.
含义：在DMARC评估期间发生永久性错误，例如遇到语法错误的DMARC记录。以后的尝试不太可能产生最终结果。
Status: active
状态：活动
The following has been added to the "Feedback Report Header Fields" registry:
以下内容已添加到“反馈报告标题字段”注册表中：
Field Name: Identity-Alignment
字段名称：标识对齐
Description: indicates whether the message about which a report is being generated had any identifiers in alignment as defined in RFC 7489
描述：指示正在生成报告的消息是否具有RFC 7489中定义的对齐标识符
Multiple Appearances: No
多次出现：否
Related "Feedback-Type": auth-failure
相关“反馈类型”：身份验证失败
Reference: RFC 7489
参考：RFC 7489
Status: current
状态：当前
A new registry tree called "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters" has been created. Within it, a new sub-registry called the "DMARC Tag Registry" has been created.
创建了一个名为“基于域的消息身份验证、报告和一致性（DMARC）参数”的新注册表树。在其中，创建了一个名为“DMARC标记注册表”的新子注册表。
Names of DMARC tags must be registered with IANA in this new sub-registry. New entries are assigned only for values that have been documented in a manner that satisfies the terms of Specification Required, per [IANA-CONSIDERATIONS]. Each registration must include the tag name; the specification that defines it; a brief description; and its status, which must be one of "current", "experimental", or "historic". The Designated Expert needs to confirm that the provided
DMARC标签的名称必须在此新的子注册表中向IANA注册。根据[IANA-注意事项]，新条目仅分配给以满足所需规范条款的方式记录的值。每次注册必须包括标签名称；定义它的规范；简要描述；它的地位，必须是“当前的”、“实验的”或“历史的”。指定专家需要确认所提供的
specification adequately describes the new tag and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers.
规范充分描述了新标记，并清楚地说明了域所有者和邮件接收者如何在DMARC上下文中使用它。
To avoid version compatibility issues, tags added to the DMARC specification are to avoid changing the semantics of existing records when processed by implementations conforming to prior specifications.
为了避免版本兼容性问题，添加到DMARC规范中的标记是为了避免在由符合先前规范的实现处理时更改现有记录的语义。
The initial set of entries in this registry is as follows:
此注册表中的初始项集如下所示：
+----------+-------------+---------+------------------------------+
| Tag Name | Reference | Status | Description |
+----------+-------------+---------+------------------------------+
| adkim | RFC 7489 | current | DKIM alignment mode |
+----------+-------------+---------+------------------------------+
| aspf | RFC 7489 | current | SPF alignment mode |
+----------+-------------+---------+------------------------------+
| fo | RFC 7489 | current | Failure reporting options |
+----------+-------------+---------+------------------------------+
| p | RFC 7489 | current | Requested handling policy |
+----------+-------------+---------+------------------------------+
| pct | RFC 7489 | current | Sampling rate |
+----------+-------------+---------+------------------------------+
| rf | RFC 7489 | current | Failure reporting format(s) |
+----------+-------------+---------+------------------------------+
| ri | RFC 7489 | current | Aggregate Reporting interval |
+----------+-------------+---------+------------------------------+
| rua | RFC 7489 | current | Reporting URI(s) for |
| | | | aggregate data |
+----------+-------------+---------+------------------------------+
| ruf | RFC 7489 | current | Reporting URI(s) for |
| | | | failure data |
+----------+-------------+---------+------------------------------+
| sp | RFC 7489 | current | Requested handling policy |
| | | | for subdomains |
+----------+-------------+---------+------------------------------+
| v | RFC 7489 | current | Specification version |
+----------+-------------+---------+------------------------------+
+----------+-------------+---------+------------------------------+
| Tag Name | Reference | Status | Description |
+----------+-------------+---------+------------------------------+
| adkim | RFC 7489 | current | DKIM alignment mode |
+----------+-------------+---------+------------------------------+
| aspf | RFC 7489 | current | SPF alignment mode |
+----------+-------------+---------+------------------------------+
| fo | RFC 7489 | current | Failure reporting options |
+----------+-------------+---------+------------------------------+
| p | RFC 7489 | current | Requested handling policy |
+----------+-------------+---------+------------------------------+
| pct | RFC 7489 | current | Sampling rate |
+----------+-------------+---------+------------------------------+
| rf | RFC 7489 | current | Failure reporting format(s) |
+----------+-------------+---------+------------------------------+
| ri | RFC 7489 | current | Aggregate Reporting interval |
+----------+-------------+---------+------------------------------+
| rua | RFC 7489 | current | Reporting URI(s) for |
| | | | aggregate data |
+----------+-------------+---------+------------------------------+
| ruf | RFC 7489 | current | Reporting URI(s) for |
| | | | failure data |
+----------+-------------+---------+------------------------------+
| sp | RFC 7489 | current | Requested handling policy |
| | | | for subdomains |
+----------+-------------+---------+------------------------------+
| v | RFC 7489 | current | Specification version |
+----------+-------------+---------+------------------------------+
Also within "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters", a new sub-registry called "DMARC Report Format Registry" has been created.
在“基于域的消息验证、报告和一致性（DMARC）参数”中，还创建了一个名为“DMARC报告格式注册表”的新子注册表。
Names of DMARC failure reporting formats must be registered with IANA in this registry. New entries are assigned only for values that satisfy the definition of Specification Required, per
DMARC故障报告格式的名称必须在此注册表中向IANA注册。根据，仅为满足所需规范定义的值分配新条目
[IANA-CONSIDERATIONS]. In addition to a reference to a permanent specification, each registration must include the format name; a brief description; and its status, which must be one of "current", "experimental", or "historic". The Designated Expert needs to confirm that the provided specification adequately describes the report format and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers.
[IANA-考虑因素]。除了参考永久规范外，每次注册必须包括格式名称；简要描述；它的地位，必须是“当前的”、“实验的”或“历史的”。指定专家需要确认所提供的规范充分描述了报告格式，并明确说明了域所有者和邮件接收者如何在DMARC上下文中使用该格式。
The initial entry in this registry is as follows:
此注册表中的初始条目如下所示：
+--------+-------------+---------+-----------------------------+
| Format | Reference | Status | Description |
| Name | | | |
+--------+-------------+---------+-----------------------------+
| afrf | RFC 7489 | current | Authentication Failure |
| | | | Reporting Format (see |
| | | | [AFRF]) |
+--------+-------------+---------+-----------------------------+
+--------+-------------+---------+-----------------------------+
| Format | Reference | Status | Description |
| Name | | | |
+--------+-------------+---------+-----------------------------+
| afrf | RFC 7489 | current | Authentication Failure |
| | | | Reporting Format (see |
| | | | [AFRF]) |
+--------+-------------+---------+-----------------------------+
This section discusses security issues and possible remediations (where available) for DMARC.
本节讨论DMARC的安全问题和可能的补救措施（如有）。
Security considerations from the authentication methods used by DMARC are incorporated here by reference.
DMARC使用的身份验证方法的安全注意事项通过引用并入此处。
URIs published in DNS TXT records are well-understood possible targets for attack. Specifications such as [DNS] and [ROLES] either expose or cause the exposure of email addresses that could be flooded by an attacker, for example; MX, NS, and other records found in the DNS advertise potential attack destinations; common DNS names such as "www" plainly identify the locations at which particular services can be found, providing destinations for targeted denial-of-service or penetration attacks.
DNS TXT记录中发布的URI是众所周知的可能攻击目标。例如，[DNS]和[ROLES]等规范暴露或导致暴露可能被攻击者淹没的电子邮件地址；DNS中发现的MX、NS和其他记录宣传潜在的攻击目的地；常见的DNS名称（如“www”）明确标识可以找到特定服务的位置，为目标拒绝服务或渗透攻击提供目的地。
Thus, Domain Owners will need to harden these addresses against various attacks, including but not limited to:
因此，域所有者将需要加强这些地址以抵御各种攻击，包括但不限于：
o high-volume denial-of-service attacks;
o 大量拒绝服务攻击；
o deliberate construction of malformed reports intended to identify or exploit parsing or processing vulnerabilities;
o 故意构建格式错误的报告，以识别或利用解析或处理漏洞；
o deliberate construction of reports containing false claims for the Submitter or Reported-Domain fields, including the possibility of false data from compromised but known Mail Receivers.
o 故意构建包含提交人或报告域字段的虚假声明的报告，包括来自受损但已知邮件接收者的虚假数据的可能性。
The DMARC mechanism and its underlying technologies (SPF, DKIM) depend on the security of the DNS. To reduce the risk of subversion of the DMARC mechanism due to DNS-based exploits, serious consideration should be given to the deployment of DNSSEC in parallel with the deployment of DMARC by both Domain Owners and Mail Receivers.
DMARC机制及其底层技术（SPF、DKIM）依赖于DNS的安全性。为了降低由于基于DNS的攻击而破坏DMARC机制的风险，应认真考虑在域所有者和邮件接收者部署DMARC的同时部署DNSSEC。
Publication of data using DNSSEC is relevant to Domain Owners and third-party Report Receivers. DNSSEC-aware resolution is relevant to Mail Receivers and Report Receivers.
使用DNSSEC发布数据与域所有者和第三方报告接收者相关。DNSSEC感知解析与邮件接收者和报告接收者相关。
A common attack in messaging abuse is the presentation of false information in the display-name portion of the RFC5322.From field. For example, it is possible for the email address in that field to be an arbitrary address or domain name, while containing a well-known name (a person, brand, role, etc.) in the display name, intending to fool the end user into believing that the name is used legitimately. The attack is predicated on the notion that most common MUAs will show the display name and not the email address when both are available.
消息传递滥用中的常见攻击是在RFC5322.From字段的显示名称部分显示错误信息。例如，该字段中的电子邮件地址可能是任意地址或域名，同时在显示名称中包含知名名称（个人、品牌、角色等），意图欺骗最终用户相信该名称是合法使用的。该攻击基于这样一个概念，即当两个MUA都可用时，大多数常见的MUA将显示显示名称而不是电子邮件地址。
Generally, display name attacks are out of scope for DMARC, as further exploration of possible defenses against these attacks needs to be undertaken.
通常，显示名称攻击不在DMARC的范围内，因为需要进一步探索针对这些攻击的可能防御措施。
There are a few possible mechanisms that attempt mitigation of these attacks, such as the following:
有几种可能的机制试图缓解这些攻击，例如：
o If the display name is found to include an email address (as specified in [MAIL]), execute the DMARC mechanism on the domain name found there rather than the domain name discovered originally. However, this addresses only a very specific attack space, and spoofers can easily circumvent it by simply not using an email address in the display name. There are also known cases of legitimate uses of an email address in the display name with a domain different from the one in the address portion, e.g.,
o 如果发现显示名称包含电子邮件地址（如[MAIL]中所述），则对在此处找到的域名而不是最初发现的域名执行DMARC机制。然而，这只针对一个非常特定的攻击空间，欺骗者可以通过不在显示名称中使用电子邮件地址轻松绕过它。还存在合法使用显示名称中的电子邮件地址的已知情况，其域与地址部分中的域不同，例如。，
From: "user@example.org via Bug Tracker" <support@example.com>
From: "user@example.org via Bug Tracker" <support@example.com>
o In the MUA, only show the display name if the DMARC mechanism succeeds. This too is easily defeated, as an attacker could arrange to pass the DMARC tests while fraudulently using another domain name in the display name.
o 在MUA中，仅当DMARC机制成功时才显示显示名称。这也很容易被击败，因为攻击者可以安排通过DMARC测试，同时在显示名中欺诈性地使用另一个域名。
o In the MUA, only show the display name if the DMARC mechanism passes and the email address thus validated matches one found in the receiving user's list of known addresses.
o 在MUA中，仅当DMARC机制通过且验证的电子邮件地址与接收用户已知地址列表中的地址匹配时，才显示显示名称。
To avoid abuse by bad actors, reporting addresses generally have to be inside the domains about which reports are requested. In order to accommodate special cases such as a need to get reports about domains that cannot actually receive mail, Section 7.1 describes a DNS-based mechanism for verifying approved external reporting.
为了避免坏角色的滥用，报告地址通常必须位于请求报告的域内。为了适应特殊情况，例如需要获取有关无法实际接收邮件的域的报告，第7.1节介绍了一种基于DNS的机制，用于验证已批准的外部报告。
The obvious consideration here is an increased DNS load against domains that are claimed as external recipients. Negative caching will mitigate this problem, but only to a limited extent, mostly dependent on the default TTL in the domain's SOA record.
这里明显需要考虑的是，对于声明为外部收件人的域，DNS负载会增加。负缓存将缓解此问题，但仅在有限的范围内，主要依赖于域的SOA记录中的默认TTL。
Where possible, external reporting is best achieved by having the report be directed to domains that can receive mail and simply having it automatically forwarded to the desired external destination.
在可能的情况下，最好通过将报告定向到可以接收邮件的域并将其自动转发到所需的外部目标来实现外部报告。
Note that the addresses shown in the "ruf" tag receive more information that might be considered private data, since it is possible for actual email content to appear in the failure reports. The URIs identified there are thus more attractive targets for intrusion attempts than those found in the "rua" tag. Moreover, attacking the DNS of the subject domain to cause failure data to be routed fraudulently to an attacker's systems may be an attractive prospect. Deployment of [DNSSEC] is advisable if this is a concern.
请注意，“ruf”标记中显示的地址接收到更多可能被视为私人数据的信息，因为实际电子邮件内容可能出现在故障报告中。因此，识别出的URI比“rua”标记中发现的目标更有吸引力。此外，攻击主题域的DNS以导致故障数据被欺诈地路由到攻击者的系统可能是一个有吸引力的前景。如果存在问题，建议部署[DNSSEC]。
The verification mechanism presented in Section 7.1 is currently not mandatory ("MUST") but strongly recommended ("SHOULD"). It is possible that it would be elevated to a "MUST" by later security review.
第7.1节中的验证机制目前不是强制性的（“必须”），但强烈建议（“应该”）。有可能在以后的安全审查中将其提升为“必须”。
This document encourages use of secure transport mechanisms to prevent loss of private data to third parties that may be able to monitor such transmissions. Unencrypted mechanisms should be avoided.
本文件鼓励使用安全传输机制，防止私人数据丢失给能够监控此类传输的第三方。应避免使用未加密的机制。
In particular, a message that was originally encrypted or otherwise secured might appear in a report that is not sent securely, which could reveal private information.
特别是，最初加密或以其他方式保护的消息可能会出现在未安全发送的报告中，这可能会泄露私人信息。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[ABNF]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[AFRF] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012, <http://www.rfc-editor.org/info/rfc6591>.
[AFRF]Fontana，H.，“使用滥用报告格式的认证失败报告”，RFC 65912012年4月<http://www.rfc-editor.org/info/rfc6591>.
[AFRF-DKIM] Kucherawy, M., "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", RFC 6651, June 2012, <http://www.rfc-editor.org/info/rfc6651>.
[AFRF-DKIM]Kucherawy，M.，“用于故障报告的域密钥识别邮件（DKIM）扩展”，RFC 66512012年6月<http://www.rfc-editor.org/info/rfc6651>.
[AFRF-SPF] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, June 2012, <http://www.rfc-editor.org/info/rfc6652>.
[AFRF-SPF]Kitterman，S.，“使用滥用报告格式的发送方策略框架（SPF）身份验证失败报告”，RFC 66522012年6月<http://www.rfc-editor.org/info/rfc6652>.
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011, <http://www.rfc-editor.org/ info/rfc6376>.
[DKIM]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 63762011年9月<http://www.rfc-editor.org/ 信息/rfc6376>。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月<http://www.rfc-editor.org/info/rfc1035>.
[DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006, <http://www.rfc-editor.org/info/rfc4343>.
[DNS-CASE]Eastlake 3rd，D.，“域名系统（DNS）案例不敏感澄清”，RFC 43432006年1月<http://www.rfc-editor.org/info/rfc4343>.
[GZIP] Levine, J., "The 'application/zlib' and 'application/gzip' Media Types", RFC 6713, August 2012, <http://www.rfc-editor.org/info/rfc6713>.
[GZIP]Levine，J.，“应用程序/zlib”和“应用程序/GZIP”媒体类型”，RFC 6713，2012年8月<http://www.rfc-editor.org/info/rfc6713>.
[IDNA] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[IDNA]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月<http://www.rfc-editor.org/info/rfc5890>.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC5322，2008年10月<http://www.rfc-editor.org/info/rfc5322>.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[MIME]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月<http://www.rfc-editor.org/info/rfc2045>.
[SEC-TERMS] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[SEC-TERMS]Shirey，R.，“互联网安全术语表，第2版”，第36期，RFC 49492007年8月<http://www.rfc-editor.org/info/rfc4949>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月<http://www.rfc-editor.org/info/rfc5321>.
[SPF] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, April 2014, <http://www.rfc-editor.org/info/rfc7208>.
[SPF]Kitterman，S.，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 7208，2014年4月<http://www.rfc-editor.org/info/rfc7208>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009, <http://www.rfc-editor.org/info/rfc5617>.
[ADSP]Allman，E.，Fenton，J.，Delany，M.，和J.Levine，“域密钥识别邮件（DKIM）作者域签名实践（ADSP）”，RFC 56172009年8月<http://www.rfc-editor.org/info/rfc5617>.
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010, <http://www.rfc-editor.org/info/rfc5965>.
[ARF]Shafranovich，Y.，Levine，J.，和M.Kucherawy，“电子邮件反馈报告的可扩展格式”，RFC 59652010年8月<http://www.rfc-editor.org/info/rfc5965>.
[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013, <http://www.rfc-editor.org/info/rfc7001>.
[AUTH-RESULTS]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 70012013年9月<http://www.rfc-editor.org/info/rfc7001>.
[Best-Guess-SPF] Kitterman, S., "Sender Policy Framework: Best guess record (FAQ entry)", May 2010, <http://www.openspf.org/FAQ/Best_guess_record>.
[最佳猜测SPF]Kitterman，S.，“发件人策略框架：最佳猜测记录（常见问题条目）”，2010年5月<http://www.openspf.org/FAQ/Best_guess_record>.
[DKIM-DEPLOYMENT] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010, <http://www.rfc-editor.org/info/rfc5863>.
[DKIM-DEPLOYMENT]Hansen，T.，Siegel，E.，Hallam Baker，P.，和D.Crocker，“域密钥识别邮件（DKIM）开发、部署和运营”，RFC 58632010年5月<http://www.rfc-editor.org/info/rfc5863>.
[DKIM-LISTS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, September 2011, <http://www.rfc-editor.org/info/rfc6377>.
[DKIM-LISTS]Kucherawy，M.，“域密钥识别邮件（DKIM）和邮件列表”，BCP 167，RFC 6377，2011年9月<http://www.rfc-editor.org/info/rfc6377>.
[DKIM-OVERVIEW] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009, <http://www.rfc-editor.org/info/rfc5585>.
[DKIM-概述]Hansen，T.，Crocker，D.，和P.Hallam Baker，“域密钥识别邮件（DKIM）服务概述”，RFC 55852009年7月<http://www.rfc-editor.org/info/rfc5585>.
[DKIM-THREATS] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006, <http://www.rfc-editor.org/info/rfc4686>.
[DKIM-THREATS]Fenton，J.，“激励域密钥识别邮件（DKIM）的威胁分析”，RFC 46862006年9月<http://www.rfc-editor.org/info/rfc4686>.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[DNSSEC]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003, <http://www.rfc-editor.org/info/rfc3464>.
[DSN]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月<http://www.rfc-editor.org/info/rfc3464>.
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月<http://www.rfc-editor.org/info/rfc5598>.
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[IANA注意事项]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[ROLES] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997, <http://www.rfc-editor.org/info/rfc2142>.
[角色]Crocker，D.，“公共服务、角色和功能的邮箱名称”，RFC 2142，1997年5月<http://www.rfc-editor.org/info/rfc2142>.
This section documents some design decisions that were made in the development of DMARC. Specifically, addressed here are some suggestions that were considered but not included in the design. This text is included to explain why they were considered and not included in this version.
本节记录了在DMARC开发过程中做出的一些设计决策。具体而言，此处提出了一些已考虑但未包含在设计中的建议。本文本旨在解释本版本中考虑和不考虑这些内容的原因。
S/MIME, or Secure Multipurpose Internet Mail Extensions, is a standard for encryption and signing of MIME data in a message. This was suggested and considered as a third security protocol for authenticating the source of a message.
S/MIME，或安全多用途Internet邮件扩展，是消息中MIME数据加密和签名的标准。这被认为是验证消息源的第三个安全协议。
DMARC is focused on authentication at the domain level (i.e., the Domain Owner taking responsibility for the message), while S/MIME is really intended for user-to-user authentication and encryption. This alone appears to make it a bad fit for DMARC's goals.
DMARC专注于域级别的身份验证（即，负责消息的域所有者），而S/MIME实际上用于用户对用户的身份验证和加密。单凭这一点似乎就不适合DMARC的目标。
S/MIME also suffers from the heavyweight problem of Public Key Infrastructure, which means that distribution of keys used to verify signatures needs to be incorporated. In many instances, this alone is a showstopper. There have been consistent promises that PKI usability and deployment will improve, but these have yet to materialize. DMARC can revisit this choice after those barriers are addressed.
S/MIME还面临公钥基础设施的重量级问题，这意味着需要合并用于验证签名的密钥分发。在许多情况下，这一点本身就是一个障碍。人们一直承诺PKI的可用性和部署将得到改善，但这些承诺尚未实现。在解决这些障碍后，DMARC可以重新考虑这一选择。
S/MIME has extensive deployment in specific market segments (government, for example) but does not enjoy similar widespread deployment over the general Internet, and this shows no signs of changing. DKIM and SPF both are deployed widely over the general Internet, and their adoption rates continue to be positive.
S/MIME在特定的市场领域（例如政府部门）有广泛的部署，但在普通互联网上没有类似的广泛部署，这没有改变的迹象。DKIM和SPF都在通用互联网上广泛部署，它们的采用率继续保持正增长。
Finally, experiments have shown that including S/MIME support in the initial version of DMARC would neither cause nor enable a substantial increase in the accuracy of the overall mechanism.
最后，实验表明，在DMARC的初始版本中包含S/MIME支持既不会导致也无法大幅提高整个机制的准确性。
It was suggested that DMARC include a mechanism by which a Domain Owner could tell Message Receivers not to attempt validation by one of the supported methods (e.g., "check DKIM, but not SPF").
有人建议，DMARC包括一种机制，通过该机制，域所有者可以告诉消息接收者不要尝试使用支持的方法之一进行验证（例如，“检查DKIM，但不要检查SPF”）。
Specifically, consider a Domain Owner that has deployed one of the technologies, and that technology fails for some messages, but such failures don't cause enforcement action. Deploying DMARC would cause enforcement action for policies other than "none", which would appear to exclude participation by that Domain Owner.
具体地，考虑已经部署了其中一种技术的域所有者，并且该技术对某些消息失败，但是这样的故障不会导致强制执行。部署DMARC将导致除“无”之外的其他策略的强制执行操作，这似乎排除了该域所有者的参与。
The DMARC development team evaluated the idea of policy exception mechanisms on several occasions and invariably concluded that there was not a strong enough use case to include them. The specific target audience for DMARC does not appear to have concerns about the failure modes of one or the other being a barrier to DMARC's adoption.
DMARC开发团队多次评估了策略异常机制的想法，并一致认为没有足够强大的用例来包含它们。DMARC的特定目标受众似乎并不担心一种或另一种故障模式会阻碍DMARC的采用。
In the scenario described above, the Domain Owner has a few options:
在上述场景中，域所有者有几个选项：
1. Tighten up its infrastructure to minimize the failure modes of the single deployed technology.
1. 加强其基础设施，以最大限度地减少单一部署技术的故障模式。
2. Deploy the other supported authentication mechanism, to offset the failure modes of the first.
2. 部署另一个受支持的身份验证机制，以抵消第一个机制的故障模式。
3. Deploy DMARC in a reporting-only mode.
3. 以仅报告模式部署DMARC。
It has been suggested in several message authentication efforts that the Sender header field be checked for an identifier of interest, as the standards indicate this as the proper way to indicate a re-mailing of content such as through a mailing list. Most recently, it was a protocol-level option for DomainKeys, but on evolution to DKIM, this property was removed.
在一些消息认证工作中，建议检查发送者头部字段是否有感兴趣的标识符，因为标准表明这是指示内容重新邮寄（如通过邮件列表）的正确方式。最近，它是域密钥的协议级选项，但在进化到DKIM时，该属性被删除。
The DMARC development team considered this and decided not to include support for doing so, for the following reasons:
DMARC开发团队考虑了这一点，并决定不提供支持，原因如下：
1. The main user protection approach is to be concerned with what the user sees when a message is rendered. There is no consistent behavior among MUAs regarding what to do with the content of the Sender field, if present. Accordingly, supporting checking of the Sender identifier would mean applying policy to an identifier
1. 主要的用户保护方法是关注用户在呈现消息时看到的内容。MUA之间对于如何处理发送者字段（如果存在）的内容没有一致的行为。因此，支持检查发送者标识符将意味着对标识符应用策略
the end user might never actually see, which can create a vector for attack against end users by simply forging a Sender field containing some identifier that DMARC will like.
最终用户可能永远看不到，这会创建一个针对最终用户的攻击向量，只需伪造一个包含DMARC喜欢的标识符的发送者字段。
2. Although it is certainly true that this is what the Sender field is for, its use in this way is also unreliable, making it a poor candidate for inclusion in the DMARC evaluation algorithm.
2. 尽管发送方字段的用途确实如此，但它在这种情况下的使用也不可靠，这使得它很难包含在DMARC评估算法中。
3. Allowing multiple ways to discover policy introduces unacceptable ambiguity into the DMARC evaluation algorithm in terms of which policy is to be applied and when.
3. 允许以多种方式发现策略会在DMARC评估算法中引入不可接受的模糊性，即应用哪种策略以及何时应用。
A common practice among MTA operators, and indeed one documented in [ADSP], is a test to determine domain existence prior to any more expensive processing. This is typically done by querying the DNS for MX, A, or AAAA resource records for the name being evaluated and assuming that the domain is nonexistent if it could be determined that no such records were published for that domain name.
MTA运营商中的一个常见做法，实际上也是[ADSP]中记录的做法，是在任何更昂贵的处理之前，先进行测试以确定域的存在。这通常是通过在DNS中查询要评估的名称的MX、A或AAAA资源记录，并假设该域名不存在（如果可以确定该域名没有发布此类记录）。
The original pre-standardization version of this protocol included a mandatory check of this nature. It was ultimately removed, as the method's error rate was too high without substantial manual tuning and heuristic work. There are indeed use cases this work needs to address where such a method would return a negative result about a domain for which reporting is desired, such as a registered domain name that never sends legitimate mail and thus has none of these records present in the DNS.
本协议的原始预标准化版本包括这种性质的强制性检查。它最终被删除，因为该方法的错误率太高，没有大量的手动调整和启发式工作。这项工作确实需要解决一些用例，在这些用例中，这种方法会返回有关需要报告的域的负面结果，例如，注册域名从未发送合法邮件，因此DNS中没有这些记录。
DMARC has been characterized as a "super-ADSP" of sorts.
DMARC被描述为某种“超级ADSP”。
Contributors to DMARC have compiled a list of issues associated with ADSP, gained from operational experience, that have influenced the direction of DMARC:
DMARC的撰稿人已编制了一份与ADSP相关的问题清单，这些问题是从运营经验中获得的，影响了DMARC的发展方向：
1. ADSP has no support for subdomains, i.e., the ADSP record for example.com does not explicitly or implicitly apply to subdomain.example.com. If wildcarding is not applied, then spammers can trivially bypass ADSP by sending from a subdomain with no ADSP record.
1. ADSP不支持子域，即example.com的ADSP记录不显式或隐式应用于subdomain.example.com。如果未应用通配符，则垃圾邮件发送者可以通过从没有ADSP记录的子域发送来绕过ADSP。
2. Nonexistent subdomains are explicitly out of scope in ADSP. There is nothing in ADSP that states receivers should simply reject mail from NXDOMAINs regardless of ADSP policy (which of course allows spammers to trivially bypass ADSP by sending email from nonexistent subdomains).
2. 不存在的子域在ADSP中显式超出范围。ADSP中没有规定接收者应该拒绝来自NXDOMAINs的邮件，而不考虑ADSP策略（当然，这允许垃圾邮件发送者通过从不存在的子域发送电子邮件来绕过ADSP）。
3. ADSP has no operational advice on when to look up the ADSP record.
3. ADSP没有关于何时查找ADSP记录的操作建议。
4. ADSP has no support for using SPF as an auxiliary mechanism to DKIM.
4. ADSP不支持使用SPF作为DKIM的辅助机制。
5. ADSP has no support for a slow rollout, i.e., no way to configure a percentage of email on which the receiver should apply the policy. This is important for large-volume senders.
5. ADSP不支持缓慢推出，即无法配置收件人应应用策略的电子邮件百分比。这对于大容量发送器非常重要。
6. ADSP has no explicit support for an intermediate phase where the receiver quarantines (e.g., sends to the recipient's "spam" folder) rather than rejects the email.
6. ADSP不明确支持中间阶段，即收件人隔离（例如，发送到收件人的“垃圾邮件”文件夹）而不是拒绝电子邮件。
7. The binding between the "From" header domain and DKIM is too tight for ADSP; they must match exactly.
7. “From”头域与DKIM的绑定对于ADSP来说太紧；它们必须完全匹配。
Although protocols like ADSP are useful for "protecting" a specific domain name, they are not helpful at protecting subdomains. If one wished to protect "example.com" by requiring via ADSP that all mail bearing an RFC5322.From domain of "example.com" be signed, this would "protect" that domain; however, one could then craft an email whose RFC5322.From domain is "security.example.com", and ADSP would not provide any protection. One could use a DNS wildcard, but this can undesirably interfere with other DNS activity; one could add ADSP records as fraudulent domains are discovered, but this solution does not scale and is a purely reactive measure against abuse.
虽然像ADSP这样的协议对于“保护”特定域名很有用，但对于保护子域却没有帮助。如果有人希望通过ADSP要求所有带有RFC5322.From域“example.com”的邮件都要签名来保护“example.com”，这将“保护”该域；然而，人们可以手工制作一封电子邮件，其RFC5322.From域是“security.example.com”，而ADSP不会提供任何保护。可以使用DNS通配符，但这可能会干扰其他DNS活动；可以在发现欺诈性域时添加ADSP记录，但此解决方案不可扩展，只是针对滥用的纯反应性措施。
The DNS does not provide a method by which the "domain of record", or the domain that was actually registered with a domain registrar, can be determined given an arbitrary domain name. Suggestions have been made that attempt to glean such information from SOA or NS resource records, but these too are not fully reliable, as the partitioning of the DNS is not always done at administrative boundaries.
DNS不提供一种方法，通过该方法，可以在给定任意域名的情况下确定“记录域”或实际向域注册器注册的域。有人建议尝试从SOA或NS资源记录中收集此类信息，但这些信息也不完全可靠，因为DNS的分区并不总是在管理边界上完成。
When seeking domain-specific policy based on an arbitrary domain name, one could "climb the tree", dropping labels off the left end of the name until the root is reached or a policy is discovered, but then one could craft a name that has a large number of nonsense
在基于任意域名寻求特定于域的策略时，可以“爬树”，在到达根或发现策略之前从名称的左端除去标签，但随后可以创建一个包含大量无意义内容的名称
labels; this would cause a Mail Receiver to attempt a large number of queries in search of a policy record. Sending many such messages constitutes an amplified denial-of-service attack.
标签；这将导致邮件接收者在搜索策略记录时尝试大量查询。发送许多这样的消息构成了一种扩大的拒绝服务攻击。
The Organizational Domain mechanism is a necessary component to the goals of DMARC. The method described in Section 3.2 is far from perfect but serves this purpose reasonably well without adding undue burden or semantics to the DNS. If a method is created to do so that is more reliable and secure than the use of a public suffix list, DMARC should be amended to use that method as soon as it is generally available.
组织域机制是DMARC目标的必要组成部分。第3.2节中描述的方法远非完美，但在不给DNS增加不适当的负担或语义的情况下，可以很好地实现这一目的。如果创建的方法比使用公共后缀列表更可靠、更安全，则应修改DMARC，以便在该方法普遍可用时尽快使用该方法。
A public suffix list for the purposes of determining the Organizational Domain can be obtained from various sources. The most common one is maintained by the Mozilla Foundation and made public at <http://publicsuffix.org>. License terms governing the use of that list are available at that URI.
可以从各种来源获得用于确定组织域的公共后缀列表。最常见的一个是由Mozilla基金会维护并在http://publicsuffix.org>. 管理该列表使用的许可条款在该URI上可用。
Note that if operators use a variety of public suffix lists, interoperability will be difficult or impossible to guarantee.
请注意，如果运营商使用各种公共后缀列表，互操作性将难以或不可能保证。
This section illustrates both the Domain Owner side and the Mail Receiver side of a DMARC exchange.
本节说明了DMARC exchange的域所有者端和邮件接收方端。
The following examples illustrate the DMARC mechanism's use of Identifier Alignment. For brevity's sake, only message headers are shown, as message bodies are not considered when conducting DMARC checks.
以下示例说明了DMARC机制对标识符对齐的使用。为简洁起见，只显示消息头，因为在执行DMARC检查时不考虑消息体。
The following SPF examples assume that SPF produces a passing result.
下面的SPF示例假定SPF生成通过的结果。
Example 1: SPF in alignment:
示例1：对齐的SPF：
MAIL FROM: <sender@example.com>
MAIL FROM: <sender@example.com>
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the RFC5321.MailFrom parameter and the RFC5322.From field have identical DNS domains. Thus, the identifiers are in alignment.
在本例中，RFC5321.MailFrom参数和RFC5322.From字段具有相同的DNS域。因此，标识符是对齐的。
Example 2: SPF in alignment (parent):
示例2：对齐的SPF（父项）：
MAIL FROM: <sender@child.example.com>
MAIL FROM: <sender@child.example.com>
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the RFC5322.From parameter includes a DNS domain that is a parent of the RFC5321.MailFrom domain. Thus, the identifiers are in alignment if relaxed SPF mode is requested by the Domain Owner, and not in alignment if strict SPF mode is requested.
在这种情况下，RFC5322.From参数包括一个DNS域，该域是RFC5321.MailFrom域的父域。因此，如果域所有者请求放松SPF模式，则标识符对齐，而如果请求严格SPF模式，则标识符不对齐。
Example 3: SPF not in alignment:
示例3：SPF未对齐：
MAIL FROM: <sender@example.net>
MAIL FROM: <sender@example.net>
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the RFC5321.MailFrom parameter includes a DNS domain that is neither the same as nor a parent of the RFC5322.From domain. Thus, the identifiers are not in alignment.
在这种情况下，RFC5321.MailFrom参数包含一个DNS域，该域既不与RFC5322.From域相同，也不是它的父域。因此，标识符没有对齐。
The examples below assume that the DKIM signatures pass verification. Alignment cannot exist with a DKIM signature that does not verify.
以下示例假设DKIM签名通过验证。无法使用未验证的DKIM签名存在对齐。
Example 1: DKIM in alignment:
示例1：对齐的DKIM：
DKIM-Signature: v=1; ...; d=example.com; ...
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
DKIM-Signature: v=1; ...; d=example.com; ...
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the DKIM "d=" parameter and the RFC5322.From field have identical DNS domains. Thus, the identifiers are in alignment.
在这种情况下，DKIM“d=”参数和RFC5322.From字段具有相同的DNS域。因此，标识符是对齐的。
Example 2: DKIM in alignment (parent):
示例2：对齐中的DKIM（父级）：
DKIM-Signature: v=1; ...; d=example.com; ...
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
DKIM-Signature: v=1; ...; d=example.com; ...
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the DKIM signature's "d=" parameter includes a DNS domain that is a parent of the RFC5322.From domain. Thus, the identifiers are in alignment for relaxed mode, but not for strict mode.
在这种情况下，DKIM签名的“d=”参数包括一个DNS域，该域是RFC5322.From域的父域。因此，标识符与放松模式对齐，但与严格模式对齐。
Example 3: DKIM not in alignment:
示例3:DKIM未对齐：
DKIM-Signature: v=1; ...; d=sample.net; ...
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
DKIM-Signature: v=1; ...; d=sample.net; ...
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the DKIM signature's "d=" parameter includes a DNS domain that is neither the same as nor a parent of the RFC5322.From domain. Thus, the identifiers are not in alignment.
在这种情况下，DKIM签名的“d=”参数包括一个DNS域，该域既不与RFC5322.From域相同，也不是它的父域。因此，标识符没有对齐。
A Domain Owner that wants to use DMARC should have already deployed and tested SPF and DKIM. The next step is to publish a DNS record that advertises a DMARC policy for the Domain Owner's Organizational Domain.
想要使用DMARC的域所有者应该已经部署并测试了SPF和DKIM。下一步是发布为域所有者的组织域播发DMARC策略的DNS记录。
The owner of the domain "example.com" has deployed SPF and DKIM on its messaging infrastructure. The owner wishes to begin using DMARC with a policy that will solicit aggregate feedback from receivers without affecting how the messages are processed, in order to:
域“example.com”的所有者在其消息传递基础设施上部署了SPF和DKIM。所有者希望在开始使用DMARC时使用一种策略，该策略将在不影响消息处理方式的情况下征求接收者的总体反馈，以便：
o Confirm that its legitimate messages are authenticating correctly
o 确认其合法消息正在正确验证
o Verify that all authorized message sources have implemented authentication measures
o 验证所有授权消息源是否已实施身份验证措施
o Determine how many messages from other sources would be affected by a blocking policy
o 确定有多少来自其他来源的邮件会受到阻止策略的影响
The Domain Owner accomplishes this by constructing a policy record indicating that:
域所有者通过构造一个策略记录来实现这一点，该记录指示：
o The version of DMARC being used is "DMARC1" ("v=DMARC1")
o 使用的DMARC版本为“DMARC1”（“v=DMARC1”）
o Receivers should not alter how they treat these messages because of this DMARC policy record ("p=none")
o 接收方不应因为此DMARC策略记录（“p=none”）而改变其处理这些消息的方式
o Aggregate feedback reports should be sent via email to the address "dmarc-feedback@example.com" ("rua=mailto:dmarc-feedback@example.com")
o 汇总反馈报告应通过电子邮件发送至地址“dmarc-feedback@example.com（“rua=mailto:dmarc-feedback@example.com")
o All messages from this Organizational Domain are subject to this policy (no "pct" tag present, so the default of 100% applies)
o 来自此组织域的所有邮件均受此策略约束（不存在“pct”标记，因此默认值为100%）
The DMARC policy record might look like this when retrieved using a common command-line tool:
使用通用命令行工具检索DMARC策略记录时，可能如下所示：
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"
To publish such a record, the DNS administrator for the Domain Owner creates an entry like the following in the appropriate zone file (following the conventional zone file format):
要发布此类记录，域所有者的DNS管理员将在适当的区域文件中创建一个条目，如下所示（遵循常规区域文件格式）：
; DMARC record for the domain example.com
; 域example.com的DMARC记录
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com" )
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com" )
The Domain Owner from the previous example has used the aggregate reporting to discover some messaging systems that had not yet implemented DKIM correctly, but they are still seeing periodic authentication failures. In order to diagnose these intermittent problems, they wish to request per-message failure reports when authentication failures occur.
上一个示例中的域所有者使用聚合报告发现了一些尚未正确实现DKIM的消息传递系统，但它们仍然会看到周期性的身份验证失败。为了诊断这些间歇性问题，他们希望在发生身份验证故障时请求每条消息的故障报告。
Not all Receivers will honor such a request, but the Domain Owner feels that any reports it does receive will be helpful enough to justify publishing this record. The default per-message report format ([AFRF]) meets the Domain Owner's needs in this scenario.
并非所有接收者都会接受这样的请求，但域所有者认为，它确实收到的任何报告都将有助于证明发布此记录的合理性。默认的每消息报告格式（[AFRF]）满足此场景中域所有者的需要。
The Domain Owner accomplishes this by adding the following to its policy record from Appendix B.2:
域所有者通过将以下内容添加到附录B.2中的策略记录中来实现此目的：
o Per-message failure reports should be sent via email to the address "auth-reports@example.com" ("ruf=mailto:auth-reports@example.com")
o 每封邮件的失败报告应通过电子邮件发送至地址“auth”-reports@example.com（“ruf=mailto:auth-reports@example.com")
The DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):
当使用通用命令行工具检索DMARC策略记录时，其外观可能如下所示（显示的输出将显示在单行上，但包装在此处以供发布）：
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
ruf=mailto:auth-reports@example.com"
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
ruf=mailto:auth-reports@example.com"
To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):
要发布此类记录，域所有者的DNS管理员可能会在适当的区域文件中创建如下条目（遵循传统区域文件格式）：
; DMARC record for the domain example.com
; 域example.com的DMARC记录
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@example.com" )
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@example.com" )
The Domain Owner from the previous example is maintaining the same policy but now wishes to have a third party receive and process the per-message failure reports. Again, not all Receivers will honor this request, but those that do may implement additional checks to validate that the third party wishes to receive the failure reports for this domain.
上一示例中的域所有者正在维护相同的策略，但现在希望有第三方接收并处理每消息失败报告。同样，并非所有接收者都会接受此请求，但那些接受此请求的接收者可能会执行额外的检查，以验证第三方是否希望接收此域的故障报告。
The Domain Owner needs to alter its policy record from Appendix B.2.2 as follows:
域所有者需要更改附录B.2.2中的策略记录，如下所示：
o Per-message failure reports should be sent via email to the address "auth-reports@thirdparty.example.net" ("ruf=mailto:auth-reports@thirdparty.example.net")
o 每封邮件的失败报告应通过电子邮件发送至地址“auth”-reports@thirdparty.example.net（“ruf=mailto:auth-reports@thirdparty.example.net")
The DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):
当使用通用命令行工具检索DMARC策略记录时，其外观可能如下所示（显示的输出将显示在单行上，但包装在此处以供发布）：
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
ruf=mailto:auth-reports@thirdparty.example.net"
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
ruf=mailto:auth-reports@thirdparty.example.net"
To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):
要发布此类记录，域所有者的DNS管理员可能会在适当的区域文件中创建如下条目（遵循传统区域文件格式）：
; DMARC record for the domain example.com
; 域example.com的DMARC记录
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@thirdparty.example.net" )
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@thirdparty.example.net" )
Because the address used in the "ruf" tag is outside the Organizational Domain in which this record is published, conforming Receivers will implement additional checks as described in Section 7.1 of this document. In order to pass these additional checks, the third party will need to publish an additional DNS record as follows:
由于“ruf”标签中使用的地址不在发布该记录的组织域内，合格接收人将按照本文件第7.1节的规定进行额外检查。为了通过这些附加检查，第三方需要发布附加DNS记录，如下所示：
o Given the DMARC record published by the Domain Owner at "_dmarc.example.com", the DNS administrator for the third party will need to publish a TXT resource record at "example.com._report._dmarc.thirdparty.example.net" with the value "v=DMARC1".
o 给定域所有者在“\u DMARC.example.com”上发布的DMARC记录，第三方的DNS管理员需要在“example.com.\u report.\u DMARC.thirdparty.example.net”上发布一个值为“v=DMARC1”的TXT资源记录。
The resulting DNS record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):
使用通用命令行工具检索时，生成的DNS记录可能如下所示（显示的输出将显示在一行上，但包装在此处以供发布）：
% dig +short TXT example.com._report._dmarc.thirdparty.example.net "v=DMARC1"
%dig+short TXT example.com.\u report.\u dmarc.thirdparty.example.net“v=DMARC1”
To publish such a record, the DNS administrator for example.net might create an entry like the following in the appropriate zone file (following the conventional zone file format):
要发布此类记录，DNS管理员（例如.net）可能会在适当的区域文件中创建如下条目（遵循传统的区域文件格式）：
; zone file for thirdparty.example.net ; Accept DMARC failure reports on behalf of example.com
; thirdparty.example.net的区域文件；代表example.com接受DMARC故障报告
example.com._report._dmarc IN TXT "v=DMARC1"
example.com._report._dmarc在TXT“v=DMARC1”中
Intermediaries and other third parties should refer to Section 7.1 for the full details of this mechanism.
中介机构和其他第三方应参考第7.1节了解该机制的全部细节。
The Domain Owner has implemented SPF and DKIM in a subdomain used for pre-production testing of messaging services. It now wishes to request that participating receivers act to reject messages from this subdomain that fail to authenticate.
域所有者已在用于消息服务预生产测试的子域中实现SPF和DKIM。现在，它希望请求参与的接收者采取行动，拒绝来自该子域的未通过身份验证的消息。
As a first step, it will ask that a portion (1/4 in this example) of failing messages be quarantined, enabling examination of messages sent to mailboxes hosted by participating receivers. Aggregate feedback reports will be sent to a mailbox within the Organizational Domain, and to a mailbox at a third party selected and authorized to receive same by the Domain Owner. Aggregate reports sent to the third party are limited to a maximum size of ten megabytes.
作为第一步，它将要求隔离失败邮件的一部分（本例中为1/4），以便能够检查发送到参与接收方托管的邮箱的邮件。聚合反馈报告将发送到组织域内的邮箱，以及域所有者选择并授权接收该报告的第三方的邮箱。发送给第三方的聚合报告的最大大小限制为10 MB。
The Domain Owner will accomplish this by constructing a policy record indicating that:
域所有者将通过构造一个策略记录来完成此任务，该策略记录指示：
o The version of DMARC being used is "DMARC1" ("v=DMARC1")
o 使用的DMARC版本为“DMARC1”（“v=DMARC1”）
o It is applied only to this subdomain (record is published at "_dmarc.test.example.com" and not "_dmarc.example.com")
o 它仅适用于此子域（记录发布在“\u dmarc.test.example.com”而不是“\u dmarc.example.com”）
o Receivers should quarantine messages from this Organizational Domain that fail to authenticate ("p=quarantine")
o 接收方应隔离来自此组织域的未通过身份验证的邮件（“p=隔离”）
o Aggregate feedback reports should be sent via email to the addresses "dmarc-feedback@example.com" and "example-tld-test@thirdparty.example.net", with the latter subjected to a maximum size limit ("rua=mailto:dmarc-feedback@ example.com,mailto:tld-test@thirdparty.example.net!10m")
o 聚合反馈报告应通过电子邮件发送至“dmarc”地址-feedback@example.com“和”示例tld-test@thirdparty.example.net，后者受最大大小限制（“rua=mailto:dmarc feedback@example.com，mailto:tld-test@thirdparty.example.net！10米）
o 25% of messages from this Organizational Domain are subject to action based on this policy ("pct=25")
o 来自此组织域的25%的邮件将根据此策略采取行动（“pct=25”）
The DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):
当使用通用命令行工具检索DMARC策略记录时，其外观可能如下所示（显示的输出将显示在单行上，但包装在此处以供发布）：
% dig +short TXT _dmarc.test.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com,
mailto:tld-test@thirdparty.example.net!10m; pct=25"
% dig +short TXT _dmarc.test.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com,
mailto:tld-test@thirdparty.example.net!10m; pct=25"
To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file:
要发布此类记录，域所有者的DNS管理员可能会在相应的区域文件中创建一个类似以下内容的条目：
; DMARC record for the domain example.com
; 域example.com的DMARC记录
_dmarc IN TXT ( "v=DMARC1; p=quarantine; "
"rua=mailto:dmarc-feedback@example.com,"
"mailto:tld-test@thirdparty.example.net!10m; "
"pct=25" )
_dmarc IN TXT ( "v=DMARC1; p=quarantine; "
"rua=mailto:dmarc-feedback@example.com,"
"mailto:tld-test@thirdparty.example.net!10m; "
"pct=25" )
A Mail Receiver that wants to use DMARC should already be checking SPF and DKIM, and possess the ability to collect relevant information from various email-processing stages to provide feedback to Domain Owners (possibly via Report Receivers).
想要使用DMARC的邮件接收者应该已经在检查SPF和DKIM，并且能够从各个电子邮件处理阶段收集相关信息，以便向域所有者提供反馈（可能通过报告接收者）。
An optimal DMARC-enabled Mail Receiver performs authentication and Identifier Alignment checking during the [SMTP] conversation.
在[SMTP]对话期间，启用DMARC的最佳邮件接收器执行身份验证和标识符对齐检查。
Prior to returning a final reply to the DATA command, the Mail Receiver's MTA has performed:
在返回对DATA命令的最终答复之前，邮件收件人的MTA已执行以下操作：
1. An SPF check to determine an SPF-authenticated Identifier.
1. 用于确定SPF身份验证标识符的SPF检查。
2. DKIM checks that yield one or more DKIM-authenticated Identifiers.
2. DKIM检查生成一个或多个DKIM身份验证标识符。
3. A DMARC policy lookup.
3. DMARC策略查找。
The presence of an Author Domain DMARC record indicates that the Mail Receiver should continue with DMARC-specific processing before returning a reply to the DATA command.
如果存在作者域DMARC记录，则表明邮件接收者应在返回对数据命令的答复之前继续进行DMARC特定的处理。
Given a DMARC record and the set of Authenticated Identifiers, the Mail Receiver checks to see if the Authenticated Identifiers align with the Author Domain (taking into consideration any strict versus relaxed options found in the DMARC record).
给定一个DMARC记录和一组经过身份验证的标识符，邮件接收者将检查经过身份验证的标识符是否与作者域对齐（考虑DMARC记录中的任何严格与宽松选项）。
For example, the following sample data is considered to be from a piece of email originating from the Domain Owner of "example.com":
例如，以下示例数据被视为来自“example.com”域所有者的一封电子邮件：
Author Domain: example.com
SPF-authenticated Identifier: mail.example.com
DKIM-authenticated Identifier: example.com
DMARC record:
"v=DMARC1; p=reject; aspf=r;
rua=mailto:dmarc-feedback@example.com"
Author Domain: example.com
SPF-authenticated Identifier: mail.example.com
DKIM-authenticated Identifier: example.com
DMARC record:
"v=DMARC1; p=reject; aspf=r;
rua=mailto:dmarc-feedback@example.com"
In the above sample, both the SPF-authenticated Identifier and the DKIM-authenticated Identifier align with the Author Domain. The Mail Receiver considers the above email to pass the DMARC check, avoiding the "reject" policy that is to be applied to email that fails to pass the DMARC check.
在上面的示例中，SPF身份验证标识符和DKIM身份验证标识符都与作者域对齐。邮件接收人认为上述电子邮件通过了DMARC检查，从而避免了应用于无法通过DMARC检查的电子邮件的“拒绝”策略。
If no Authenticated Identifiers align with the Author Domain, then the Mail Receiver applies the DMARC-record-specified policy. However, before this action is taken, the Mail Receiver can consult external information to override the Domain Owner's policy. For example, if the Mail Receiver knows that this particular email came from a known and trusted forwarder (that happens to break both SPF and DKIM), then the Mail Receiver may choose to ignore the Domain Owner's policy.
如果没有经过身份验证的标识符与作者域对齐，则邮件接收方将应用指定的DMARC记录策略。但是，在执行此操作之前，邮件接收者可以查阅外部信息以覆盖域所有者的策略。例如，如果邮件接收者知道此特定电子邮件来自已知且受信任的转发器（这恰好破坏了SPF和DKIM），则邮件接收者可能会选择忽略域所有者的策略。
The Mail Receiver is now ready to reply to the DATA command. If the DMARC check yields that the message is to be rejected, then the Mail Receiver replies with a 5xy code to inform the sender of failure. If the DMARC check cannot be resolved due to transient network errors, then the Mail Receiver replies with a 4xy code to inform the sender as to the need to reattempt delivery later. If the DMARC check yields a passing message, then the Mail Receiver continues on with email processing, perhaps using the result of the DMARC check as an input to additional processing modules such as a domain reputation query.
邮件接收者现在可以回复数据命令了。如果DMARC检查结果表明邮件将被拒绝，则邮件接收者将用5xy代码回复，以通知发送者失败。如果DMARC检查由于暂时的网络错误而无法解决，则邮件接收者会用4xy代码回复，通知发送者需要稍后重新尝试投递。如果DMARC检查产生传递的消息，则邮件接收者继续进行电子邮件处理，可能使用DMARC检查的结果作为其他处理模块（如域信誉查询）的输入。
Before exiting DMARC-specific processing, the Mail Receiver checks to see if the Author Domain DMARC record requests AFRF-based reporting. If so, then the Mail Receiver can emit an AFRF to the reporting address supplied in the DMARC record.
在退出特定于DMARC的处理之前，邮件接收者会检查作者域DMARC记录是否请求基于AFRF的报告。如果是这样，那么邮件接收者可以向DMARC记录中提供的报告地址发送AFRF。
At the exit of DMARC-specific processing, the Mail Receiver captures (through logging or direct insertion into a data store) the result of DMARC processing. Captured information is used to build feedback for Domain Owner consumption. This is not necessary if the Domain Owner has not requested aggregate reports, i.e., no "rua" tag was found in the policy record.
在DMARC特定处理的出口处，邮件接收器（通过记录或直接插入数据存储）捕获DMARC处理的结果。捕获的信息用于为域所有者消费构建反馈。如果域所有者未请求聚合报告，即在策略记录中未找到“rua”标记，则无需执行此操作。
Aggregate feedback is consumed by Domain Owners to verify a Domain Owner's understanding of how the Domain Owner's domain is being processed by the Mail Receiver. Aggregate reporting data on emails that pass all DMARC-supporting authentication checks is used by Domain Owners to verify that authentication practices remain accurate. For example, if a third party is sending on behalf of a Domain Owner, the Domain Owner can use aggregate report data to verify ongoing authentication practices of the third party.
域所有者使用聚合反馈来验证域所有者对邮件接收者如何处理域所有者的域的理解。域所有者使用通过所有DMARC支持的身份验证检查的电子邮件上的聚合报告数据来验证身份验证实践是否准确。例如，如果第三方代表域所有者发送，域所有者可以使用聚合报告数据来验证第三方正在进行的身份验证实践。
Data on email that only partially passes underlying authentication checks provides visibility into problems that need to be addressed by the Domain Owner. For example, if either SPF or DKIM fails to pass, the Domain Owner is provided with enough information to either directly correct the problem or understand where authentication-breaking changes are being introduced in the email transmission path. If authentication-breaking changes due to email transmission path cannot be directly corrected, then the Domain Owner at least maintains an understanding of the effect of DMARC-based policies upon the Domain Owner's email.
电子邮件中仅部分通过基础身份验证检查的数据提供了对需要由域所有者解决的问题的可见性。例如，如果SPF或DKIM未能通过，则向域所有者提供足够的信息，以直接纠正问题或了解在电子邮件传输路径中引入了破坏身份验证的更改的位置。如果由于电子邮件传输路径导致的身份验证中断更改无法直接更正，则域所有者至少了解基于DMARC的策略对域所有者电子邮件的影响。
Data on email that fails all underlying authentication checks provides baseline visibility on how the Domain Owner's domain is being received at the Mail Receiver. Based on this visibility, the Domain Owner can begin deployment of authentication technologies across uncovered email sources. Additionally, the Domain Owner may come to an understanding of how its domain is being misused.
未通过所有基础身份验证检查的电子邮件上的数据提供了有关如何在邮件接收方接收域所有者的域的基线可见性。基于这种可见性，域所有者可以开始跨未覆盖的电子邮件源部署身份验证技术。此外，域名所有者可能会了解其域名是如何被滥用的。
A DMARC record can contain a "mailto" reporting address, such as:
DMARC记录可以包含“mailto”报告地址，例如：
mailto:dmarc-feedback@example.com
邮寄地址：dmarc-feedback@example.com
A sample aggregate report from the Mail Receiver at mail.receiver.example follows:
邮件接收者在Mail.Receiver.example的聚合报告示例如下：
DKIM-Signature: v=1; ...; d=mail.receiver.example; ...
From: dmarc-reporting@mail.receiver.example
Date: Fri, Feb 15 2002 16:54:30 -0800
To: dmarc-feedback@example.com
Subject: Report Domain: example.com
Submitter: mail.receiver.example
Report-ID: <2002.02.15.1>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
Content-Language: en-us
DKIM-Signature: v=1; ...; d=mail.receiver.example; ...
From: dmarc-reporting@mail.receiver.example
Date: Fri, Feb 15 2002 16:54:30 -0800
To: dmarc-feedback@example.com
Subject: Report Domain: example.com
Submitter: mail.receiver.example
Report-ID: <2002.02.15.1>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
Content-Language: en-us
This is a multipart message in MIME format.
这是MIME格式的多部分消息。
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
This is an aggregate report from mail.receiver.example.
这是来自mail.receiver.example的聚合报告。
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: application/gzip
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="mail.receiver.example!example.com!
1013662812!1013749130.gz"
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: application/gzip
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="mail.receiver.example!example.com!
1013662812!1013749130.gz"
<gzipped content of report>
<gzip报告内容>
------=_NextPart_000_024E_01CC9B0A.AFE54C00--
------=_NextPart_000_024E_01CC9B0A.AFE54C00--
Not shown in the above example is that the Mail Receiver's feedback should be authenticated using SPF. Also, the value of the "filename" MIME parameter is wrapped for printing in this specification but would normally appear as one continuous string.
上面的示例中没有显示邮件接收者的反馈应该使用SPF进行身份验证。此外，“filename”MIME参数的值在本规范中被包装以便打印，但通常显示为一个连续字符串。
The following is the proposed initial schema for producing XML-formatted aggregate reports as described in this document.
以下是用于生成本文档中所述的XML格式聚合报告的建议初始模式。
NOTE: Per the definition of XML, unless otherwise specified in the schema below, the minOccurs and maxOccurs values for each element are set to 1.
注意：根据XML的定义，除非下面的模式中另有规定，否则每个元素的minOccurs和maxOccurs值都设置为1。
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://dmarc.org/dmarc-xml/0.1">
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://dmarc.org/dmarc-xml/0.1">
<!-- The time range in UTC covered by messages in this report,
specified in seconds since epoch. -->
<xs:complexType name="DateRangeType">
<xs:all>
<xs:element name="begin" type="xs:integer"/>
<xs:element name="end" type="xs:integer"/>
</xs:all>
</xs:complexType>
<!-- The time range in UTC covered by messages in this report,
specified in seconds since epoch. -->
<xs:complexType name="DateRangeType">
<xs:all>
<xs:element name="begin" type="xs:integer"/>
<xs:element name="end" type="xs:integer"/>
</xs:all>
</xs:complexType>
<!-- Report generator metadata. -->
<xs:complexType name="ReportMetadataType">
<xs:sequence>
<xs:element name="org_name" type="xs:string"/>
<xs:element name="email" type="xs:string"/>
<xs:element name="extra_contact_info" type="xs:string"
minOccurs="0"/>
<xs:element name="report_id" type="xs:string"/>
<!-- Report generator metadata. -->
<xs:complexType name="ReportMetadataType">
<xs:sequence>
<xs:element name="org_name" type="xs:string"/>
<xs:element name="email" type="xs:string"/>
<xs:element name="extra_contact_info" type="xs:string"
minOccurs="0"/>
<xs:element name="report_id" type="xs:string"/>
<xs:element name="date_range" type="DateRangeType"/>
<xs:element name="error" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="date_range" type="DateRangeType"/>
<xs:element name="error" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- Alignment mode (relaxed or strict) for DKIM and SPF. -->
<xs:simpleType name="AlignmentType">
<xs:restriction base="xs:string">
<xs:enumeration value="r"/>
<xs:enumeration value="s"/>
</xs:restriction>
</xs:simpleType>
<!-- Alignment mode (relaxed or strict) for DKIM and SPF. -->
<xs:simpleType name="AlignmentType">
<xs:restriction base="xs:string">
<xs:enumeration value="r"/>
<xs:enumeration value="s"/>
</xs:restriction>
</xs:simpleType>
<!-- The policy actions specified by p and sp in the
DMARC record. -->
<xs:simpleType name="DispositionType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="quarantine"/>
<xs:enumeration value="reject"/>
</xs:restriction>
</xs:simpleType>
<!-- The policy actions specified by p and sp in the
DMARC record. -->
<xs:simpleType name="DispositionType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="quarantine"/>
<xs:enumeration value="reject"/>
</xs:restriction>
</xs:simpleType>
<!-- The DMARC policy that applied to the messages in
this report. -->
<xs:complexType name="PolicyPublishedType">
<xs:all>
<!-- The domain at which the DMARC record was found. -->
<xs:element name="domain" type="xs:string"/>
<!-- The DKIM alignment mode. -->
<xs:element name="adkim" type="AlignmentType"
minOccurs="0"/>
<!-- The SPF alignment mode. -->
<xs:element name="aspf" type="AlignmentType"
minOccurs="0"/>
<!-- The policy to apply to messages from the domain. -->
<xs:element name="p" type="DispositionType"/>
<!-- The policy to apply to messages from subdomains. -->
<xs:element name="sp" type="DispositionType"/>
<!-- The percent of messages to which policy applies. -->
<xs:element name="pct" type="xs:integer"/>
<!-- Failure reporting options in effect. -->
<xs:element name="fo" type="xs:string"/>
</xs:all>
</xs:complexType>
<!-- The DMARC policy that applied to the messages in
this report. -->
<xs:complexType name="PolicyPublishedType">
<xs:all>
<!-- The domain at which the DMARC record was found. -->
<xs:element name="domain" type="xs:string"/>
<!-- The DKIM alignment mode. -->
<xs:element name="adkim" type="AlignmentType"
minOccurs="0"/>
<!-- The SPF alignment mode. -->
<xs:element name="aspf" type="AlignmentType"
minOccurs="0"/>
<!-- The policy to apply to messages from the domain. -->
<xs:element name="p" type="DispositionType"/>
<!-- The policy to apply to messages from subdomains. -->
<xs:element name="sp" type="DispositionType"/>
<!-- The percent of messages to which policy applies. -->
<xs:element name="pct" type="xs:integer"/>
<!-- Failure reporting options in effect. -->
<xs:element name="fo" type="xs:string"/>
</xs:all>
</xs:complexType>
<!-- The DMARC-aligned authentication result. -->
<xs:simpleType name="DMARCResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
</xs:restriction>
</xs:simpleType>
<!-- The DMARC-aligned authentication result. -->
<xs:simpleType name="DMARCResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
</xs:restriction>
</xs:simpleType>
<!-- Reasons that may affect DMARC disposition or execution
thereof. -->
<xs:simpleType name="PolicyOverrideType">
<xs:restriction base="xs:string">
<xs:enumeration value="forwarded"/>
<xs:enumeration value="sampled_out"/>
<xs:enumeration value="trusted_forwarder"/>
<xs:enumeration value="mailing_list"/>
<xs:enumeration value="local_policy"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
<!-- Reasons that may affect DMARC disposition or execution
thereof. -->
<xs:simpleType name="PolicyOverrideType">
<xs:restriction base="xs:string">
<xs:enumeration value="forwarded"/>
<xs:enumeration value="sampled_out"/>
<xs:enumeration value="trusted_forwarder"/>
<xs:enumeration value="mailing_list"/>
<xs:enumeration value="local_policy"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
<!-- How do we allow report generators to include new
classes of override reasons if they want to be more
specific than "other"? -->
<xs:complexType name="PolicyOverrideReason">
<xs:all>
<xs:element name="type" type="PolicyOverrideType"/>
<xs:element name="comment" type="xs:string"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<!-- How do we allow report generators to include new
classes of override reasons if they want to be more
specific than "other"? -->
<xs:complexType name="PolicyOverrideReason">
<xs:all>
<xs:element name="type" type="PolicyOverrideType"/>
<xs:element name="comment" type="xs:string"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<!-- Taking into account everything else in the record,
the results of applying DMARC. -->
<xs:complexType name="PolicyEvaluatedType">
<xs:sequence>
<xs:element name="disposition" type="DispositionType"/>
<xs:element name="dkim" type="DMARCResultType"/>
<xs:element name="spf" type="DMARCResultType"/>
<xs:element name="reason" type="PolicyOverrideReason"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- Taking into account everything else in the record,
the results of applying DMARC. -->
<xs:complexType name="PolicyEvaluatedType">
<xs:sequence>
<xs:element name="disposition" type="DispositionType"/>
<xs:element name="dkim" type="DMARCResultType"/>
<xs:element name="spf" type="DMARCResultType"/>
<xs:element name="reason" type="PolicyOverrideReason"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- Credit to Roger L. Costello for IPv4 regex
http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
018018.html -->
<!-- Credit to java2s.com for IPv6 regex
http://www.java2s.com/Code/XML/XML-Schema/
IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
<xs:simpleType name="IPAddress">
<xs:restriction base="xs:string">
<xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
(1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>
</xs:restriction>
</xs:simpleType>
<!-- Credit to Roger L. Costello for IPv4 regex
http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
018018.html -->
<!-- Credit to java2s.com for IPv6 regex
http://www.java2s.com/Code/XML/XML-Schema/
IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
<xs:simpleType name="IPAddress">
<xs:restriction base="xs:string">
<xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
(1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="RowType">
<xs:all>
<!-- The connecting IP. -->
<xs:element name="source_ip" type="IPAddress"/>
<!-- The number of matching messages. -->
<xs:element name="count" type="xs:integer"/>
<!-- The DMARC disposition applying to matching
messages. -->
<xs:element name="policy_evaluated"
type="PolicyEvaluatedType"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<xs:complexType name="RowType">
<xs:all>
<!-- The connecting IP. -->
<xs:element name="source_ip" type="IPAddress"/>
<!-- The number of matching messages. -->
<xs:element name="count" type="xs:integer"/>
<!-- The DMARC disposition applying to matching
messages. -->
<xs:element name="policy_evaluated"
type="PolicyEvaluatedType"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<xs:complexType name="IdentifierType">
<xs:all>
<!-- The envelope recipient domain. -->
<xs:element name="envelope_to" type="xs:string"
minOccurs="0"/>
<!-- The RFC5321.MailFrom domain. -->
<xs:element name="envelope_from" type="xs:string"
minOccurs="1"/>
<!-- The RFC5322.From domain. -->
<xs:element name="header_from" type="xs:string"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<xs:complexType name="IdentifierType">
<xs:all>
<!-- The envelope recipient domain. -->
<xs:element name="envelope_to" type="xs:string"
minOccurs="0"/>
<!-- The RFC5321.MailFrom domain. -->
<xs:element name="envelope_from" type="xs:string"
minOccurs="1"/>
<!-- The RFC5322.From domain. -->
<xs:element name="header_from" type="xs:string"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- DKIM verification result, according to RFC 7001
Section 2.6.1. -->
<xs:simpleType name="DKIMResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="pass"/>
<!-- DKIM verification result, according to RFC 7001
Section 2.6.1. -->
<xs:simpleType name="DKIMResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
<xs:enumeration value="policy"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="temperror"/>
<xs:enumeration value="permerror"/>
</xs:restriction>
</xs:simpleType>
<xs:enumeration value="fail"/>
<xs:enumeration value="policy"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="temperror"/>
<xs:enumeration value="permerror"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DKIMAuthResultType">
<xs:all>
<!-- The "d=" parameter in the signature. -->
<xs:element name="domain" type="xs:string"
minOccurs="1"/>
<!-- The "s=" parameter in the signature. -->
<xs:element name="selector" type="xs:string"
minOccurs="0"/>
<!-- The DKIM verification result. -->
<xs:element name="result" type="DKIMResultType"
minOccurs="1"/>
<!-- Any extra information (e.g., from
Authentication-Results). -->
<xs:element name="human_result" type="xs:string"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<xs:complexType name="DKIMAuthResultType">
<xs:all>
<!-- The "d=" parameter in the signature. -->
<xs:element name="domain" type="xs:string"
minOccurs="1"/>
<!-- The "s=" parameter in the signature. -->
<xs:element name="selector" type="xs:string"
minOccurs="0"/>
<!-- The DKIM verification result. -->
<xs:element name="result" type="DKIMResultType"
minOccurs="1"/>
<!-- Any extra information (e.g., from
Authentication-Results). -->
<xs:element name="human_result" type="xs:string"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<!-- SPF domain scope. -->
<xs:simpleType name="SPFDomainScope">
<xs:restriction base="xs:string">
<xs:enumeration value="helo"/>
<xs:enumeration value="mfrom"/>
</xs:restriction>
</xs:simpleType>
<!-- SPF domain scope. -->
<xs:simpleType name="SPFDomainScope">
<xs:restriction base="xs:string">
<xs:enumeration value="helo"/>
<xs:enumeration value="mfrom"/>
</xs:restriction>
</xs:simpleType>
<!-- SPF result. -->
<xs:simpleType name="SPFResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
<xs:enumeration value="softfail"/>
<!-- "TempError" commonly implemented as "unknown". -->
<xs:enumeration value="temperror"/>
<!-- "PermError" commonly implemented as "error". -->
<xs:enumeration value="permerror"/>
</xs:restriction>
</xs:simpleType>
<!-- SPF result. -->
<xs:simpleType name="SPFResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
<xs:enumeration value="softfail"/>
<!-- "TempError" commonly implemented as "unknown". -->
<xs:enumeration value="temperror"/>
<!-- "PermError" commonly implemented as "error". -->
<xs:enumeration value="permerror"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="SPFAuthResultType">
<xs:all>
<!-- The checked domain. -->
<xs:element name="domain" type="xs:string" minOccurs="1"/>
<!-- The scope of the checked domain. -->
<xs:element name="scope" type="SPFDomainScope" minOccurs="1"/>
<!-- The SPF verification result. -->
<xs:element name="result" type="SPFResultType"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<xs:complexType name="SPFAuthResultType">
<xs:all>
<!-- The checked domain. -->
<xs:element name="domain" type="xs:string" minOccurs="1"/>
<!-- The scope of the checked domain. -->
<xs:element name="scope" type="SPFDomainScope" minOccurs="1"/>
<!-- The SPF verification result. -->
<xs:element name="result" type="SPFResultType"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- This element contains DKIM and SPF results, uninterpreted
with respect to DMARC. -->
<xs:complexType name="AuthResultType">
<xs:sequence>
<!-- There may be no DKIM signatures, or multiple DKIM
signatures. -->
<xs:element name="dkim" type="DKIMAuthResultType"
minOccurs="0" maxOccurs="unbounded"/>
<!-- There will always be at least one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- This element contains DKIM and SPF results, uninterpreted
with respect to DMARC. -->
<xs:complexType name="AuthResultType">
<xs:sequence>
<!-- There may be no DKIM signatures, or multiple DKIM
signatures. -->
<xs:element name="dkim" type="DKIMAuthResultType"
minOccurs="0" maxOccurs="unbounded"/>
<!-- There will always be at least one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- This element contains all the authentication results that
were evaluated by the receiving system for the given set of
messages. -->
<xs:complexType name="RecordType">
<xs:sequence>
<xs:element name="row" type="RowType"/>
<xs:element name="identifiers" type="IdentifierType"/>
<xs:element name="auth_results" type="AuthResultType"/>
</xs:sequence>
</xs:complexType>
<!-- This element contains all the authentication results that
were evaluated by the receiving system for the given set of
messages. -->
<xs:complexType name="RecordType">
<xs:sequence>
<xs:element name="row" type="RowType"/>
<xs:element name="identifiers" type="IdentifierType"/>
<xs:element name="auth_results" type="AuthResultType"/>
</xs:sequence>
</xs:complexType>
<!-- Parent -->
<xs:element name="feedback">
<xs:complexType>
<xs:sequence>
<xs:element name="version"
type="xs:decimal"/>
<xs:element name="report_metadata"
type="ReportMetadataType"/>
<xs:element name="policy_published"
type="PolicyPublishedType"/>
<!-- Parent -->
<xs:element name="feedback">
<xs:complexType>
<xs:sequence>
<xs:element name="version"
type="xs:decimal"/>
<xs:element name="report_metadata"
type="ReportMetadataType"/>
<xs:element name="policy_published"
type="PolicyPublishedType"/>
<xs:element name="record" type="RecordType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:element name="record" type="RecordType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Descriptions of the PolicyOverrideTypes:
PolicyOverrideTypes的说明：
forwarded: The message was relayed via a known forwarder, or local heuristics identified the message as likely having been forwarded. There is no expectation that authentication would pass.
转发：消息通过已知的转发器转发，或者本地启发式方法将消息标识为可能已转发。不期望身份验证能够通过。
local_policy: The Mail Receiver's local policy exempted the message from being subjected to the Domain Owner's requested policy action.
local_策略：邮件接收者的本地策略使邮件不受域所有者请求的策略操作的约束。
mailing_list: Local heuristics determined that the message arrived via a mailing list, and thus authentication of the original message was not expected to succeed.
邮件列表：本地启发式算法确定消息通过邮件列表到达，因此原始消息的身份验证预计不会成功。
other: Some policy exception not covered by the other entries in this list occurred. Additional detail can be found in the PolicyOverrideReason's "comment" field.
其他：发生此列表中其他条目未涵盖的某些策略异常。更多详细信息可在PolicyOverrideReason的“注释”字段中找到。
sampled_out: The message was exempted from application of policy by the "pct" setting in the DMARC policy record.
抽样：通过DMARC策略记录中的“pct”设置，该消息被豁免应用策略。
trusted_forwarder: Message authentication failure was anticipated by other evidence linking the message to a locally maintained list of known and trusted forwarders.
可信转发器：其他证据将邮件链接到本地维护的已知和可信转发器列表，预期邮件身份验证失败。
The "version" for reports generated per this specification MUST be the value 1.0.
根据本规范生成的报告的“版本”值必须为1.0。
Acknowledgements
致谢
DMARC and the draft version of this document submitted to the Independent Submission Editor were the result of lengthy efforts by an informal industry consortium: DMARC.org (see <http://dmarc.org>). Participating companies included Agari, American Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn, Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain Project, and Yahoo!. Although the contributors and supporters are too numerous to mention, notable individual contributions were made by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen. The contributors would also like to recognize the invaluable input and guidance that was provided early on by J.D. Falk.
DMARC和提交给独立提交编辑的本文件草稿是一个非正式行业联盟（DMARC.org）长期努力的结果（见<http://dmarc.org>). 参与的公司包括Agari、American Greetings、AOL、美国银行、Cloudmark、Comcast、Facebook、Fidelity Investments、谷歌、摩根大通公司、LinkedIn、微软、网易、贝宝、ReturnPath、可信域项目和雅虎！。尽管贡献者和支持者太多了，但值得一提的个人贡献有J.特伦特·亚当斯、迈克尔·阿德金斯、莫妮卡·周、戴夫·克罗克、蒂姆·德雷根、史蒂夫·琼斯、弗兰克·马丁、布雷特·麦克道尔和保罗·米德根。撰稿人还想感谢J.D.Falk早些时候提供的宝贵投入和指导。
Additional contributions within the IETF context were made by Kurt Anderson, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton, J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S. Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull.
Kurt Anderson、Michael Jack Assels、Les Barstow、Anne Bennett、Jim Fenton、J.Gomez、Mike Jones、Scott Kitterman、Eliot Lear、John Levine、S.Moonesamy、Rolf Sonneveld、Henry Timmes和Stephen J.Turnbull在IETF范围内做出了其他贡献。
Authors' Addresses
作者地址
Murray S. Kucherawy (editor)
默里·S·库切拉维（编辑）
EMail: superuser@gmail.com
EMail: superuser@gmail.com
Elizabeth Zwicky (editor) Yahoo!
伊丽莎白兹威基（编辑）雅虎！
EMail: zwicky@yahoo-inc.com
EMail: zwicky@yahoo-inc.com