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

RFC 7601《Authentication-Results 信头》中文译本

IETF · RFC 7601 · 标准跟踪（Standards Track）· 2015 年 8 月

摘要

本文档规定了一个名为 Authentication-Results 的报文信头字段，用于电子邮件报文中，以指示报文认证工作的结果。任何接收方软件——例如邮件过滤器或邮件用户代理（MUA）——都可以使用该信头字段，以便捷而有意义的方式将这些信息传递给用户，或据以做出排序与过滤决策。

本备忘录的状态：本文档为 Internet 标准跟踪（Internet Standards Track）文档。本文档是互联网工程任务组（IETF）的产物，代表了 IETF 社区的共识。它已经过公开评议，并获得互联网工程指导组（IESG）批准发布。关于 Internet 标准的进一步信息可参见 RFC 5741 第 2 节。

本文档废止（Obsoletes）RFC 7001 与 RFC 7410。有关本文档当前状态、任何勘误以及如何对其提供反馈的信息，可在 http://www.rfc-editor.org/info/rfc7601 获取。

1. 引言

本文档描述了一个用于电子邮件报文、名为 Authentication-Results 的信头字段，它以机器可读的格式呈现报文认证工作的结果。该信头字段的意图是：在使用报文认证机制时，创建一个收集此类数据的位置，使邮件用户代理（MUA）与下游过滤器能够做出过滤决策，并/或就报文来源的有效性、以及可能的内容安全性与完整性，向用户给出建议。

本文档基于当前实际使用中的各种认证协议，修订了 [RFC5451] 中的原始定义，并纳入了自原规范发布以来所记录的勘误。

终端用户并不被期望直接消费该信头字段。该信头字段旨在供程序消费，再由这些程序使用其中的数据或将其呈现为人类可用的形式。

本文档规定了该信头字段的格式，并讨论了其存在或缺失所带来的影响。但本文档不讨论该信头字段中所含数据应当如何被使用，例如何种过滤决策是恰当的、或者 MUA 应如何呈现这些结果，因为这些属于本地策略与/或用户界面设计问题，不适合在本文档中讨论。

在本文档发布之时，以下是已发布的电子邮件认证方法：

存在若干注册表，用于登记该信头字段内所使用、并指向上述规范的各类标记（token）。第 6 节描述了这些注册表及其内容，并规定了添加或更新条目的流程；同时也更新了既有内容，使之与这些规范的当前状态相符。

本规范并不意在局限于基于域名的认证方案，但该族系中现有的方案已被证明是实现工作的良好起点。目标是为当前及未来的认证方案提供一个共同框架，用以将其结果投送给下游代理，并抑制为每一种方案单独创建专有信头字段的做法。

虽然 SPF 为此目的定义了一个名为 "Received-SPF" 的信头字段，历史性的 DomainKeys 定义了一个名为 "DomainKey-Status" 的信头字段，但那些信头字段仅专用于传递各自的结果，因而不足以满足下文所列举的需求。此外，许多 SPF 实现至少已将此处规定的信头字段作为一个选项予以采用，而 DomainKeys 已被 DKIM 废止。

1.1. 目的

本文档所定义的信头字段预期服务于以下几个目的：

  1. 传递各种报文认证检查的结果。这些检查由上游过滤器与邮件传输代理（MTA）施加，随后传递给同一「信任域」内的 MUA 与下游过滤器。此类代理可能希望将这些结果呈现给终端用户，或基于认证结果，运用这些数据施加或宽或严的内容检查；
  2. 为这些数据在报文中提供一个统一的位置；
  3. 创建一个可扩展的框架，以便在新的认证方法出现时对其进行报告。

特别需要指出的是：该信头字段的存在本身并不意味着其内容是有效的。相反，该信头字段所报告的，是（据称）在上游某处施加的一个或多个认证方案所做出的断言。若要让 MUA 或下游过滤器把这些断言当作确实有效的，就必须对此类代理、执行验证的 MTA、以及传递该信息的机制三者之间的信任关系做出评估。

1.2. 信任边界

本文档多次提及管理管理域（Administrative Management Domain，ADMD）的「信任边界」。鉴于现有邮件环境的多样性，无法对该术语给出精确定义。

简单地说，从该信头字段的生产者到消费者的传递，必须发生在这样一个上下文之中：该上下文允许消费者把生产者所做的断言视为可靠而准确的（即可信的）。如何获得这种信任超出了本文档的范围，这完全是一个本地事务。

因此，本文档将「信任边界」定义为「外部」实体与「内部」实体之间的分界。内部服务——处于信任边界之内——由 ADMD 的基础设施为其用户提供；外部服务则处于该 ADMD 的权限之外。依此定义，处于信任边界之内的主机受该 ADMD 的权限与策略管辖，而与其物理位置或物理运营方式无关。例如，某台位于信任边界内的主机，实际上可能由一家远程服务提供商运营，并物理地驻留在其数据中心内。

一封报文可能在信任边界内被评估，随后离开信任边界又再度进入。例如被转发的报文，如以 message/rfc822 附件形式（参见多用途互联网邮件扩展 [MIME]）出现的报文，或作为 multipart/digest 一部分的报文。在这种情况下，本字段所报告的细节不可被信任。因此，在这些媒体类型内部发现的本字段通常会被忽略。

1.3. 处理范围

该信头字段的内容意在向报文消费者表明：针对该报文的认证工作已在其信任边界内完成，现将这些结果予以呈现。它并不意在向消费者提供报文参数，以便消费者自行执行认证协议。

1.4. 需求

本文档不对既有协议或服务器确立任何新的要求。

特别地，本文档并不要求 MTA 拒绝或过滤那些未通过认证检查的到达报文。所规定信头字段内容所传递的数据，仅供 MUA 与过滤器参考，由其自行斟酌使用。

1.5. 定义

本节定义贯穿本文档使用的各种术语。

1.5.1. 关键词

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

1.5.2. 安全

《撰写 RFC 安全考虑章节的指南》（[SECURITY]）讨论了认证（authentication）与授权（authorization），以及这两个概念之间的混淆。在近期报文安全工作的语境中，这些术语的用法产生了略有差异的定义，本文档反映的是这些当前用法，如下：

举例而言：SPF 与 Sender ID 属于授权机制，因为它们所表达的结果显示的是——表面上发送该报文的 ADMD 是否明确授权了发起连接的简单邮件传输协议（[SMTP]）客户端代其中继报文——但它们实际上并不验证报文自身的任何其他属性。相比之下，DKIM 对报文的路由不加关心，而是使用密码学签名来认证代理、为报文指派（部分）责任（这隐含着授权），并确保报文中所列出的部分在传输途中未被修改。由于签名不与 SMTP 连接绑定，它们可以由源头 ADMD、中间 ADMD（例如邮件列表服务器）、其他处理代理，或以上任意组合来添加。

本提案没有为每一类解决方案分别创建独立的信头字段，而是把它们都归入单一的信头字段之中。

1.5.3. 电子邮件体系结构

下图说明了邮件在这些已定义组件之间的流动。关于一般电子邮件系统体系结构（其中包含对这些组件的详细描述）的进一步讨论，参见《Internet 邮件体系结构》[EMAIL-ARCH]；关于当前环境中电子邮件认证共性方面的讨论，参见本文档的附录 C。

                       +-----+   +-----+   +------------+
                       | MUA |-->| MSA |-->| Border MTA |
                       +-----+   +-----+   +------------+
                                                 |
                                                 |
                                                 V
                                            +----------+
                                            | Internet |
                                            +----------+
                                                 |
                                                 |
                                                 V
+-----+   +-----+   +------------------+   +------------+
| MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA |
+-----+   +-----+   +------------------+   +------------+

一般而言，我们假定施加报文认证方案的工作发生在边界 MTA 或投递 MTA 处，本规范正是基于这一假定撰写的。然而，有些站点的整个邮件基础设施仅由一台主机构成。在这种情况下，「边界 MTA」与「投递 MTA」等术语很可能指的是同一台机器，甚至同一个代理。也有可能某些报文认证测试是在中间 MTA 上进行的。尽管本文档没有专门描述这些情形，但并不意味着将其排除在外。

1.5.4. 其他术语

在本文档中，术语「生产者（producer）」指任何将该信头字段添加到其所处理报文中的组件；「消费者（consumer）」指任何识别、提取并解析该信头字段，以将其作为处理决策一部分加以使用的组件。

1.6. 信任环境

该信头字段使一个或多个报文验证机制能够把输出传达给一个或多个彼此独立的评估机制。这些机制运行在一个统一的信任边界之内，该边界界定了一个管理管理域（ADMD）。一个 ADMD 包含一个或多个执行验证并生成该信头字段的实体，以及一个或多个为某种评估而消费该字段的实体。该字段往往自身不含任何完整性或验证机制，因此其存在必须被隐式地信任。故而，对该信头字段的有效使用要求：在报文进入 ADMD 时，移除其中已存在的该字段的任何出现实例。这可确保后续出现的实例都是在该 ADMD 的信任边界内添加的。

第 2.2 节所定义的 authserv-id 标记可用于指代整个 ADMD，或某个 ADMD 内的特定验证引擎。尽管标注方案留作运营选择，但本文档后续章节提供了一些选择该标记的指导。

2. 信头字段的定义与格式

本节先对所定义信头字段的格式给出总体概述，然后提供更为形式化的规范。

2.1. 总体描述

此处所规定的信头字段名为 Authentication-Results。它是《Internet 报文格式》（[MAIL]）中所定义的结构化信头字段（Structured Header Field），因此该文档中所有相关的定义均适用。

该信头字段是在报文经过执行认证检查的 MTA 时被添加到报文顶部的，因此可以据此推断出这些检查是在多远之外完成的。所以它被视为 [MAIL] 中所定义的追踪字段（trace field），该文档中所有相关的定义同样适用。

该信头字段的值（在移除注释之后）由一个认证标识符、一个可选的版本，以及随后一系列陈述与支撑数据组成。这些陈述采取 "method=result" 的形式，指明施加了哪些认证方法及其各自的结果。对于每一条此类陈述，其支撑数据可以包括一个 "reason" 字符串，以及一条或多条 "property=value" 陈述，用以指明为得出该结论而评估了报文的哪些属性。

该信头字段可以在单封报文中出现多次，单个信头字段中也可以表示多个结果，或者两者结合使用。

2.2. 形式化定义

形式上，该信头字段使用扩充巴科斯-诺尔范式（[ABNF]）规定如下：

  authres-header = "Authentication-Results:" [CFWS] authserv-id
           [ CFWS authres-version ]
           ( no-result / 1*resinfo ) [CFWS] CRLF

  authserv-id = value
              ; see below for a description of this element

  authres-version = 1*DIGIT [CFWS]
          ; indicates which version of this specification is in use;
          ; this specification is version "1", and the absence of a
          ; version implies this version of the specification

  no-result = [CFWS] ";" [CFWS] "none"
            ; the special case of "none" is used to indicate that no
            ; message authentication was performed

  resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
            *( CFWS propspec )

  methodspec = [CFWS] method [CFWS] "=" [CFWS] result
             ; indicates which authentication method was evaluated
             ; and what its output was

  reasonspec = "reason" [CFWS] "=" [CFWS] value
             ; a free-form comment on the reason the given result
             ; was returned

  propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue
           ; an indication of which properties of the message
           ; were evaluated by the authentication scheme being
           ; applied to yield the reported result

  method = Keyword [ [CFWS] "/" [CFWS] method-version ]
         ; a method indicates which method's result is
         ; represented by "result", and is one of the methods
         ; explicitly defined as valid in this document
         ; or is an extension method as defined below

  method-version = 1*DIGIT [CFWS]
         ; indicates which version of the method specification is
         ; in use, corresponding to the matching entry in the IANA
         ; "Email Authentication Methods" registry; a value of "1"
         ; is assumed if this version string is absent

  result = Keyword
         ; indicates the results of the attempt to authenticate
         ; the message; see below for details

  ptype = Keyword
        ; indicates whether the property being evaluated was
        ; a parameter to an [SMTP] command, was a value taken
        ; from a message header field, was some property of
        ; the message body, or was some other property evaluated by
        ; the receiving MTA; expected to be one of the "property
        ; types" explicitly defined as valid, or an extension
        ; ptype, as defined below

  property = special-smtp-verb / Keyword
          ; indicates more specifically than "ptype" what the
          ; source of the evaluated property is; the exact meaning
          ; is specific to the method whose result is being reported
          ; and is defined more clearly below

  special-smtp-verb = "mailfrom" / "rcptto"
          ; special cases of [SMTP] commands that are made up
          ; of multiple words

  pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name )
           [CFWS]
         ; the value extracted from the message property defined
         ; by the "ptype.property" construction

"local-part" 定义于 [MAIL] 第 3.4.1 节，"CFWS" 定义于 [MAIL] 第 3.2.2 节。

"Keyword" 定义于 [SMTP] 第 4.1.2 节。

"value" 如 [MIME] 第 5.1 节所定义。

"domain-name" 如 [DKIM] 第 3.5 节所定义。

上文 "result" 中所使用的 "Keyword" 还进一步受到限制：其取值必须列举于第 2.7 节之中。

关于 authserv-id 元素的描述，参见第 2.5 节。

若某个 "pvalue" 构造的值部分所标识的对象意在作为一个电子邮件身份，则它必须（MUST）使用该 ABNF 定义中右侧的那种形式。

可与 "smtp" 这一 ptype 配合使用的命令清单，可在 [SMTP] 第 4.1 节中找到。

"propspec" 可以省略，例如当该方法无法提取任何属性来完成其评估、但仍有结果需要报告时。

当把某个 SMTP 命令名作为 "property" 报告时，生成该信头字段的代理通过将其转为小写并去掉所有空格来表示该命令（例如 "MAIL FROM" 变为 "mailfrom"，"RCPT TO" 变为 "rcptto"，依此类推）。

"ptype" 取值为 "policy" 时，表示这是一项关于该报文的策略决定，而不特定于可被提取的某项报文属性。详见第 2.4 节。

使用该信头字段的完整报文示例，可在附录 B 中找到。

2.3. 属性类型（ptype）与属性（property）

上文 ABNF 中的 "ptype" 指明了所报告结果据以产生的、被描述属性的一般类型。它与更为具体的 "property" 相配合，共同指明所报告的数据是从报文的哪一特定部分提取出来的。

ptype 与 property 的各种组合，连同它们所配合使用的认证方法，一并登记并描述于「Email Authentication Methods」注册表中。第 6 节对此有进一步描述。

"ptype" 的合法取值以 IANA 的「Email Authentication Property Types」注册表（由 [RFC7410] 创建）所定义者为准。基于 [RFC7001]，其初始取值及其通常所指含义如下：

使用未知 ptype 所报告的结果不得（MUST NOT）用于做出处理决策。消费者可以安全地忽略它们。

「Email Authentication Methods」注册表中的条目，可以在适当时定义偏离上述定义的属性。此类偏离需要在注册表中与/或在定义文档中予以明确说明。参见第 2.7.1 节中的示例。

2.4. "policy" 这一 ptype

还定义了一个特殊的 ptype 取值 "policy"。提供该 ptype 是为了表明：施加了某种本地策略机制，它增补甚至替换（即覆盖）了认证机制所返回的结果。此时的 property 与 value 用于标识所施加的本地策略及其返回的结果。

例如，DKIM 签名并不要求把 Subject 信头字段纳入被签名字段集合之中。某个 ADMD 在收到这样的报文时，可能认定这样的签名不可接受——即便它通过了验证——因为 Subject 信头字段的内容有可能在签名之后被改动而不致使签名失效。这样的 ADMD 可以把 DKIM 的 "pass" 结果替换为 "policy" 结果，并在相应的 Authentication-Results 字段中包含如下内容：

   ... dkim=fail policy.dkim-rules=unsigned-subject ...

在这个例子中，property 是 "dkim-rules"，表示进行了一项以此为名的本地检查，且该检查返回了 "unsigned-subject" 这一结果。这些名称是由使用它们的 ADMD 任意选定（并且大概也仅在该 ADMD 内部使用）的，因此通常不会向 IANA 注册，也不会以其他方式加以规定，除了施加一些语法限制以便于在信头字段其余部分中方便解析之外。

该 ptype 在本信头字段的原始规范中即已存在，但没有完整的描述或预期用法的示例。其结果是，迄今为止它未曾出现任何与其预期目的相符的实际使用。此处补充的这些细节，旨在引导实现者正确使用它。

2.5. 认证标识符字段

每一个 Authentication-Results 信头字段都有一个认证服务标识符字段（即上文的 authserv-id）。具体而言，它是任意字符串，用于标识 ADMD 内对该报文执行了认证检查的那个认证服务。该标识符意在供机器读取，不一定对用户具有意义。

由于消费该字段的代理将使用该标识符来判定其内容是否值得关注（以及是否可安全使用），该标识符的唯一性必须（MUST）由生成它的 ADMD 予以保证，且必须（MUST）与该 ADMD 相关联。MUA 或下游过滤器应当（SHOULD）使用该标识符来判定某个 Authentication-Results 信头字段中所含数据应当被使用还是被忽略。

为简化实现并利于扩展，认证服务标识符应当（SHOULD）是在整个 ADMD 范围内通用的一个标记。常见做法是使用该 ADMD 所使用或其内部使用的 DNS 域名（有时称为「组织域」），但这并非严格必需。

出于追踪与调试目的，认证标识符也可以改为执行该认证检查（其结果正被报告）的那台 MTA 的具体主机名。此外，某些实现为该标识符定义了子结构，这些均超出本规范的范围。

但请注意：使用像扁平主机名这样的本地相对标识符，而非像 DNS 域名那样层次化且全局唯一的 ADMD 标识符，会使大型站点的配置更加困难。层次化标识符允许把相关的可信系统聚合到单一的父标识符之下，从而允许以一次引用来评估信任关系；替代方案则是一个扁平的命名空间，需要逐一列举每个可信系统。由于消费者将使用该标识符来判定是否使用该信头字段的内容：

有效认证标识符的示例包括 "example.com"、"mail.example.org"、"ms1.newyork.example.com" 以及 "example-auth"。

2.6. 版本标记

上述语法规定：可以在信头字段本身（附于 authserv-id 标记之后）以及所报告的每个方法上，可选地包含版本号。方法版本指的是方法自身的版本，由描述这些方法的文档规定；而 authserv-id 版本指的是本文档的版本，因而也就是该信头字段语法的版本。

包含这些版本号的目的，是避免对结果产生误读。也就是说，如果解析器在 authserv-id 之后发现一个它并不明确知晓的版本，它就可以立即停止解析，因为后续内容可能不符合预期格式。对于方法版本，若该版本不被支持，解析器应当（SHOULD）忽略该方法结果，以防结果的语义与预期含义不同。例如，假设某个 DKIM 版本 2 得出 "pass" 结果的理由与版本 1 不同，那么该字段的消费者可能不希望采用被改变了的语义。允许在语法中携带版本，正是一种表明此点、并让该信头字段的消费者自行决定的方式。

2.7. 已定义的方法与结果取值

每一种认证方法都会返回一组特定结果取值中的一个。下面各小节提供了指向那些定义了本文档专门支持的认证方法的文档的引用，以及它们相应的结果取值。验证方应当（SHOULD）按下文所述使用这些取值。本文档未予规定、但意在被此处所定义信头字段支持的新方法，必须（MUST）在其定义文档或补充文档中包含一份类似的结果表。

2.7.1. DKIM 与 DomainKeys

DKIM 由 "dkim" 方法表示，定义于 [DKIM]。DomainKeys 定义于 [DOMAINKEYS]，由 "domainkeys" 方法表示。

[DOMAINKEYS] 第 3.8 节列举了 DomainKeys 评估的一些可能结果。在生成本信头字段时并不使用那些结果；相反，所返回的结果如下所列。

若某个签名通过了本地策略检查（或不存在特定的本地策略检查），则称该签名「为该 ADMD 所接受（acceptable to the ADMD）」。例如，某个 ADMD 的策略可能要求报文上的签名必须使用报文 From 信头字段中出现的 DNS 域名来添加，从而使第三方签名即便验证通过也不可接受。

DKIM 与 DomainKeys 使用同一套结果集合，如下：

DKIM 结果使用 "header" 这一 ptype 来报告。但其 property 表示的是 DKIM-Signature 信头字段中的某个标签（tag），而不是一个独立的信头字段。例如，ptype-property 组合 "header.d" 指的是签名信头字段内 "d"（签名域）标签的内容，而非一个名为 "d" 的独立信头字段。

针对具有多个签名的报文报告不同 DKIM 结果的能力，在 [RFC6008] 中有所描述。

[DKIM] 建议：若某报文未能通过验证，应将其视为未签名报文。此处报告 "fail" 允许报告的接收方自行决定如何处理该失败；而报告 "neutral" 或 "none" 则先行剥夺了这一选择，确保该报文将被当作从未签名过一样对待。

[DOMAINKEYS] 第 3.1 节描述了确定报文发送地址的过程。因此，DomainKeys 结果是连同签名域名、报文的发送地址、以及提取后者所依据的信头字段名称一并报告的。这意味着一个 DomainKeys 结果包含 ptype-property 组合 "header.d"，外加 "header.from" 与 "header.sender" 之一。从信头中提取的发送地址在包含时会移除所有 [MAIL] 风格的注释；此外，如果该地址未以某种方式被认证，则其 local-part 与 "@" 字符也会被移除。

2.7.2. SPF 与 Sender ID

SPF 与 Sender ID 分别使用 "spf" 与 "sender-id" 方法名。SPF 的结果取值定义于 [SPF] 第 2.6 节，这些定义在此以引用方式纳入：

代码（Code）含义（Meaning）
none[RFC7208]，第 2.6.1 节
pass[RFC7208]，第 2.6.3 节
fail[RFC7208]，第 2.6.4 节
softfail[RFC7208]，第 2.6.5 节
policyRFC 7601，第 2.4 节
neutral[RFC7208]，第 2.6.2 节
temperror[RFC7208]，第 2.6.6 节
permerror[RFC7208]，第 2.6.7 节

在本规范的语境中，这些结果代码用于反映执行 SPF 评估的组件所返回的结果。

对于 SPF，所使用的 ptype 是 "smtp"，property 则是 "mailfrom" 或 "helo"，因为这两者正是 SPF 能够评估的取值。（如果 SMTP 客户端发出的是 EHLO 命令而非 HELO，所使用的 property 仍为 "helo"。）

"sender-id" 方法在 [SENDERID] 中描述。对于该方法，所使用的 ptype 是 "header"，property 则是提取「据称负责地址」（Purported Responsible Address，参见 [PRA]）所依据的那个信头字段的名称——即 "Resent-Sender"、"Resent-From"、"Sender" 或 "From" 之一。

Sender ID 的各项结果列举并描述于 [SENDERID] 第 4.2 节，但就本规范而言，改用上文列举的 SPF 定义。此外，[SENDERID] 规定的结果代码使用了大小写混合形式，但在本语境中通常全部使用小写。

对上述两种方法，还额外定义了一个 "policy" 结果，其含义是：按照该认证方法的算法，客户端确实获得了代表发件人 DNS 域名注入或中继邮件的授权，但本地策略判定该结果不可接受。例如，若 SPF 返回 "pass" 结果，但本地策略检查发现发送方 DNS 域名与一份明确的不可接受 DNS 域名清单（例如垃圾邮件发送者名单）相匹配，就可以使用 "policy"。

如果用于评估 SPF 与 Sender ID 的、所取回的发件人策略中不含对地址 local-part（参见 [MAIL] 第 3.4.1 节）进行认证的明确规定，那么随这些机制的结果一并报告的 "pvalue" 不应（SHOULD NOT）包含 local-part 及其后的 "@" 字符。

2.7.3. "iprev"

第 3 节所定义的 "iprev" 方法所使用的结果取值如下：

该方法没有 "none" 结果，因为任何投递邮件的 TCP 连接都必然关联着一个 IP 地址，因此总是能够进行某种评估。

该结果使用 "policy" 这一 ptype（因为它并不属于任何既有协议的一部分）与 "iprev" 这一 property 来报告。

关于 DNS 应答格式的讨论，参见《域名——实现与规范》（[DNS]）。

2.7.4. SMTP AUTH

SMTP AUTH（定义于 [AUTH]）由 "auth" 方法表示。其结果取值如下：

AUTH 的结果使用 "smtp" 这一 ptype 来报告，property 则为以下之一：

如果两种身份都可获得，则两者都可以报告。例如，考虑某客户端已通过 AUTH 命令完成会话认证、得到授权身份 "client@c.example"，随后发出如下命令：

  MAIL FROM:<alice@a.example> AUTH=<bob@b.example>

这可能产生如下的 "resinfo" 构造：

  ; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example

请注意，在除 "pass" 之外的所有情形中，报文都是由未经认证的客户端发送的。因此就该方法而言，所有非 "pass" 的情形应当（SHOULD）被同等对待。

2.7.5. 其他已注册的代码

还有一些结果代码在其他 RFC 中注册，如下：

2.7.6. 扩展方法

未来对本规范的后续修订或扩展可以定义额外的认证方法标识符（即扩展方法）。这些方法标识符需向互联网号码分配机构（IANA）注册，并且最好在 RFC 中发布。进一步细节参见第 6 节。

可以出于以下原因定义扩展方法：

  1. 使来自新认证系统的额外信息能够被传达给 MUA 或下游过滤器。此类标识符的名称应当反映所定义方法的名称，但不宜不必要地冗长。
  2. 允许创建「子标识符」，以表明不同的认证级别并区分其相对强度，例如 "auth1-weak" 与 "auth1-strong"。

鼓励认证方法的实现者提供充分的信息——必要时通过报文信头字段的注释——以便 MUA 开发者能够理解或转达认证结果的附带细节。例如，若转达执行某次评估所用的数据是有意义的，这类信息可以作为信头字段中的注释加以转达，例如：

     Authentication-Results: example.com;
               foo=pass bar.baz=blob (2 of 3 tests OK)

实验性的方法标识符必须（MUST）仅在明确同意使用它们的 ADMD 之内使用。这些方法标识符及其相关参数不会记载于 RFC 之中。因此，它们随时可能变更，不适合用于生产环境。任何用于生产环境的 MTA、MUA 或下游过滤器，应当（SHOULD）忽略或删除任何包含实验性（未知）方法标识符的 Authentication-Results 信头字段。

2.7.7. 扩展结果代码

未来对本规范的后续修订或扩展可能会定义额外的结果代码（即扩展结果）。结果代码必须（MUST）向互联网号码分配机构（IANA）注册，并且最好在 RFC 中发布。进一步细节参见第 6 节。

实验性结果必须（MUST）仅在明确同意使用它们的 ADMD 之内使用。这些结果及其相关参数没有正式的文档记载。因此，它们随时可能变更，不适合用于生产环境。任何用于生产环境的 MTA、MUA 或下游过滤器，应当（SHOULD）忽略或删除任何包含扩展结果的 Authentication-Results 信头字段。

3. "iprev" 认证方法

本节定义一种名为 "iprev" 的额外认证方法。

"iprev" 试图依据若干 DNS 查询来验证客户端看起来是有效的，也就是说，验证该 IP 地址确实与某个域名明确关联。在收到来自客户端的某种会话发起之后，以客户端对端的 IP 地址查询与之匹配的名称（即由号码到名称的转换，也称为「反向查找」或 "PTR" 记录查询）。取得该结果后，再对由此取回的每一个名称进行查找（即由名称到号码的转换，或称 "A"、"AAAA" 记录查询）。第二次检查的响应通常会产生至少一条回映到客户端 IP 地址的映射。

用算法表述：设客户端对端的 IP 地址为 I，I（经 "PTR" 查询后）所映射到的名称列表为集合 N，N 中每个成员（经相应的 "A" 与 "AAAA" 查询后）所映射到的 IP 地址之并集为 L，则当 I 是 L 的一个元素时，此项测试成功。

接收连接的 MTA 往往会在该测试失败时，直接使用 [AUTH-ESC] 中定义的增强状态码拒绝该连接。如果运营者转而希望把这一信息提供给下游代理，作为处理决策的一个因素，则应按照第 2.7.3 节记录一个结果。

PTR 查询的响应可能包含多个名称。为防止沉重的 DNS 负载，执行这些查询的代理必须（MUST）如此实现：通过生成相应 A 或 AAAA 查询而被评估的名称数量要受到限制，以免对 DNS 基础设施造成过度负担，不过它可以（MAY）由管理员配置。例如，[SPF] 第 4.6.4 节在实现该算法时选择了 10 作为上限。

《支持 IP 版本 6 的 DNS 扩展》（[DNS-IP6]）讨论了 IPv6 情形下的查询格式。

关于此项测试是否明智、是否可靠，存在一些争议。例如在某些地区，由于「使正向与反向 DNS 相匹配」的做法很少被遵循，此项测试可能很难有通过的机会。因此，验证方执行 "iprev" 测试的精确实现细节在此不作规定。验证方在使用 DNS 对连接身份的有效性做了某种检查之后，可以（MAY）自行斟酌报告 "iprev" 测试成功或失败。利用所报告 "iprev" 结果的代理，有责任理解该特定验证方究竟意在报告什么。

关于反向 DNS 映射及其影响的详尽讨论，可参见《DNS 反向映射使用的考虑》（[DNSOP-REVERSE]）。特别地，该文档建议应用避免把此项测试用作认证或安全手段。它在本文档中的出现并非对其的背书，而仅仅是承认该方法仍然常见，并提供转达该测试结果的手段。

4. 将该信头字段添加到报文中

本规范不试图评估可能出现的各种报文认证方法之间的相对强度。所列出的方法是一个与顺序无关的集合；它们的排列次序并不表示某一方法相对于另一方法的强弱或重要性。相反，消费该信头字段的 MUA 或下游过滤器，应当基于自身对每种方法所评估内容的了解来解读该方法的结果。

每一个 "method" 必须（MUST）指向 IANA 注册表中声明的某个认证方法，或第 2.7.6 节所述的某个扩展方法；每一个 "result" 必须（MUST）指向 IANA 注册表中声明的某个结果代码，或第 2.7.7 节所定义的某个扩展结果代码。关于已注册方法与结果代码的进一步信息，参见第 6 节。

符合本规范的 MTA 会（在执行了一项或多项报文认证测试之后）添加该信头字段，以指明是哪个 MTA 或 ADMD 执行了该测试、施加了何种测试，以及结果如何。如果某个 MTA 施加了不止一项此类测试，它要么为每项测试各添加一次该信头字段，要么添加一次并在其中指明所有结果。MTA 不得（MUST NOT）向一个已存在的信头字段中追加结果。

MTA 可以（MAY）添加仅包含认证标识符部分与 "none" 标记（参见第 2.2 节）的该信头字段，以明确表示在该报文投递之前未施加任何报文认证方案。

添加该信头字段的 MTA 必须采取措施，使最终消费其内容的 MUA 或下游过滤器能够辨识该字段是合法的。第 5 节描述了达成此目的的一种流程；在某些环境中可能还需要进一步的措施。第 7.1 节列举了一些可能的解决方案。本文档不为该问题强制规定任何特定解决方案，因为每种环境都有其自身的设施与局限。

多数已知的报文认证方法都聚焦于评估某个特定标识。SPF 与 Sender ID 有所不同，它们可以基于不止一个标识得出结果；具体而言，SPF 可以评估 RFC5321.HELO 参数或 RFC5321.MailFrom 参数，而 Sender ID 可以评估 RFC5321.MailFrom 参数或「据称负责地址」（PRA）标识。在生成本字段以报告这些结果时，只包含实际产生该结果的那个参数。

对于添加该信头字段的 MTA 而言，按照 [MAIL] 第 3.6 节的规定有序地（在顶部）添加信头字段尤为重要。此外，该信头字段应当（SHOULD）被插入到此类 MTA 可能前置的任何其他追踪信头字段之上。这样的位置安排便于检测哪些信头字段是可信的。

直接使用该信头字段的终端用户，可能会无意中信任未经妥善核实的信息。举例来说，如果转达了一个基本的 SPF 结果，声称某个 addr-spec 已通过认证，而该 addr-spec 的 local-part 实际上并未被认证。因此，添加该信头字段的 MTA 不应（SHOULD NOT）包含任何未被所施加方法认证过的数据。此外，如果某项信息是由已知并不对其进行认证的方法所提供的，MUA 不应（SHOULD NOT）把该信息呈现给用户。

4.1. 信头字段的位置与解读

为确保结果无歧义并避免伪造信头字段的影响，MUA 与下游过滤器不应（SHOULD NOT）解读该信头字段，除非被用户或管理员明确配置为如此。也就是说，这种解读不应「默认开启」。自然地，用户或管理员也不应启用此类特性，除非：(1) 他们确信该信头字段会由 ADMD 内某个代理有效地添加，而该 ADMD 正是接收最终由该 MUA 阅读的邮件的一方；并且 (2) 那些看似源自本 ADMD 内部、实则由外部 MTA 添加的该信头字段实例，会在投递之前被移除。

此外，除非该信头字段所携带的认证服务标识符看起来正是用户或管理员所配置的、本 ADMD 内部使用的标识符，否则 MUA 与下游过滤器不应（SHOULD NOT）解读该信头字段。

对于使用了未列于 IANA「Result Code」注册表中的 "result"，或使用了未列于第 6 节所定义「Email Authentication Property Types」注册表中的 "ptype" 所报告的任何结果，MUA 与下游过滤器必须（MUST）予以忽略。此外，对于它们并不专门支持的任何 "method" 所指明的结果，此类代理也必须（MUST）予以忽略。

在缺少针对信任相关材料呈现的、审慎的人因设计考量与测试的情况下，MUA 不应（SHOULD NOT）把这些结果展示给终端用户。例如，攻击者可以注册 examp1e.com（注意其中的数字 "1"（一）），并向目标受害者发送已签名的邮件；验证方会检测到签名有效并报告 "pass"，尽管很显然该 DNS 域名意在误导。进一步的讨论参见第 7.2 节。

如第 2.1 节所述，该信头字段必须（MUST）被当作 [MAIL] 第 3.6.7 节所定义的追踪信头字段来对待，因而不得（MUST NOT）被重新排序，并且必须（MUST）被前置到报文之前，以便在投递时通常能够看出报文认证是在处理链中的哪一个 MTA 处完成的。

请注意，有少数报文处理程序只能向报文追加（append）新的信头字段。严格来说，这些处理程序并不符合本规范。它们仍然可以添加该信头字段以携带认证细节，但关于该工作在处理链中何处完成的信号可能会丢失。消费者应当（SHOULD）被设计为能够容忍这种情况，尤其是对于已知具有此项局限的生产者。

MUA 应当（SHOULD）忽略在 message/rfc822 MIME 附件内部发现的该信头字段实例。

关于这些主题的进一步讨论，可在下文第 7 节中找到。

4.2. 本地策略的执行

某些站点的本地策略把任何特定认证策略的不可恢复失败结果（通常是 "fail" 或类似结果）视为拒绝该报文的正当理由。在这种情况下，边界 MTA 应当（SHOULD）针对该报文发出 SMTP 拒绝响应，而不是添加该信头字段并允许报文继续走向投递。这样做优于让报文抵达内部主机的 MTA 或垃圾邮件过滤器，因为后者可能生成一个本地拒绝，例如向一个被伪造的发起人发送投递状态通知（DSN）[DSN]。此类生成的拒绝在口语中被称为「反向散射（backscatter）」。

对于覆盖认证方法结果的本地策略决定（例如第 2.7 节所述的 "policy" 结果代码），也可以（MAY）照此办理。

如果本地策略是在 MUA 而非 MTA 处执行的，则无法在 SMTP 协议层面进行此类拒绝。

5. 移除已存在的信头字段

出于安全原因，任何符合本规范的 MTA 必须（MUST）删除所发现的、凭借其认证服务标识符声称是在其信任边界内添加、但并非直接来自另一台可信 MTA 的该信头字段的任何实例。例如，example.com 的某台 MTA 在收到一封报文时，必须（MUST）在添加自己的信头字段之前，删除或以其他方式遮蔽该报文中任何携带「表明该信头字段是在 example.com 内部添加」之认证服务标识符的实例。这可能意味着每台 MTA 都必须配备一份已知合规（因而可信）的内部 MTA 清单。

为求简单并获得最大安全性，边界 MTA 可以移除进入其信任边界的邮件上该信头字段的所有实例。然而，这可能与「希望获取由可信外部服务提供商所执行的认证结果」的诉求相冲突；它也可能使那些签名覆盖了该信头字段外部实例的已签名报文失效。更为稳健的边界 MTA 可以设置一份特定清单，列出其信息可被接纳的认证 MTA，并移除来自所有其他来源的该信头字段。

如第 1.2 节所述，此处刻意不给出「信任边界」的形式化定义。完全有可能出现这样的情况：example.com 的边界 MTA 明确信任上游主机 example.net 所断言的认证结果，尽管两者处于完全不相交的管理边界之中。在这种情况下，该边界 MTA 可以（MAY）选择不删除那些结果；此外，执行了某些认证工作的上游主机，可以对自己的结果施加诸如 [DKIM] 之类的签名技术，以向下游主机保证这些结果的真实性。附录 B 中提供了这样一个示例。

类似地，对于使用 [DKIM] 或其他对信头字段进行签名的报文签名方法所签名的报文，如果签名覆盖了将被移除的信头字段，则这一移除动作可能使报文上的一个或多个签名失效。这种行为可能是可取的，因为对一封带有伪造信头字段的报文验证其签名并没有多少价值。不过，签名代理因此可以（MAY）选择将这些信头字段排除在签名范围之外，以避免这种情形。

对于携带了自身不支持的版本（无论是明示的还是隐含的）的该信头字段实例，MTA 应当（SHOULD）予以移除。但是，如果中继该报文的 [SMTP] 连接并非来自可信的内部 MTA，则该 MTA 必须（MUST）移除这样的信头字段。这意味着该 MTA 需要能够理解的该信头字段版本，至少要与其 ADMD 内 MUA 或其他消费者所能理解的版本一样新。

6. IANA 考虑

IANA 已注册所定义的信头字段，并按下文所述创建了相关表格。这些注册表动作最初由 [RFC5451] 定义，并经 [RFC6577] 与 [RFC7001] 更新。此处对所创建的注册表做进一步更新，以提高其完整性。

6.1. Authentication-Results 信头字段

[RFC5451] 依据 [IANA-HEADERS] 中的流程，把 Authentication-Results 信头字段加入了 IANA 的「Permanent Message Header Field Names」注册表。该条目已被更新为引用本文档。以下是其注册模板：

  Header field name: Authentication-Results
  Applicable protocol: mail ([MAIL])
  Status: Standard
  Author/Change controller: IETF
  Specification document(s): RFC 7601
  Related information: none

6.2.「Email Authentication Methods」注册表描述

本规范所支持的报文认证方法名称已向 IANA 注册，第 2.7.6 节所述的实验性名称除外。随每个方法一并记录的，还有伴随该方法结果出现的各项属性。

「Email Authentication Parameters」分组，以及其中的「Email Authentication Methods」注册表，均由 [RFC5451] 为此目的而创建。[RFC6577] 为每个条目增加了 "status" 字段。[RFC7001] 修订了管辖该注册表的规则，并为该注册表增加了 "version" 字段。

该注册表的引用文献已更新为指向本文档。

新条目仅在通过专家评审（Expert Review）后方予分配，依据 [IANA-CONSIDERATIONS]。指定专家应由 IESG 任命。若无法给出清晰、简明、足以确保互操作性的认证方法定义，指定专家有权要求引用一份出版物。除此之外的注册请求通常应予准许。指定专家也可以处理把任何现有注册标记为「已弃用（deprecated）」的请求。

任何两个条目都不能具有相同的 method、ptype 与 property 组合。

该注册表中的一个条目包含以下内容：

"Definition" 字段通常会指向一份永久性文档，或至少是一段描述性文字，从中可以找到关于所添加条目的额外信息。这又可能进一步引用定义该方法的文档，以便能够理解围绕「使用该 method、ptype 与 property 创建或解读 Authentication-Results 信头字段」的全部语义。

6.3.「Email Authentication Methods」注册表更新

依据本文档，该注册表已做出以下变更：

  1. "Defined" 字段已更名为 "Definition"，以与本分组中其他注册表保持一致。
  2. "dkim" 方法、"header" ptype 与 "b" property 所对应的条目，现在引用 [RFC6008] 作为其定义文档，并已从描述中移除该引用。
  3. 所有其他 "dkim"、"domainkeys"、"iprev"、"sender-id" 与 "spf" 方法条目的 "Definition" 字段已改为指向本文档，因为本文档包含了对该注册表及这些相应取值的完整描述。
  4. 所有 "smime" 条目的 "Definition" 字段已改为 [SMIME-REG]。
  5. 使用 property "smime-part" 的 "smime" 条目，其 "value" 字段已改为："The MIME body part reference that contains the S/MIME signature. See Section 3.2.1 of RFC 7281 for full syntax."
  6. "auth" 方法原本仅有的那个条目，意在反映 SMTP "MAIL FROM" 命令动词所带 "AUTH" 参数所指明的身份。然而，还存在一个 "AUTH" 命令动词。为澄清这一歧义，"auth" 方法条目的 "property" 字段已改为 "mailfrom"，其 "Definition" 字段已改为本文档。
  7. 已新增以下条目：
      Method:      auth
  Definition:  this document (RFC 7601)
  ptype:       smtp
  property:    auth
  Value:       identity confirmed by the AUTH command
  Status:      active
  Version:     1
  8. ptype 为 "header" 的 "domainkeys" 条目，其取值已更新如下：
      from:    contents of the [MAIL] From: header field, after removing
           comments, and removing the local-part and following "@" if
           not authenticated

  sender:  contents of the [MAIL] Sender: header field, after removing
           comments, and removing the local-part and following "@" if
           not authenticated
  9. 所有 "dkim-adsp" 与 "domainkeys" 条目的 Status 取值均已改为 "deprecated"，以反映其相应规范现已具有历史性（Historic）状态这一事实。其 "Definition" 字段也已修改，加入了对本文档的引用。

6.4.「Email Authentication Property Types」注册表

[RFC7410] 创建了「Email Authentication Property Types」注册表。

该注册表中的条目须遵循 [IANA-CONSIDERATIONS] 所述的专家评审规则。注册表中的每个条目需要以下取值：

对于新条目，指定专家需要确保为该新条目所提供的描述充分说明了其预期用途。如果存在定义文档，在其中包含一个示例会很有帮助；不过「Email Authentication Methods」注册表或「Email Authentication Result Names」注册表中的条目也可以作为预期用途的示例。

由于本文档是对该注册表定义与规则的完整重述，IANA 已更新该注册表，将本文档第 2.3 节列为其 "body"、"header"、"policy" 与 "smtp" 条目的当前定义。对 [RFC7001] 与 [RFC7410] 的引用已被移除。

6.5.「Email Authentication Result Names」描述

本规范所支持的报文认证结果代码名称必须向 IANA 注册，第 2.7.7 节所述的实验性代码除外。[RFC5451] 为此目的创建了一个注册表。[RFC6577] 增加了 "status" 列，[RFC7001] 更新了管辖该注册表的规则。

新条目仅在通过专家评审后方予分配，依据 [IANA-CONSIDERATIONS]。指定专家应由 IESG 任命。若无法给出清晰、简明、足以确保互操作性的认证结果定义，指定专家有权要求引用一份出版物。除此之外的注册请求通常应予准许。指定专家也可以处理把任何现有注册标记为「已弃用」的请求。

任何两个条目都不能具有相同的 method 与 code 组合。

该注册表中的一个条目包含以下内容：

6.6.「Email Authentication Result Names」更新

本文档包含对该注册表的完整描述，并废止 [RFC7001]。相应地，依据本文档，该注册表已做出以下变更：

6.7. SMTP 增强状态码

「Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry」的「Enumerated Status Codes」子注册表中 X.7.25 的条目，已更新为引用本文档而非 [RFC7001]。

7. 安全考虑

在添加或处理 Authentication-Results 信头字段时，适用以下安全考虑：

7.1. 伪造的信头字段

如果某个 MUA 或过滤器访问的邮箱，其报文是由一台不合规的 MTA 处理的，而该 MUA 或过滤器又能理解 Authentication-Results 信头字段，那么它就可能基于伪造的信头字段得出错误结论。恶意用户或代理可以伪造一个信头字段，把接收方 ADMD 的 DNS 域名用作该字段值中的 authserv-id 标记，并以该值的其余部分声称该报文已被妥善认证。不合规的 MTA 不会剥离这个伪造的信头字段，于是 MUA 可能不恰当地信任它。

因此，最好不要默认启用对 Authentication-Results 信头字段的处理；相反，至少就做出过滤决策而言，应当忽略该字段，除非在核实边界 MTA 确实合规之后，由用户或管理员明确启用。让一个 MUA 知晓本规范、但同时持有一份「其 Authentication-Results 信头字段值得信任的主机名」的明确清单，是可以接受的；不过这份清单起初应当为空。

针对这一问题，此前曾提出过若干替代解决方案，列举如下。迄今为止，由于缺乏需求，它们尚未被开发；此处记录下来，以备将来这些信息可能有用：

  1. 可能最简单的做法是对该信头字段施加数字签名，例如使用 [DKIM]，MUA 可以借助已发布的公钥来验证它。虽然本文档的主要目的之一正是减轻 MUA 承担报文认证工作的负担，但这种做法只要求 MUA 学会单一一种认证方案，即便边界 MTA 处正在使用多种方案。注意 [DKIM] 要求 From 信头字段必须被签名；不过在本应用场景中，签名代理（一台可信 MTA）很可能无法认证该值，因此「它被签名了」这一事实应当被忽略。当 authserv-id 就是该 ADMD 的域名时，authserv-id 与这个有效内部签名的 "d=" DKIM 取值相匹配即已足够。
  2. 另一种做法是提供某种手段来询问添加了该信头字段的那台 MTA，以确认它是否确实在提供报文认证服务、并且确实处理过所涉报文；但考虑到设计与实现此类方案所需的工作量，这并不特别可取。
  3. 再一种做法可能是提供某种方法，去询问那些看起来处理过该报文的内部 MTA（依据 Received 信头字段判断），以确定其中是否有任何一台符合本备忘录第 5 节的规定。这同样具有潜在的高门槛。
  4. 可以为 [IMAP]、[SMTP] 与 [POP3] 定义扩展，允许 MUA 或过滤代理获取某个 ADMD 内所使用的 authserv-id，从而使其能够识别哪些 Authentication-Results 信头字段是可以信任的。
  5. 基于「内部 MTA 完全符合 [MAIL] 第 3.6 节，且合规的内部 MTA 使用其自身主机名或该 ADMD 的 DNS 域名作为 authserv-id 标记」这一前提，此处所提议的信头字段应当总是出现在由可信 MTA 添加的 Received 信头之上。这可以用作检验信头字段有效性的一项测试。

其中一些方案正在被考虑作为未来的工作。

无论如何，需要存在一种机制，使 MUA 或过滤器能够验证：看起来添加了该信头字段的那台主机 (a) 确实添加了它，并且 (b) 是为本次投递而合法地添加该信头字段的。鉴于当今部署的消息传递环境多种多样，共识似乎是：为此规定某种特定机制并不适合放在本文档中。

对伪造信头字段攻击的缓解，也可以通过把认证结果数据移入与该报文相关联的元数据之中来实现。特别地，可以确立一项 [SMTP] 扩展，把认证结果从边界 MTA 传达给中间 MTA 与投递 MTA；后者可以设法将认证结果存储为元数据，由知晓该协议中类似扩展的 [IMAP] 客户端连同报文一并取回并呈现。投递 MTA 会被告知只信任来自其所信任 MTA 经由该扩展传来的数据，而边界 MTA 则不接受任何来源经由该扩展传来的数据。在这样的安排中，外部代理没有任何途径可以伪造认证数据。

7.2. 具有误导性的结果

在某种「查询发送代理声誉」的服务被广泛部署之前，该信头字段存在并指示 "pass"，并不能使报文变得可信。到达的垃圾邮件或其他不受欢迎的邮件，完全有可能通过上文列举的若干方法的检查（例如一封由垃圾邮件发送者本人签名的、使用 [DKIM] 的垃圾邮件，而该发送者可能是垃圾邮件散布者或一台被攻陷的系统）。特别需要指出的是，上文讨论的「移除伪造信头字段」并不能解决这一问题。

因此，即便可能的恶意信头已被清洗，MUA 与下游过滤器在使用该信头时仍必须保持谨慎。

7.3. 信头字段的位置

尽管 [MAIL] 有相应要求，信头字段有时仍会在传输途中被中间 MTA 重新排序。「要求只在报文顶部添加信头字段」这一目标，正是对「某些 MTA 确实会重排信头字段，但大多数不会」这一事实的承认。因此，在一般情况下，总能看出在此处所定义信头字段被添加之后，有哪些（如果有的话）MTA 处理过该报文。

7.4. 反向 IP 查询的拒绝服务攻击

[SPF] 第 4.6.4 节描述了一种针对「尝试对到达客户端连接进行基于 DNS 的身份验证」的验证方的、基于 DNS 的拒绝服务攻击。希望执行此项检查并报告该信息的验证方，需要注意不要无限度地去解析 "A" 与 "PTR" 查询。利用本文档所规定 "iprev" 结果的 MUA 或其他过滤器，需要了解报告该结果的验证方所使用的算法，尤其是其局限性。

7.5. 反向散射的缓解

不遵循第 4.2 节的指引，可能导致一种拒绝服务攻击：向那些并未发送被拒报文的地址生成 [DSN] 报文（或等效物）。

7.6. 内部 MTA 清单

第 5 节描述了一套清洗流程，用以清除可能含有关于某报文之伪造认证结果的信头字段。一个合规的部署必须在每台 MTA 上都包含一份「已知合规且可信的其他 MTA」清单。随着内部基础设施的变化而未能及时更新这份清单，可能使 ADMD 暴露于攻击之下。

7.7. 针对认证方法的攻击

如果针对某种认证方法的攻击手法为人所知，那么显然，验证该方法的代理就可能被欺骗而认为一封不真实的报文是真实的，从而使该信头字段的值具有误导性。由此可知，任何针对本文档所支持之认证方法的攻击，也都属于此处的安全考虑。

7.8. 蓄意构造的畸形信头字段

攻击者有可能添加一个异常巨大或以其他方式畸形的 Authentication-Results 信头字段，试图发现或利用信头字段解析代码中的弱点。实现者必须彻底校验所有从 MTA 收到的此类信头字段，并且对蓄意的以及非蓄意的畸形信头字段都保持健壮。

7.9. 被攻陷的内部主机

一台被攻陷的内部 MUA 或 MTA，可能生成带有伪造 From 信头字段以及为其背书的伪造 Authentication-Results 信头字段的邮件。尽管「存在被攻陷的内部机器」显然是比「证明该信头字段的价值」更大的问题，但这一风险可以通过如下安排加以缓解：内部 MTA 在遇到「声称由某台可信边界 MTA 添加（如上文所述），但 [SMTP] 连接并非来自已知运行着授权 MTA 的内部机器」的该信头字段时，将其移除。不过在这样的配置中，合法的 MTA 在生成合法的纯内部报文时，就必须自行添加该信头字段。第 5 节也涵盖了这一点。

7.10. 被封装的实例

MIME 报文可以包含类型为 "message/rfc822" 的附件，其中含有其他报文。这样一封被封装的报文也可能含有 Authentication-Results 信头字段。虽然对这些字段的处理超出了本文档的预期范围（参见第 1.3 节），但在此给出一些面向 MUA 开发者的早期指引是恰当的。

由于 MTA 不太可能在邮箱投递之后再剥离 Authentication-Results 信头字段，第 4.1 节建议 MUA 忽略 MIME 附件内部的此类实例。此外，在把报文摘录提取到独立的邮件存储报文或其他介质中时，应当移除此类信头字段，以免它们日后被消费它们的 MUA 不当解读。

7.11. 反向映射

尽管本备忘录第 3 节明确支持 "iprev" 方法，但其作为认证机制的价值是有限的。鼓励本提案的实现者，以及使用其所转达数据的代理的实现者，在决定是否纳入对 "iprev" 的支持时，先熟悉 [DNSOP-REVERSE] 所提出的各项问题。

8. 参考文献

8.1. 规范性参考文献

8.2. 资料性参考文献

附录 A. 旧式 MUA（Legacy MUAs）

本协议的实现者应当意识到：许多 MUA 不太可能被改造以支持这个新的信头字段及其语义。为了便利并加快采纳，投递 MTA 或许可以考虑：在 Authentication-Results 信头字段之外，再添加一些能被现有 MUA 处理的内容。一个建议是：对于那些尚不含 Priority 信头字段的报文，添加一个 Priority 信头字段，其取值反映所完成认证的强度，例如认证薄弱或无认证时取 "low"，认证良好或强健时取 "normal" 或 "high"。

某些现代 MUA 已经能够基于该信头字段的内容进行过滤。然而，人们非常希望 MUA 能够把该信头字段的含义以某种图形化方式呈现给终端用户。在这一能力被加入之前（即在本提案及其后继规范被逐步采纳的过程中），可能仍需要其他过渡性的手段来传达认证结果。

附录 B. Authentication-Results 示例

本节给出若干使用该信头字段指示认证结果的示例。

B.1. 平凡情形；信头字段不存在

最平凡的情形：

     Received: from mail-router.example.com
                   (mail-router.example.com [192.0.2.1])
               by server.example.org (8.11.6/8.11.6)
                   with ESMTP id g1G0r1kA003489;
               Fri, Feb 15 2002 17:19:07 -0800
     From: sender@example.com
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: receiver@example.org
     Message-Id: <12345.abc@example.com>
     Subject: here's a sample

     Hello!  Goodbye!

                       示例 1：平凡情形

Authentication-Results 信头字段完全缺失。MUA 无法就该报文的有效性得出任何结论。出现这种情况的原因可能是：投递时报文认证服务不可用、根本未提供此类服务，或者该 MTA 不符合本规范。

B.2. 近乎平凡的情形；提供了服务，但未做认证

一封由符合本规范、但并未提供实际报文认证服务的 MTA 所投递的报文：

     Authentication-Results: example.org 1; none
     Received: from mail-router.example.com
                   (mail-router.example.com [192.0.2.1])
               by server.example.org (8.11.6/8.11.6)
                   with ESMTP id g1G0r1kA003489;
               Fri, Feb 15 2002 17:19:07 -0800
     From: sender@example.com
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: receiver@example.org
     Message-Id: <12345.abc@example.com>
     Subject: here's a sample

     Hello!  Goodbye!

        示例 2：信头存在，但未做认证

Authentication-Results 信头字段存在，表明投递方 MTA 符合本规范。它使用自己的 DNS 域名作为 authserv-id。"none" 的出现（以及任何 method 或 result 标记的缺席）表明未进行任何报文认证。该字段内容所遵循规范的版本号被明确给出。

B.3. 提供了服务，做了认证

一封由符合本规范、并施加了某种报文认证的 MTA 所投递的报文：

     Authentication-Results: example.com;
               spf=pass smtp.mailfrom=example.net
     Received: from dialup-1-2-3-4.example.net
                   (dialup-1-2-3-4.example.net [192.0.2.200])
               by mail-router.example.com (8.11.6/8.11.6)
                   with ESMTP id g1G0r1kA003489;
               Fri, Feb 15 2002 17:19:07 -0800
     From: sender@example.net
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: receiver@example.com
     Message-Id: <12345.abc@example.net>
     Subject: here's a sample

     Hello!  Goodbye!

                 示例 3：报告结果的信头

Authentication-Results 信头字段存在，表明边界 MTA 符合本规范。authserv-id 再次采用了 DNS 域名。此外，该报文经由 [SPF] 所规定的方法被该 MTA 认证。请注意，由于该方法无法认证 local-part，它已从结果值中被省略。如有需要，MUA 可以提取并转达这些额外信息。

B.4. 提供了服务，做了多项认证，单台 MTA

一封经由单台符合本规范的 MTA 入站中继、并施加了三种不同报文认证检查的报文：

     Authentication-Results: example.com;
               auth=pass (cram-md5) smtp.auth=sender@example.net;
               spf=pass smtp.mailfrom=example.net
     Authentication-Results: example.com;
               sender-id=pass header.from=example.net
     Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6)
                   (dialup-1-2-3-4.example.net [192.0.2.200])
               by mail-router.example.com (8.11.6/8.11.6)
                   with ESMTPA id g1G0r1kA003489;
               Fri, Feb 15 2002 17:19:07 -0800
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: receiver@example.com
     From: sender@example.net
     Message-Id: <12345.abc@example.net>
     Subject: here's a sample

     Hello!  Goodbye!

          示例 4：报告来自同一台 MTA 之结果的信头

Authentication-Results 信头字段存在，表明投递方 MTA 符合本规范。同样，接收方的 DNS 域名被用作 authserv-id。此外，发件人通过 [AUTH] 所规定的方法向该 MTA 认证了自己的身份，并且 SPF 与 Sender ID 检查均已执行且均通过。如有需要，MUA 可以提取并转达这些额外信息。

此处并不需要两个 Authentication-Results 信头字段，因为所有检查都是由同一台主机完成的。执行认证的代理本可以把所有结果合并到一个信头字段中。

本示例展示了这样一个场景：一位使用拨号连接的远程用户（example.net）向边界 MTA（example.com）发送邮件，并使用 SMTP 认证来证明身份。该拨号服务提供商已被明确授权可以代表 example.com 中继邮件，因而 SPF 与 Sender ID 检查均产生 "pass" 结果。

B.5. 提供了服务，做了多项认证，不同 MTA

一封由两台不同的、均符合本规范的 MTA 入站中继、并施加了多项报文认证检查的报文：

     Authentication-Results: example.com;
               sender-id=fail header.from=example.com;
               dkim=pass (good signature) header.d=example.com
     Received: from mail-router.example.com
                   (mail-router.example.com [192.0.2.1])
               by auth-checker.example.com (8.11.6/8.11.6)
                   with ESMTP id i7PK0sH7021929;
               Fri, Feb 15 2002 17:19:22 -0800
     DKIM-Signature:  v=1; a=rsa-sha256; s=gatsby; d=example.com;
               t=1188964191; c=simple/simple; h=From:Date:To:Subject:
               Message-Id:Authentication-Results;
               bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
               b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
     Authentication-Results: example.com;
               auth=pass (cram-md5) smtp.auth=sender@example.com;
               spf=fail smtp.mailfrom=example.com
     Received: from dialup-1-2-3-4.example.net
                   (dialup-1-2-3-4.example.net [192.0.2.200])
               by mail-router.example.com (8.11.6/8.11.6)
                   with ESMTPA id g1G0r1kA003489;
               Fri, Feb 15 2002 17:19:07 -0800
     From: sender@example.com
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: receiver@example.com
     Message-Id: <12345.abc@example.com>
     Subject: here's a sample

     Hello!  Goodbye!

       示例 5：报告来自多台 MTA 之结果的信头

Authentication-Results 信头字段存在，表明符合本规范。同样，所使用的 authserv-id 是收件方的 DNS 域名。该信头字段出现了两次，因为投递链中有两台不同的 MTA 做了认证测试。第一台 MTA（mail-router.example.com）报告 SMTP AUTH 与 SPF 均被使用，前者通过而后者失败。在 SMTP AUTH 这一项中，注释字段提供了额外信息，MUA 可自行选择是否呈现。

第二台 MTA（auth-checker.example.com）报告它做了 Sender ID 测试（失败）与 DKIM 测试（通过）。同样，关于其中一项测试的额外数据以注释形式提供，MUA 可以选择是否呈现。此处另一个值得注意之处是：example.com 添加的 DKIM 签名保证了下方那个 Authentication-Results 字段的完整性。

由于两组认证检查是由不同主机完成的，本示例中的信头字段无法合并。

本示例展示了更为典型的邮件传输过程：邮件从一位使用 example.net 拨号连接的用户发往 example.com。该用户看起来是合法的，因为他/她持有有效口令，可以在边界 MTA 处使用 SMTP AUTH 完成认证。SPF 与 Sender ID 测试失败，因为 example.com 并未授予 example.net 代其中继邮件的权限。然而 DKIM 测试通过，因为发送用户持有与 example.com 所发布公钥之一相匹配的私钥，并用它对报文进行了签名。

B.6. 提供了服务，做了多层级认证

一封在多个阶段做了认证的报文，其中一个阶段位于接收方 ADMD 之外：

     Authentication-Results: example.com;
           dkim=pass reason="good signature"
             header.i=@mail-router.example.net;
           dkim=fail reason="bad signature"
             header.i=@newyork.example.com
     Received: from mail-router.example.net
               (mail-router.example.net [192.0.2.250])
           by chicago.example.com (8.11.6/8.11.6)
               for <recipient@chicago.example.com>
               with ESMTP id i7PK0sH7021929;
           Fri, Feb 15 2002 17:19:22 -0800
     DKIM-Signature: v=1; a=rsa-sha256; s=furble;
           d=mail-router.example.net; t=1188964198; c=relaxed/simple;
           h=From:Date:To:Message-Id:Subject:Authentication-Results;
           bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=;
           b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3=
     Authentication-Results: example.net;
           dkim=pass (good signature) header.i=@newyork.example.com
     Received: from smtp.newyork.example.com
               (smtp.newyork.example.com [192.0.2.220])
           by mail-router.example.net (8.11.6/8.11.6)
               with ESMTP id g1G0r1kA003489;
           Fri, Feb 15 2002 17:19:07 -0800
     DKIM-Signature: v=1; a=rsa-sha256; s=gatsby;
           d=newyork.example.com;
           t=1188964191; c=simple/simple;
           h=From:Date:To:Message-Id:Subject;
           bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
           b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
     From: sender@newyork.example.com
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: meetings@example.net
     Message-Id: <12345.abc@newyork.example.com>
     Subject: here's a sample

     示例 6：报告来自不同 ADMD 中多台 MTA 之结果的信头

在本示例中，我们看到了信任边界被扩展的多层级认证。

该报文由 example.com 纽约办公室（newyork.example.com）的某人发出，发往由某个中间方管理的一个邮件列表。报文在源头使用 DKIM 进行了签名。

报文被发送到 example.com 所使用的邮件列表服务提供商 example.net。在那里，meetings@example.net 被展开为一长串收件人，其中一位在芝加哥办公室。在本示例中，我们假定 chicago.example.com 的信任边界包含 example.net 处的邮件列表服务器。

那里的邮件列表服务器首先认证了该报文，并附加了一个 Authentication-Results 信头字段来表明这一点，使用其 DNS 域名作为 authserv-id。随后它修改了报文，在正文后附加了一些页脚文本，其中包括退订说明之类的事务性信息。最后，邮件列表服务器附加了第二个 DKIM 签名，并开始分发该报文。

chicago.example.com 的边界 MTA 明确信任来自 mail-router.example.net 的结果，因此那个信头字段没有被移除。它对两个签名都做了评估，判定第一个（最近添加的）为 "pass"，但由于前述的修改，第二个为 "fail"。然而，第一个签名覆盖了在 mail-router.example.net 处添加的 Authentication-Results 信头，而后者验证了第二个签名。因此可以间接判定：两个签名所声称的认证确实都是有效的。

请注意，此处使用了两种呈现结果元数据的风格。其一是出现了 "reason=" 子句，它便于解析器提取；其二是使用 ABNF 中的 CFWS 产生式，把这类数据作为信头字段注释包含进来。鉴于邮件信头字段所支持的语法多种多样，后者对解析器而言可能更难提取。

B.7. 注释密集的示例

形式化语法允许在内容中的许多位置插入注释。为便于说明，下面这个示例同样是合法的：

    Authentication-Results: foo.example.net (foobar) 1 (baz);
        dkim (Because I like it) / 1 (One yay) = (wait for it) fail
          policy (A dot can go here) . (like that) expired
          (this surprised me) = (as I wasn't expecting it) 1362471462

     示例 7：一个注释极其密集、但完全合法的示例

附录 C. 关于报文认证的运营考虑

本协议所依据的理念是：认证（以及可以预见的将来的声誉评估）工作通常由边界 MTA 完成，而非由 MUA 或中间 MTA 完成；后者只是使用前者所判定的结果。这当然不是参与电子邮件或报文认证的强制要求，但本协议及其迄今为止的部署都基于这一模型。该假定满足了 ADMD 的若干常见需求：

  1. 服务运营者倾向于尽可能靠近 ADMD 边界处解决问题报文的处置。例如，这使得可以在 SMTP 层面拒绝报文，而不必在内部生成一个 DSN。因此，若把认证或声誉工作完全放在 MUA 或中间 MTA 上完成，这一诉求就无法实现。
  2. 边界 MTA 更有可能直接访问外部的认证或声誉信息源，因为现代 MUA 更可能被严密的防火墙隔离。因此，某些 MUA 若没有复杂的代理配置或类似负担，甚至可能根本无法完成执行认证或声誉评估的任务。
  3. MUA 依赖其信任边界内的上游 MTA，对报文的信封、信头与内容做出（尽可能）正确的评估。因此，MUA 不需要知道如何完成上游 MTA 所做的工作；它们只需要那些工作的结果。
  4. 对报文质量的评估——从简单的标记匹配（例如一份优选 DNS 域名清单）到密码分析（例如公钥/私钥运算）——确实有成本，因而需要尽量减少。为此，在边界 MTA 处执行这些测试，远优于在处理该报文的每一个 MUA 处都做一遍。如果某个 ADMD 的环境遵循常见的消息传递协议，那么由边界 MTA 执行的声誉查询或认证检查，与由 MUA 执行的同一查询会返回相同结果。相比之下，在由 MUA 完成这些工作的环境中，一封发给多个收件人的报文会导致对同一封报文进行多次（即在每个 MUA 处）认证或声誉评估，造成资源使用的无谓放大，并制造出一个可能的拒绝服务攻击向量。
  5. 把变更降到最低是好事。随着新的认证与声誉方法出现，该信头字段所支持的方法列表大概会被扩充。如果 MUA 只是消费该信头字段的内容，而不是真的去尝试完成认证与/或声誉工作，那么 MUA 只需学会解析该信头字段一次；新方法的出现只需要在 MUA 处做配置变更，以及在 MTA 处做软件变更（而 MTA 的数量大概更少）。在选择把这些功能实现于 MTA 还是 MUA 时，必须考虑个体灵活性、基础设施惯性与工作量规模等问题。更改单个 MUA 通常比更改 MTA 更容易，因为该修改影响的用户更少，可以以较低的谨慎程度推进；然而，更改许多 MUA 比更改数量更少的 MTA 要费力得多。
  6. 对于影响报文投递与展示的决策而言，基于认证与声誉的评估最好在报文传输时进行——即在报文走向用户收件箱的旅程之中，而非事后。DKIM 密钥与 IP 地址声誉等都可能随时间变化甚至失效，而用户可能在报文投递之后过很久才去阅读它。因此，一旦投递过程完成，这项工作的价值就会降低，而且可能降低得很快。这严重削弱了在 MTA 之外的其他地方完成这项工作的价值。

在一个 ADMD 之内可以有许多运营选择，包括在何处执行认证与/或声誉评估。当前规范并不对这些选择做任何规定；相反，它便利了这样一类情形：由分析的某一阶段所产生的信息，需要随报文一同传送到下一阶段。

附录 D. 自 RFC 7001 以来的变更

致谢（Acknowledgments）

作者谨此感谢以下个人对本文档的评审与建设性批评：Stephane Bortzmeyer、Scott Kitterman、John Levine、Tom Petch 与 Pete Resnick。

作者地址（Author's Address）

Murray S. Kucherawy
270 Upland Drive
San Francisco, CA 94127
United States

Email: superuser@gmail.com