非官方中文译本声明：本页为 IETF RFC 7960《Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc7960。

RFC 7960《基于域的邮件认证互操作建议》中文译本

IETF · RFC 7960 · informational（参考类）· 2016 年 9 月

摘要

基于域的邮件认证、报告与一致性（Domain-based Message Authentication, Reporting, and Conformance，DMARC）引入了一种机制，用于表达域级别的策略与偏好，以进行邮件消息的校验、处置与报告。然而，当消息并非从作者（Author）所在的管理域直接流向最终收件人（Final Recipient）时，DMARC 机制会引发潜在的、具有破坏性的互操作问题。这类邮件流被统称为「间接邮件流（indirect email flows）」。本文档描述这些互操作问题，并给出可能的应对方法。

本备忘录的状态

本文档不是 Internet 标准跟踪（Internet Standards Track）规范；它是为提供参考信息（informational）而发布的。

本文档是 Internet 工程任务组（IETF）的产物。它代表了 IETF 社区的共识，已经过公开评审，并获得 Internet 工程指导组（IESG）批准发布。并非所有经 IESG 批准的文档都是任何级别 Internet 标准的候选；参见 RFC 7841 第 2 节。

有关本文档当前状态、任何勘误以及如何对其提供反馈的信息，可在 http://www.rfc-editor.org/info/rfc7960 处获取。

1. 引言

DMARC [RFC7489] 引入了一种机制，用于表达域级别的策略与偏好，以进行消息的校验、处置与报告。DMARC 机制——尤其是在采用限制性策略时——会因第三方消息来源、消息变换或重新路由而遭遇若干不同类型的互操作问题。特别地，采用限制性策略的 DMARC 会给许多邮件列表（Mailing List）带来麻烦。

在撰写本文档时，DMARC 基础规范已作为 Informational 类 RFC 7489 [RFC7489] 发布，并在邮件社区中获得了相当规模的部署。

邮件不是从作者的管理域直接流向收件人所在域的那些情形，在本文档中被统称为「间接邮件流」。由于 DMARC 已有并且日益扩大的采用规模，基于 DMARC 的邮件拒收策略对间接邮件流所造成的影响，对于总体邮件流量中的某一特定子集而言可能相当显著。

本文档首先给出若干已知的互操作问题成因，随后描述 Internet 邮件体系结构 [RFC5598] 中可能出现互操作问题的各个组件。

最后，本文档给出已知的以及可能的问题解决方法。对于任何一个给定的互操作问题，往往存在多种应对方式。虽然本文档力求评述全面，但不应被视为已经穷尽。

请注意，本文档撰写时正在使用的某些做法，未必是「最佳实践」，尤其是在未来标准不断演进的情况下。

1.1. 文档约定

本文档中用于结构化字段的记法取自 [RFC5598] 第 1.3 节。

术语「通知消息（notification message）」（[RFC5321] 第 4.5.5 节）用于指代 RFC5321.MailFrom 为空（null）的消息。

术语「组织域（Organizational Domain）」与「已认证标识（Authenticated Identifiers）」在 DMARC（[RFC7489] 第 3 节）中定义。

所有以大写字母开头的词语，其正式含义均取自上述引用文献。

2. 互操作问题的成因

当对 DMARC 规范的遵从导致接收方实现，对那些既符合 [RFC5598] 所规定的体系结构、又被目标收件人视为合法的消息施加基于 DMARC 的策略限制时，DMARC 与间接邮件流之间就出现了互操作问题。

请注意，声明 "p=none" 策略的域，以及能够通过标准 DMARC 校验的邮件消息，不存在任何互操作问题。

那些不符合 IETF 邮件规范、但被目标收件人视为合法的邮件消息，不在本文档讨论范围之内。

本节其余部分描述互操作问题的若干概念性成因。

2.1. 标识一致性（Identifier Alignment）

致运营者与管理员的提示：发件人策略框架（SPF）所使用的标识是 SMTP 传输过程中的技术性组成部分。如下文所述，它们与消息本身的内容或来源之间未必存在有实质意义的关联。这种「因邻近而产生的关联」可能成为非技术类最终用户（无论是收件人还是发件人）产生困惑的一个源头。

DMARC 依赖域名密钥标识邮件（DomainKeys Identified Mail，DKIM）[RFC6376] 与 SPF [RFC7208] 来执行消息来源校验。DMARC [RFC7489] 规范将经由 DKIM 或 SPF 校验通过的来源域称为「已认证标识」。要为 DMARC 所用，一个「已认证标识」还必须与消息 RFC5322.From 头字段 [RFC5322] 中所出现的域相关联。已认证标识的域与 RFC5322.From 的域之间的这种关联，被称为「标识一致性（Identifier Alignment）」。

DMARC 允许以两种不同的模式来判定标识一致性：严格（strict）与宽松（relaxed）。严格模式要求任一已认证标识的域与消息 RFC5322.From 头字段 [RFC5322] 之间完全精确匹配。宽松模式则允许在已认证标识与消息 RFC5322.From 头字段 [RFC5322] 共享同一组织域时即判定为标识一致。总体而言，严格一致与宽松一致所面临的 DMARC 互操作问题是相同的，但严格一致因其更为严苛的匹配要求而限制了可行的解决方案。本文档所描述的某些缓解措施只在宽松标识一致模式下才有效。

2.1.1. DKIM 标识

DKIM 提供了一种密码学手段，使一个或多个域标识能够与某一特定消息相关联。作为一项独立技术，DKIM 标识并不要求与消息内容的来源相关联。然而，要使某个 DKIM 标识在 DMARC 中达成一致，有效签名的签名域必须与 RFC5322.From 头字段 [RFC5322] 中的域同属一个组织域。

此外，DKIM 允许存在多个有效签名。这些多重签名可能来自相同或不同的域；DKIM 规范内部对此没有任何限制。DMARC 机制将持续处理基于 DKIM 签名的已认证标识，直至找到一个一致的已认证标识（如果存在的话）。然而，运营经验表明，某些实现在处理多重签名时存在困难。无法处理多个 DKIM 签名的实现，可能会错误地将消息标记为「未通过」（DMARC 一致性），并对本来符合规范的消息错误地施加基于 DMARC 的策略。

2.1.2. SPF 标识

SPF 规范 [RFC7208] 为每条消息定义了两个已认证标识。这些标识派生自：

  1. RFC5321.MailFrom [RFC5321] 域；以及
  2. RFC5321.HELO/.EHLO SMTP 域。

在 SPF 规范中，RFC7208.MAILFROM [RFC7208] 值被定义为基于 RFC5321.MailFrom，除非该值缺失（例如通知消息的情形），此时便使用第二个标识值（RFC5321.HELO/.EHLO）。由于通知消息往往是 MTA 软件的一项「自动」功能，这种「回退（fallback）」定义时常被 MTA 系统的运营者所误解。某些 MTA 软件并不提供为此类通知消息添加 DKIM 签名的能力。

该场景的处理示例参见附录 A。

就 DMARC 的校验／一致性判定而言，当且仅当混合的 RFC7208.MAILFROM [RFC7208] 标识之域与 RFC5322.From [RFC5322] 域一致时，该域才会被采用。已校验域的一致性判定，依据 DMARC 记录中「严格」或「宽松」的设定来确定，其规则如上文针对 DKIM 标识所述并见于 [RFC7489]。

2.1.3. 多个 RFC5322.From 地址

[RFC5322] 只允许出现一个 From 头字段，但该字段中可以包含多个邮箱（mailbox）。由于这是一种极其罕见的用法，DMARC 规定该情形的处理方式由实现自行决定。

由于多个域的出现可能被攻击者所利用（攻击者可以把自己的域加入 RFC5322.From 字段、提供任意的新内容并对消息签名），DMARC 规范建议对此类消息施加最严格的策略（[RFC7489] 第 6.6.1 节）。

2.2. 消息转发

第 3 节结合 Internet 邮件体系结构的各个组件描述转发行为。

所有转发操作都涉及邮件的重新传输。如上文所述，为使 SPF 能够产出与 DMARC 相关的已认证标识，RFC7208.MAILFROM 的域必须与 RFC5322.From 头字段保持一致。转发给基于 SPF 的已认证标识的可用性带来了特定的问题：

在这两种情形下，SPF 都无法产出相关的已认证标识，只能依赖 DKIM 来产出与 DMARC 相关的结果。

2.3. 消息修改

对邮件内容的修改会使大多数 DKIM 签名失效，而许多消息转发系统都会修改邮件内容。邮件列表处理程序是此类系统的常见例子，但其他转发系统同样会进行修改。

尽管 DKIM 提供了长度标志（length flag），使得内容可以被追加而不致令签名失效，但在实践中——特别是对于 MIME 编码 [RFC2045] 的消息——邮件列表处理程序所做的远不止简单地追加内容（细节参见 [RFC5598] 第 5.3 节）。此外，由于存在安全问题，长度标志很少被使用（更多安全考虑参见 [RFC6376] 第 8.2 节）。因此，此方法在这里仅出于完整性而提及。

DKIM 描述了在为 DKIM 处理准备头部与主体时可用的两种规范化（canonicalization）方式：simple 与 relaxed。后者旨在容纳对空白与折行的细微修改——至少在头部的情形下，这些修改通常不具有语义意义。然而，relaxed 规范化在计算上更为密集，在 DKIM 的早期部署中可能并不受青睐，以致某些部署仍在使用宽容度较低的 "simple" 规范化。虽然其普遍程度尚不清楚，但确实有一些 DKIM 验证方在正确处理 relaxed 规范化时存在问题。

3. Internet 邮件体系结构、DMARC 与间接邮件流

本节描述 Internet 邮件体系结构 [RFC5598] 中可能出现 DMARC 与间接邮件流之间互操作问题的各个组件。

3.1. 消息处理系统（MHS）

[RFC5598] 第 4 节描述了构成消息处理系统（Message Handling System，MHS）的六个基本组件：

在这些组件中，本文档就与 DMARC 的互操作性讨论 MSA、MTA 与 MDA。

[RFC5598] 第 5 节还定义了中介体（Mediator），它是若干组件类型的混合体。由于中介体在尝试与 DMARC 互操作时会面临独特的问题，本节对其给予专门的考量。

3.1.1. 消息提交代理（MSA）

MSA 接受由消息用户代理（MUA）提交的消息，并执行其所在管理管辖域（ADministrative Management Domain，ADMD）的策略以及 Internet 标准的各项要求。

MSA 可划分为两个子组件：

当某个 aMSA 接受了一条其 RFC5322.From 头字段所含之域位于该 MSA 的 ADMD 之外的消息时，MSA 与 DMARC 的互操作问题便随之开始。此种情形以多种方式表现出来，例如：某人使用某项邮件服务并配以自有域名，却未能正确配置 SPF 记录；或者某个 MUA 试图以他人身份发送邮件。后一种情形的例子包括新闻／文章网站上常见的「转发给朋友（forward-to-friend）」功能，或某些 MUA 所提供的「以他人身份发送（send-as）」功能。

当某个 hMSA 为一条 RFC5322.From 头字段中所含之域位于该 hMSA 的 ADMD 之外的消息承担传输责任时，若该域发布了 "quarantine" 或 "reject" 的 DMARC 策略，则该 hMSA 将面临 DMARC 互操作问题。这些问题的特征在于：难以与消息 RFC5322.From 头字段中所出现之域建立一致性。此类问题的例子包括：

3.1.2. 消息传输代理（MTA）

MTA 对消息进行中继，直至消息抵达目标 MDA。某些常见的消息处理策略会破坏 DKIM 签名的完整性。限制性的 DMARC 策略加上被破坏的 DKIM 签名，会使潜在的互操作问题变为显性问题。

3.1.2.1. 消息编码

MTA 可能会修改消息的编码，例如把 8 位（8-bit）MIME 分段转换为 quoted-printable 的 7 位分段。此类修改超出 DKIM 规范化的适用范围，并将使包含消息内容的 DKIM 签名失效。

MTA 也可能在不改变编码类型的前提下对消息重新编码：接收一条 MIME 编码的消息，并产出一个在语义与符号意义上等价、但与原文并不完全相同的 MIME 主体。这是那些在内部使用其他消息表示形式的系统所特有的行为。

3.1.2.2. 头部标准化

MTA 可能会改写头部，以使其符合现行的各项 RFC。例如，某些常见的 MTA 会把可以理解但不合规的日期格式修正为合规格式。

头部改写超出 DKIM 规范化的适用范围，并将使 DKIM 签名失效。由于头部被改写，所有下游的 DMARC 处理都将无法利用 DKIM 来产出已认证标识。

为不符合 RFC 规范的邮件所涉问题提供解决方案，不在本文档范围之内。

3.1.2.3. 内容校验

MTA 还可能出于安全动机对邮件消息的内容作出改动，丢弃或改变消息的某些部分，从而造成 DKIM 签名被破坏。

3.1.3. 消息投递代理（MDA）

MDA 把消息从 MHS 转交到邮箱。与 MSA 类似，MDA 由两个子组件构成：

hMDA 与 rMDA 都可以把消息重定向至另一个地址。与消息重定向相关的 DMARC 互操作问题在第 3.2 节中描述。

Sieve [RFC5228] 功能通常存在于 rMDA 子组件之中，并可能引发 DMARC 互操作问题。Sieve 的 'addheader' 与 'deleteheader' 过滤动作可以修改消息并使 DKIM 签名失效，从而移除由 DKIM 提供、作为 DMARC 机制输入的已认证标识。此外还存在会修改主体的 Sieve 扩展 [RFC5703]。Sieve 所作的改动可能只有在邮件被重新引入传输基础设施时才成为问题。

3.2. 中介体（Mediators）

中介体 [RFC5598] 通过重新投寄（re-posting）过程来转发消息。中介体与基本的 MTA 中继共享部分功能，但在寻址与内容修改两方面都具有更大的灵活性。

DMARC 互操作问题在中介体这一语境下十分常见，而中介体往往正是因其修改消息的能力而被使用。

DMARC 的设计无法应对中介体的某些功能，例如：使 DKIM 签名失效的内容修改；以及在新收件人是从中介体（而非最初的组织）处收到消息时，为支持对重发邮件的 SPF 认证而进行的 RFC5321.MailFrom 改写。

3.2.1. 别名（Alias）

别名是一种简单的重新寻址设施，它提供一个或多个新的 Internet 邮件地址，而不是单一的内部地址。消息继续经由传输服务，投递至一个或多个替代地址。

别名可以通过邮箱级转发（例如通过 "dot-forwarding"）、Sieve 级转发（通过 Sieve 的 "redirect" 动作）或其他方法来实现。当别名保留消息内容且不作显著的头部改动时，DKIM 签名可能仍然有效。然而，别名往往会把投递路径延伸到发起方 ADMD 的 SPF 记录所覆盖的范围之外。

别名的例子包括：

在大多数情形下，提供别名服务的 aMSA 与发起方或最终收件人的 ADMD 之间并无管理上的关系，因此针对别名相关 DMARC 失败的解决方案不应假定存在这样的关系。

3.2.2. 重发方（ReSenders）

重发方对消息的寻址信息进行「拼接（splice）」，把原始消息的作者与新消息的收件人连接起来。即便中介体添加了评注，新收件人看到的消息仍显示为来自原始作者。

如果没有与作者 RFC5322.From 头字段之域相一致的已认证标识，新收件人便无从获得通过（pass）的 DMARC 评估结果。

重发方的例子包括 MUA 层面的转发：把消息重新发送给新的收件人，或者以「内联（inline）」方式把消息转发给新的收件人（这不包括以「附件形式」转发消息）。另一个例子是日程软件——它允许会议参与者（而非会议组织者）修改邀请内容，从而生成声称由会议组织者重新发出的新邀请。

3.2.3. 邮件列表（Mailing Lists）

邮件列表以显式收件人的身份接收消息，然后把它们重新投寄给一份已订阅成员的名单。邮件列表所执行的任务，可以看作是重发方动作的一种扩展与精细化。

邮件列表与重发方（第 3.2.2 节）面临相同的 DMARC 互操作问题，并且极为常见地会以导致 DKIM 失败的方式修改头部或消息内容，包括：

任何此类修改都会使 DKIM 签名失效。

对许多邮件列表而言，头部与内容的修改十分常见，并且往往是当前邮件列表功能与用法的核心所在。此外，MUA 也已开始依赖邮件列表的消息修改，以按照最终用户所预期的方式呈现消息。

3.2.3.1. 邮件列表的运营影响

邮件列表还可能面临以下 DMARC 互操作问题：

3.2.4. 网关（Gateways）

网关执行消息中继的基本路由与传输工作，但同时也被允许根据需要修改内容、结构、寻址和／或其他属性，以便把消息发送进一个依照不同标准或潜在不兼容策略运作的消息环境之中。

网关与重发方（第 3.2.2 节）面临相同的 DMARC 互操作问题。

网关也可能与 MTA（第 3.1.2 节）面临相同的 DMARC 互操作问题。

位于协议网关非 SMTP 一侧的接收方系统，可能无法对 DKIM 与 SPF 进行评估。如果消息经由第二个协议网关重新回到 SMTP 域，这些变换通常会破坏原始的 DKIM 签名。

如果网关被配置为把消息改写到其他接收域，网关层面的转发就可能引入 DMARC 互操作问题。举例来说，一次并购可能促使收购方公司决定把被收购公司的域名下线，方法是改写消息以使用收购方公司的域名。由于 RFC5322.To 头字段通常处于 DKIM 签名范围之内，此类改写会使这些 DKIM 签名失效。

3.2.5. 边界过滤器（Boundary Filters）

为强制执行安全边界，组织可以对消息进行分析，以核查其是否符合自身的安全策略。过滤器可能会改动内容以使其变得安全，例如移除或以其他方式改变被认定为不可接受的内容。

边界过滤器与重发方面临相同的 DMARC 互操作问题。

如果 SPF 与 DKIM 的评估是在过滤器作出修改之后执行的，就可能出现问题。

边界过滤器的例子包括：

3.3. 组合情形

间接邮件流可以相互组合。例如，某大学生可能（使用其大学邮件地址）订阅了一个邮件列表，而这个大学邮件地址又被配置为把所有邮件转发到某个免费邮箱或毕业后的企业账户提供商——该学生在那里拥有一个更为长期的邮件地址。

在一个组织内部，消息可能会经过各种各样的 MTA（第 3.1.2 节），每一个 MTA 执行不同的功能（认证、过滤、分发等）。

4. 互操作问题的可能缓解措施

DMARC 与间接邮件流之间互操作问题的解决方案，在适用范围与影响后果上差异极大。它们既包括对底层处理的改进（例如正确处理多个 DKIM 签名），也包括对消息体系结构更为激进的改动。本节描述应对互操作问题的可能方式。请注意，这些特定的机制未必被视为「最佳实践」，并且在某些情况下可能违反各种惯例或预期。

接收方有时需要投递那些并不符合任何标准或协议、但最终用户确实希望收到的邮件消息。对于那些以易用性以及与既有邮件流的兼容性为优先的服务运营者而言，缓解 DMARC 对间接邮件流的影响尤为重要。

DMARC 提供了一种机制（本地策略，local policy），使接收方能够依据 DMARC 之外的信息，就标识一致性的可接受性作出判断，并把这些判断作为「覆盖（override）」传达给发送方。这一设施可用于缓解某些互操作问题，不过需要谨慎行事，以确保它不会为滥用打开缺口。

使缓解措施的运用更加复杂的是：如果所涉邮件属于某类高价值或高风险（与安全相关）的事务性消息（例如涉及金融交易或医疗记录），那么缓解措施可能并不可取。在这些情形下，缓解 DMARC 因间接邮件流而产生的影响或许并不理想（可能适得其反或为滥用留出空间）。

最后需要说明的是，邮件系统种类繁多且部署广泛。人们预期各种年代与能力的系统都能与 SMTP 生态系统的其余部分保持互操作性。例如，Qmail 至今仍在使用，尽管其基础代码自 1998 年以来就未再更新；ezmlm 这一曾经流行的邮件列表管理器（MLM）仍在部署之中，自 1997 年起便未再更新，尽管存在一个新版本（ezmlm-idx）。其他开源与闭源 MTA 的旧版本也仍普遍在运行。在应对老旧或已停止支持的系统时，某些解决方案的实施可能相当耗时和／或具有破坏性。

4.1. 当前在用的缓解措施

由于 DMARC 已经广泛部署，许多运营者已经在使用各种缓解措施。这些措施在有效性与副作用方面各不相同，但其优点在于它们当前即可获得。

4.1.1. 面向发送方的缓解措施

4.1.1.1. 标识一致性
4.1.1.2. 消息修改

4.1.2. 面向接收方的缓解措施

4.1.2.1. 标识一致性
4.1.2.2. 策略覆盖

4.1.3. 面向重发方的缓解措施

4.1.3.1. 对 RFC5322.From 的更改

许多重发方的问题可以通过使用一个处于重发方控制之下的 RFC5322.From 头字段（而非最初的 RFC5322.From）来规避。只要重发方以一个一致的域签名对消息进行签署，这样做就能纠正标识一致性问题，并允许对消息作任意修改。当重发方更改 RFC5322.From 时，宜于保留有关消息最初发起者的信息。

第一种选择是在各种语境下为此目的使用 Original-From [RFC5703]（或 X-Original-From）头字段（[RFC6648] 不鼓励使用 X- 开头的头字段名）。然而，Original-From（或 X-Original-From）的处理方式在任何地方都没有定义。它目前既未被一致地使用，也未被展示给用户；而且在任何使用它的场合，除非它被纳入新 DKIM 签名的覆盖范围之内，否则它就是一个可被利用的、新的未经认证的标识。

重发方的另一种选择是：把 RFC5322.From 头字段地址改写为一个本地控制的地址，该地址会把邮件转发回原始发送方（并受其自身重发方转发缓解措施的约束）。

4.1.3.2. 避免消息修改
4.1.3.3. 邮件列表

[RFC6377] 就在邮件列表中使用 DKIM 提供了一些指引。以下缓解技术可用于缓解 DMARC 与邮件列表之间的互操作问题：

所有这些技术都可能给 MUA 带来某些特定的挑战，并给最终用户带来不同的操作用法（例如需要改写过滤规则以把邮件归入文件夹）。要充分理解并适应所有这些影响，尚需一段时间。

4.2. 已提出的与进行中的缓解措施

以下缓解措施基于仍在推进中的 Internet 草案（Internet-Drafts，I-D）。此处对它们加以描述，是为了提供一条探索性的解决路径。这些方案不应在生产环境中使用。由于 I-D 具有临时性，本文档不包含具体的引用出处，因为其中相当一部分终将过时，而那些在社区中取得共识者将成为 RFC，届时应以 RFC 的形式被检索到。

4.2.1. 更激进的做法：要求在 MUA 之间建立新的通信路径

在实践中，若干运营者正在使用 DMARC 的严格一致模式，以避免收到通过冒称为邮件列表处理器的系统所投送的、层出不穷且花样翻新的不受欢迎且不真实的邮件。接收方 ADMD 并不知道用户订阅了哪些列表、未订阅哪些列表。一条值得探索的路径是：由用户授权邮件列表充当认证的代理（proxy），届时接收方 ADMD 便会对该邮件列表服务寄予一定的信任。DKIM 的创造者当年正是预见到了这种可能性，才没有把任何语义与 RFC5322.From 头字段紧密绑定。如上所述，这一领域已经开展了一些实验性工作。后续工作或可探究一条通往用户的新通信路径，以授权某种形式的传递性信任（transitive trust）。

5. 安全考虑

本文档是对 DMARC 对间接邮件流之影响的分析。它描述了 DMARC 感知型邮件接收方拒收消息所可能造成的意外拒绝服务（denial of service）。

第 4.1.1.1 节讨论了在面对第三方邮件发送方时，恰当地进行 DKIM 密钥管理的重要性。

第 4.1.3.3 节告诫：不应针对任何域名，通过改写 RFC5322.From 头字段来制造人为构造的域名。

6. 参考文献

6.1. 规范性参考文献

6.2. 资料性参考文献

附录 A. SPF 退信示例

本示例演示一条通知消息「退信（bounce）」。

A.1. 初始消息

下面是该消息离开源 MTA（segv.d1.example）时的样子：

Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
    (authenticated bits=0)
    by segv.d1.example with ESMTP id t0FN4a8O084569;
    Thu, 14 Jan 2015 15:00:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
    s=20130426; t=1421363082;
    bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
    h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
     Content-Transfer-Encoding;
    b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
     bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
     gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org
Subject: Example 1

Hey gang,
This is a test message.
--J.

A.2. 通知消息

当 dmarc.org 拒收这条没有 DKIM 签名的消息时，它把 RFC5321.HELO/.EHLO 域指定为 dmarc.org.local，而该域没有 SPF 记录。dmarc.org 针对此类未通过的情形设置了 reject 策略。由于该通知消息上没有 DKIM 签名，SPF 查询失败便导致 dmarc=fail，因此可以预期 d1.example 会把这条通知消息本身丢弃：

Return-Path: <>
Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1])
   by mx.d1.example with ESMTPS id Lkm25302jJR5
   for <jqd@d1.example>
   (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
   Thu, 14 Jan 2015 15:00:24 -0800 (PST)
Authentication-Results: mx.d1.example;
   spf=none (d1.example: dmarc.org.local does not designate
   permitted sender hosts) smtp.mail=;
   dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org
MIME-Version: 1.0
Received: from segv.d1.example (segv.d1.example [198.51.100.1])
 by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu,
 14 Jan 2015 15:00:24 -0800 (PST)
From: Mail Delivery Subsystem <mailer-daemon@dmarc.org>
To: jqd@d1.example
Subject: Delivery Status Notification (Failure)
Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org>
Date: Thu, 14 Jan 2016 23:00:24 +0000
Content-Type: text/plain; charset=UTF-8

This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

     no-recipient@dmarc.org

Technical details of permanent failure:
Your message was rejected by the server for the recipient domain
  dmarc.org by mail.dmarc.org [192.0.2.1].

The error that the other server returned was:
550 5.1.1 <no-recipient@dmarc.org>... User unknown

----- Original message -----
Return-Path: <jqd@d1.example>
Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com
    [203.252.0.131]) (authenticated bits=0)
    by segv.d1.example with ESMTP id t0FN4a8O084569;
    Thu, 14 Jan 2015 15:00:01 -0800 (PST)
    (envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
    s=20130426; t=1421363082;
    bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
    h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
     Content-Transfer-Encoding;
    b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
     bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
     gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org
Subject: Example 1

Hey gang,
This is a test message.
--J.

致谢（Acknowledgments）

Miles Fidelman、John Levine、David Crocker、Stephen J. Turnbull、Rolf E. Sonneveld、Tim Draegen 与 Franck Martin 为 IETF DMARC 工作组的维基页面作出了贡献，该页面列出了 DMARC 与间接邮件流之间所有已知的互操作问题。

Tim Draegen 依据这些贡献，并以颇为笨拙的方式把它们映射到 [RFC5598] 的术语体系中，撰写了本文档的第一版草案。

作者地址（Authors' Addresses）

Franck Martin（编者）
LinkedIn
Mountain View, CA
United States of America

Email: fmartin@linkedin.com

Eliot Lear（编者）
Cisco Systems GmbH
Richtistrasse 7
Wallisellen, ZH CH-8304
Switzerland

Phone: +41 44 878 9200
Email: lear@cisco.com

Tim Draegen（编者）
dmarcian, inc.
PO Box 1007
Brevard, NC 28712
United States of America

Email: tim@dmarcian.com

Elizabeth Zwicky（编者）
Yahoo
Sunnyvale, CA
United States of America

Email: zwicky@yahoo-inc.com

Kurt Andersen（编者）
LinkedIn
2029 Stierlin Court
Mountain View, CA 94043
United States of America

Email: kandersen@linkedin.com