非官方中文译本声明：本页为 IETF RFC 6591《Authentication Failure Reporting Using the Abuse Reporting Format》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc6591。

RFC 6591《基于 ARF 的认证失败报告》中文译本

IETF · RFC 6591 · 标准跟踪（Standards Track）· 2012 年 4 月

摘要

本备忘录为滥用报告格式（Abuse Reporting Format，ARF）注册了一种扩展报告类型，该注册涉及多个注册表，用于生成「接收时（receipt-time）报告」，以报告那些未能通过一项或多项电子邮件报文认证检查的邮件。

1. 引言

滥用报告格式 [ARF] 定义了一种报文格式，用于发送有关消息传递基础设施中滥用行为的报告，其着眼点在于让这类报告的生成与消费都能够自动化。现在还产生了一种需求：扩展 ARF，使其能够报告那些未能通过已知报文认证方法（例如 DomainKeys Identified Mail [DKIM] 与发件人策略框架 [SPF]）认证的邮件，因为这类失败有时正是滥用行为的证据，而这些证据可以通过自动化手段检测并上报。同一机制还可用于传递取证（forensic）信息，说明认证方法失败的具体原因。因此，本备忘录提出了对 ARF 的此类扩展，使得对报文认证方法失败的详细报告成为可能。

2. 定义

2.1. 关键词

本文档中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"RECOMMENDED"（推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 [KEYWORDS] 中的描述进行解释。

2.2. 电子邮件体系结构

本备忘录使用了一些术语，其定义与描述可在 [EMAIL-ARCH] 中查到。

2.3. Base64

Base64 定义于 [BASE64] 第 4 节。

采用 base64 编码的取值可以（MAY）出于格式排版目的而包含折行空白（folding whitespace，FWS），这与 [MAIL] 中所定义的常规信头字段折行方式一致。在解码过程中，任何不属于 base64 字母表的字符都会被忽略，因此这样的折行不会破坏取值。ABNF 记号 "FWS" 定义于 [DKIM]。除此之外，不允许对合法的 base64 字符集作任何其他扩展。

2.4. 相关技术

在邮件安全领域，有些技术提供的是认证（authentication）服务，另一些提供的则是授权（authorization）服务。这两者经常被混为一谈。[AUTH-RESULTS] 第 1.5.2 节中的讨论有助于厘清相关背景。

3. 用于认证失败报告的 ARF 扩展

[ARF] 中所定义的现行报告格式缺少若干具体特性，而这些特性正是开展有效的邮件认证失败报告所必需的。本节定义了 ARF 的扩展，以满足这一需求。

单份报告描述单次邮件认证失败。可以（MAY）使用多份报告来上报同一封邮件的多次失败。

3.1. 新的 ARF 反馈类型

本文档依据 [ARF] 第 7.3 节，定义了一种新的反馈类型 "auth-failure" 作为扩展。

使用该反馈类型的报文，对于报告的第二个（机器可解析的）[MIME] 部分，其信头字段要求作如下修改：

Authentication-Results: 语法如 [AUTH-RESULTS] 中所规定。此外，[ARF] 规定该字段是可选（OPTIONAL）的且至多出现一次；对于本扩展，该字段必须（MUST）存在，但它必须（MUST）只反映单一一种认证方法的结果。
Original-Envelope-Id: 语法如 [ARF] 中所规定。此外，[ARF] 规定该字段是可选（OPTIONAL）的且至多出现一次；对于本扩展，在该取值可得的情况下，推荐（RECOMMENDED）包含该字段，以便于诊断认证失败。
Original-Mail-From: 语法如 [ARF] 中所规定。此外，[ARF] 规定该字段是可选（OPTIONAL）的且至多出现一次；对于本扩展，在该取值可得的情况下，推荐（RECOMMENDED）包含该字段，以便于诊断认证失败。
Source-IP: 语法如 [ARF] 中所规定。此外，[ARF] 规定该字段是可选（OPTIONAL）的且至多出现一次；对于本扩展，在该取值可得的情况下，推荐（RECOMMENDED）包含该字段，以便于诊断认证失败。
Reported-Domain: 语法如 [ARF] 中所规定。此外，[ARF] 规定该字段是可选（OPTIONAL）的且至多出现一次；对于本扩展，若该取值可得，则该字段必须（MUST）存在。
Delivery-Result: 如第 3.2.2 节所规定。该字段是可选（OPTIONAL）的，但它不得（MUST NOT）出现一次以上。若存在，它应当（SHOULD）以某种有意义的方式指明该邮件的处置结果，不过出于本地策略方面的原因，它也可以（MAY）被置为 "other"。

报文的第三个 MIME 部分，其类型要么是 "message/rfc822"（如 [MIME-TYPES] 中所定义），要么是 "text/rfc822-headers"（如 [REPORT] 中所定义），其中包含原始报文完整信头块的一份副本。该部分必须（MUST）被包含在内（这与 [REPORT] 相反，后者将其规定为可选）。

出于隐私方面的原因，报告生成方可能需要对被举报报文的某些部分作脱敏（redact）处理，例如与「其投诉行为触发了本报告」的最终用户相关联的标识符或地址。有关问题的讨论以及一种建议的处理方法可参见 [RFC6590]。

3.2. 新的 ARF 信头字段名

以下新的 ARF 字段名被定义为对 [ARF] 第 3.1 节的扩展。

3.2.1. 所有报告均需要的字段

Auth-Failure: 指明所报告的邮件认证方法失败情形。合法取值的清单枚举于第 3.3 节。

3.2.2. 所有报告均可选的字段

Delivery-Result: 由生成该报告的管理管理域（ADministrative Management Domain，ADMD）所实际执行的最终报文处置结果。它不得（MUST NOT）出现一次以上。可能的取值如下：

delivered: 报文已被投递（未具体指明投递到何处）。
spam: 报文被投递到了收件人的垃圾邮件文件夹（或等价位置）。
policy: 由于某项邮件认证方法失败，报文未被投递到预期的收件箱。所采取的具体动作未作规定。
reject: 报文被拒收。
other: 报文的最终处置结果不属于上述任何一种取值。

3.2.3. DKIM 报告需要的字段

DKIM-Domain: 为该报文签名的域，取自签名的 "d=" 标签。
DKIM-Identity: 验证失败的那个签名所对应的身份标识，取自签名的 "i=" 标签。
DKIM-Selector: 验证失败的那个签名所使用的选择符（selector），取自签名的 "s=" 标签。

3.2.4. DKIM 报告可选的字段

DKIM-Canonicalized-Header: 由验证方生成的、报文规范化（canonicalized）信头的 base64 编码。
DKIM-Canonicalized-Body: 由验证方生成的、报文规范化正文的 base64 编码。被编码的内容必须（MUST）限定于那些参与计算 DKIM 正文哈希的八位组（即由 "l=" 标签取值所限定的范围；参见 [DKIM] 第 3.7 节）。

如果 DKIM-Canonicalized-Header 与 DKIM-Canonicalized-Body 所编码的是经过脱敏处理的数据，则它们不得（MUST NOT）被包含在内。否则，它们应当（SHOULD）被包含在内。其中呈现的数据必须恰好是 [DKIM] 所定义的、并在验证方处计算得出的规范化信头与正文。之所以如此，是因为这些字段的用途在于帮助识别那些在传输途中使 DKIM 签名失效的报文改动。若在其中包含脱敏后的数据，会使这些数据变得毫无用处。（另请参见第 3.1 节与第 6.6 节的进一步讨论。）

3.2.5. ADSP 报告需要的字段

DKIM-ADSP-DNS: 包含用于得出验证方 ADSP 结果的作者域签名实践（Author Domain Signing Practices，ADSP）策略。它必须（MUST）按照 [ADSP] 第 4.2.1 节的规定进行格式化。

3.2.6. SPF 报告需要的字段

SPF-DNS: 对于用于得出 SPF 结果的每一条 SPF 记录 [SPF]，该字段都必须（MUST）出现一次。它必须（MUST）包含所使用的 DNS RRTYPE、检索到该记录的 DNS 域名，以及该记录的内容。其语法定义于第 4 节。

3.3. 认证失败类型

在（上文所定义的）"Auth-Failure:" 信头字段中所使用的、已定义的邮件认证失败类型清单如下：

adsp: 该报文不符合作者域所发布的 [ADSP] 签名实践。报告中必须（MUST）包含 DKIM-ADSP-DNS 字段。
bodyhash: 签名中的正文哈希与验证方计算出的正文哈希不匹配。报告中应当（SHOULD）包含 DKIM-Canonicalized-Body 字段（参见第 3.2.4 节）。
revoked: 该报文签名所引用的 DKIM 密钥已被吊销。报告中必须（MUST）包含 DKIM-Domain 与 DKIM-Selector 字段。
signature: 该报文上的 DKIM 签名未能针对信头哈希与公钥成功通过验证。报告中必须（MUST）包含 DKIM-Domain 与 DKIM-Selector 字段，并且应当（SHOULD）包含 DKIM-Canonicalized-Header 字段（参见第 3.2.4 节）。
spf: 对作者域 SPF 记录的求值产生了 "none"、"fail"、"softfail"、"temperror" 或 "permerror" 结果。（按照 [SPF]，"none" 严格来说并不算失败，但如果某项服务要求客户端必须通过 SPF 求值，则它可能会把 "none" 当作失败来对待。）

可以（MAY）以符合 [MAIL] 规定的注释（comment）形式包含补充数据。例如，可以为 "Auth-Failure: adsp" 补上一段注释，说明失败的那封报文之所以被拒收，是因为它本应被签名却未被签名。示例参见附录 B。

4. 新增 ARF 信头字段的语法

这些新字段的 [ABNF] 定义如下：

  auth-failure = "Auth-Failure:" [CFWS]
                 ( "adsp" / "bodyhash" / "revoked" /
                   "signature" / "spf" ) [CFWS] CRLF
               ; "CFWS" is defined in [MAIL]

  delivery-result = "Delivery-Result:" [CFWS]
                    ( "delivered" / "spam" / "policy" /
                      "reject" / "other" ) [CFWS] CRLF

  dkim-header = "DKIM-Canonicalized-Header:" [CFWS]
                base64string CRLF
              ; "base64string" is defined in [DKIM]

  dkim-sig-domain = "DKIM-Domain:" [CFWS] domain-name [CFWS]
                    CRLF
                  ; "domain-name" is defined in [DKIM]

  dkim-identity = "DKIM-Identity:" [CFWS] [ local-part ] "@"
                  domain-name [CFWS] CRLF
                ; "local-part" is defined in [MAIL]

  dkim-selector = "DKIM-Selector:" [CFWS] selector [CFWS] CRLF
                ; "selector" is defined in [DKIM]

  dkim-adsp-dns = "DKIM-ADSP-DNS:" [CFWS]
                  quoted-string [CFWS] CRLF
                ; "quoted-string" is defined in [MAIL]

  dkim-body = "DKIM-Canonicalized-Body:" [CFWS]
              base64string CRLF

  dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS]
                      quoted-string [CFWS] CRLF

  spf-dns = "SPF-DNS:" [CFWS] ( "txt" / "spf" ) [CFWS] ":" [CFWS]
            domain [CFWS] ":" [CFWS] quoted-string [CFWS] CRLF

5. IANA 考虑

按照 [IANA] 的要求，本节给出针对 [ARF] 之扩展的注册表信息。

5.1. 对 ARF 反馈类型的更新

下列反馈类型已被添加到「反馈报告类型取值（Feedback Report Type Values）」注册表中：

Feedback Type: auth-failure
Description: email authentication failure report
Published in: [RFC6591]
Status: current

5.2. 对 ARF 信头字段名的更新

下列信头字段已被添加到「反馈报告信头字段（Feedback Report Header Fields）」注册表中：

Field Name: Auth-Failure
Description: Type of email authentication method failure
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [RFC6591]
Status: current

Field Name: Delivery-Result
Description: Final disposition of the subject message
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [RFC6591]
Status: current

Field Name: DKIM-ADSP-DNS
Description: Retrieved DKIM ADSP record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [RFC6591]
Status: current

Field Name: DKIM-Canonicalized-Body
Description: Canonicalized body, per DKIM
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [RFC6591]
Status: current

Field Name: DKIM-Canonicalized-Header
Description: Canonicalized header, per DKIM
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [RFC6591]
Status: current

Field Name: DKIM-Domain
Description: DKIM signing domain from "d=" tag
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [RFC6591]
Status: current

Field Name: DKIM-Identity
Description: Identity from DKIM signature
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [RFC6591]
Status: current

Field Name: DKIM-Selector
Description: Selector from DKIM signature
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [RFC6591]
Status: current

Field Name: DKIM-Selector-DNS
Description: Retrieved DKIM key record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [RFC6591]
Status: current

Field Name: SPF-DNS
Description: Retrieved SPF record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [RFC6591]
Status: current

为便于中文读者对照，上述注册表条目各字段的含义如下表所示。

字段名（Field Name）	说明（Description）	可否多次出现	关联的 Feedback-Type
Auth-Failure	邮件认证方法失败的类型	否	auth-failure
Delivery-Result	被报告报文的最终处置结果	否	auth-failure
DKIM-ADSP-DNS	检索到的 DKIM ADSP 记录	否	auth-failure
DKIM-Canonicalized-Body	依照 DKIM 规范化后的正文	否	auth-failure
DKIM-Canonicalized-Header	依照 DKIM 规范化后的信头	否	auth-failure
DKIM-Domain	取自 "d=" 标签的 DKIM 签名域	否	auth-failure
DKIM-Identity	取自 DKIM 签名的身份标识	否	auth-failure
DKIM-Selector	取自 DKIM 签名的选择符	否	auth-failure
DKIM-Selector-DNS	检索到的 DKIM 密钥记录	否	auth-failure
SPF-DNS	检索到的 SPF 记录	否	auth-failure

6. 安全考虑

与这些报告相关的安全问题，同 [DSN] 中所讨论的问题相似。

6.1. 继承而来的考虑

建议实现者一并参考 [DKIM]、[ADSP]、[SPF] 与 [ARF] 各文档的「安全考虑」章节。

6.2. 伪造

这些报告与普通的 Internet 电子邮件一样容易被伪造。凡希望自动利用各类投递状态通知（Delivery Status Notification，DSN）的用户代理与自动化邮件处理设施（例如邮件分发列表的分发器），都应采取适当的防范措施，以尽量降低拒绝服务攻击可能造成的损害。

与伪造 DSN 相关的安全威胁包括发送以下内容：

伪造的邮件认证方法失败通知，而实际上该报文已被投递给所指明的收件人；
伪造的签名信息，例如选择符、域名等。

缓解这一威胁的最简单办法，也许就是主张这些报告本身应当以类似 DKIM 的方式签名。但另一方面，如果验证方一侧的 DKIM 基础设施本身存在问题，那么对 DKIM 失败报告进行签名，可能会产出不被其预期收件人信任、甚至不被其接受的报告。

6.3. 自动生成

当有大量邮件因某种原因触发邮件认证失败时，验证代理自动生成这些报告可能会造成一次拒绝服务攻击。

对这类报文的生成速率加以限制或许是恰当的做法，但这样做也有可能妨碍重要且可能具有时效性的信息的传递。

就 ARF 反馈环（feedback loop）的一般原则而言，建议报告生成方仅在双方之间已达成带外（out-of-band）安排之后，才创建这些（或任何）ARF 报告。这样，本机制便成为一种用于调整「经由私下协议配置并启用的、经授权的滥用报告反馈环」参数的手段，而不是仅凭在 DNS 中发现的数据就自动开始发送报告。

6.4. 信封发件人的选择

对于以新报文形式发出的报告，有必要审慎考虑该报文的构造与传输方式，以避免（无论有意还是无意的）放大攻击。进一步的信息参见 [ARF] 第 5 节。

6.5. 多起事件的报告

如果已知某台主机会在发生特定事件时生成滥用报告，攻击者就可以伪造大量会触发此类报告的报文。报告的接收方随后便可能被报告淹没。只要再找出若干台会生成报告的服务器，这种手法很容易被扩展成一次分布式拒绝服务攻击。

[ARF] 中提到的事件计数（incident count）提供了一种有限的缓解方式。生成报告的主机可以选择只周期性地发送报告，每份报告代表若干起相同或近乎相同的事件。甚至可以采用某种「反指数」的做法：对前十起事件逐一发送报告，此后每十起事件发送一份，直至第 100 起；再往后每 100 起事件发送一份，直至第 1000 起；依此类推，直到出现一段相对平静的时期，此后该限制重置。

然而，尤其是针对「近乎相同」的事件采用这一技术时，会导致报告质量下降。举例来说，如果有大量垃圾邮件来自同一个攻击者，报告代理可能决定只就其中一部分报文发送报告。这虽然避免了系统管理员被报告洪流淹没，但每一起事件的精确细节同样也就没有被送出。

6.6. DKIM 报告中数据的脱敏

本备忘录要求：在报告 DKIM 失败时，规范化的信头与正文必须原样返回，不得经过脱敏处理。这是为了确保所返回的规范化形式对调试是有用的，因为它们必须与签名方处的等价形式进行比对。如果一封报文在传输途中被改动，而返回的数据又经过了脱敏，那么被脱敏的部分与被改动的部分可能相互重叠，从而使比对结果变得毫无意义。然而，未经脱敏的数据可能泄露报告方认为属于私密的信息。正因如此，返回这些规范化形式并未被规定为强制要求。

7. 参考文献

7.1. 规范性参考文献

[ABNF] Crocker, D., Ed., and P. Overell，《语法规范的扩充巴科斯范式：ABNF》（Augmented BNF for Syntax Specifications: ABNF），STD 68，RFC 5234，2008 年 1 月。
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine，《DKIM 作者域签名实践（ADSP）》（DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)），RFC 5617，2009 年 8 月。
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy，《一种可扩展的邮件反馈报告格式》（An Extensible Format for Email Feedback Reports），RFC 5965，2010 年 8 月。
[AUTH-RESULTS] Kucherawy, M.，《用于指示报文认证状态的报文信头字段》（Message Header Field for Indicating Message Authentication Status），RFC 5451，2009 年 4 月。
[BASE64] Josefsson, S.，《Base16、Base32 与 Base64 数据编码》（The Base16, Base32, and Base64 Data Encodings），RFC 4648，2006 年 10 月。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.，《域名密钥识别邮件（DKIM）签名》（DomainKeys Identified Mail (DKIM) Signatures），RFC 6376，2011 年 9 月。
[IANA] Narten, T. and H. Alvestrand，《在 RFC 中撰写 IANA 考虑章节的指南》（Guidelines for Writing an IANA Considerations Section in RFCs），BCP 26，RFC 5226，2008 年 5 月。
[KEYWORDS] Bradner, S.，《在 RFC 中用于指明要求级别的关键词》（Key words for use in RFCs to Indicate Requirement Levels），BCP 14，RFC 2119，1997 年 3 月。
[MAIL] Resnick, P., Ed.，《Internet 报文格式》（Internet Message Format），RFC 5322，2008 年 10 月。
[MIME] Freed, N. and N. Borenstein，《多用途 Internet 邮件扩展（MIME）第一部分：Internet 报文主体的格式》（Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies），RFC 2045，1996 年 11 月。
[MIME-TYPES] Freed, N. and N. Borenstein，《多用途 Internet 邮件扩展（MIME）第二部分：媒体类型》（Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types），RFC 2046，1996 年 11 月。
[REPORT] Kucherawy, M., Ed.，《用于报告邮件系统管理类报文的 Multipart/Report 媒体类型》（The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages），STD 73，RFC 6522，2012 年 1 月。
[RFC6590] Falk, J., Ed., and M. Kucherawy, Ed.，《从邮件滥用报告中对潜在敏感数据进行脱敏》（Redaction of Potentially Sensitive Data from Mail Abuse Reports），RFC 6590，2012 年 4 月。
[SPF] Wong, M. and W. Schlitt，《发件人策略框架（SPF）：授权在电子邮件中使用域名，第 1 版》（Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1），RFC 4408，2006 年 4 月。

7.2. 资料性参考文献

[DSN] Moore, K. and G. Vaudreuil，《一种可扩展的投递状态通知报文格式》（An Extensible Message Format for Delivery Status Notifications），RFC 3464，2003 年 1 月。
[EMAIL-ARCH] Crocker, D.，《Internet 邮件体系结构》（Internet Mail Architecture），RFC 5598，2009 年 7 月。

附录 A. 致谢（Acknowledgements）

作者谨此感谢以下各位对本提案所作的审阅与建设性批评：Frank Ellermann、J.D. Falk、Scott Kitterman、John Levine、Mike Markley、Kelly Wanser、Murray Kucherawy 以及 Alessandro Vesely。

附录 B. 示例（Example）

本附录给出一个使用本备忘录所定义之扩展的示例。

B.1. ARF 扩展信头的使用示例

以下是一份使用了本文所提出之 ARF 扩展字段的 ARF 格式报告（原文照录，不作翻译）：

Message-ID: <433689.81121.example@mta.mail.receiver.example>
From: "SomeISP Antispam Feedback" <feedback@mail.receiver.example>
To: arf-failure@sender.example
Subject: FW: You have a new bill from your bank
Date: Sat, 8 Oct 2011 15:15:59 -0500 (CDT)
MIME-Version: 1.0
Content-Type: multipart/report;
  boundary="------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg";
  report-type=feedback-report
Content-Transfer-Encoding: 7bit

--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

This is an authentication failure report for an email message
received from a.sender.example on 8 Oct 2011 20:15:58 +0000 (GMT).
For more information about this format, please see [RFC6591].

--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit

Feedback-Type: auth-failure
User-Agent: Someisp!Mail-Feedback/1.0
Version: 1
Original-Mail-From: anexample.reply@a.sender.example
Original-Envelope-Id: o3F52gxO029144
Authentication-Results: mta1011.mail.tp2.receiver.example;
 dkim=fail (bodyhash) header.d=sender.example
Auth-Failure: bodyhash
DKIM-Canonicalized-Body: VGhpcyBpcyBhIG1lc3NhZ2UgYm9keSB0
  aGF0IGdvdCBtb2RpZmllZCBpbiB0cmFuc2l0LgoKQXQgdGhlIHNhbWU
  gdGltZSB0aGF0IHRoZSBib2R5aGFzaCBmYWlscyB0byB2ZXJpZnksIH
  RoZQptZXNzYWdlIGNvbnRlbnQgaXMgY2xlYXJseSBhYnVzaXZlIG9yI
  HBoaXNoeSwgYXMgdGhlClN1YmplY3QgYWxyZWFkeSBoaW50cy4gIElu
  ZGVlZCwgdGhpcyBib2R5IGFsc28gY29udGFpbnMKdGhlIGZvbGxvd2l
  uZyB0ZXh0OgoKICAgUGxlYXNlIGVudGVyIHlvdXIgZnVsbCBiYW5rIG
  NyZWRlbnRpYWxzIGF0CiAgIGh0dHA6Ly93d3cuc2VuZGVyLmV4YW1wb
  GUvCgpXZSBhcmUgaW1wbHlpbmcgdGhhdCwgYWx0aG91Z2ggbXVsdGlw
  bGUgZmFpbHVyZXMKcmVxdWlyZSBtdWx0aXBsZSByZXBvcnRzLCBhIHN
  pbmdsZSBmYWlsdXJlIGNhbiBiZQpyZXBvcnRlZCBhbG9uZyB3aXRoIH
  BoaXNoaW5nIGluIGEgc2luZ2xlIHJlcG9ydC4K
DKIM-Domain: sender.example
DKIM-Identity: @sender.example
DKIM-Selector: testkey
Arrival-Date: 8 Oct 2011 20:15:58 +0000 (GMT)
Source-IP: 192.0.2.1
Reported-Domain: a.sender.example
Reported-URI: http://www.sender.example/

--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: text/rfc822-headers
Content-Transfer-Encoding: 7bit

Authentication-Results: mta1011.mail.tp2.receiver.example;
 dkim=fail (bodyhash) header.d=sender.example;
 spf=pass smtp.mailfrom=anexample.reply@a.sender.example
Received: from smtp-out.sender.example
 by mta1011.mail.tp2.receiver.example
 with SMTP id oB85W8xV000169;
 Sat, 08 Oct 2011 13:15:58 -0700 (PDT)
DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256;
 s=testkey; d=sender.example; h=From:To:Subject:Date;
 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
 KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
 4bmp/YzhwvcubU4=
Received: from mail.sender.example
 by smtp-out.sender.example
 with SMTP id o3F52gxO029144;
 Sat, 08 Oct 2011 13:15:31 -0700 (PDT)
Received: from internal-client-001.sender.example
 by mail.sender.example
 with SMTP id o3F3BwdY028431;
 Sat, 08 Oct 2011 13:15:24 -0700 (PDT)
Date: Sat, 8 Oct 2011 16:15:24 -0400 (EDT)
Reply-To: anexample.reply@a.sender.example
From: anexample@a.sender.example
To: someuser@receiver.example
Subject: You have a new bill from your bank
Message-ID: <87913910.1318094604546@out.sender.example>

--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg--

示例 1：使用本文所定义扩展的 ARF 报告示例

这份示例 ARF 报文所作出的断言如下：

在 "sender.example" 域内添加的那个签名，其 DKIM 验证失败。
验证失败的原因是：验证方处观察到的正文内容与签名中所含的正文哈希不匹配。

作者地址（Author's Address）

Hilda L. Fontana
3579 E. Foothill Blvd., Suite 282
Pasadena, CA 91107
US

电话（Phone）：+1 626 676 8852
电子邮件（EMail）：hilda@hfontana.com