非官方中文译本声明：本页为 IETF RFC 8460《SMTP TLS Reporting（SMTP TLS 报告，简称 TLS-RPT）》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc8460。

RFC 8460：SMTP TLS 报告（TLS-RPT）

标准跟踪（Standards Track）· D. Margolis（Google）、A. Brotman（Comcast）、B. Ramakrishnan（Oath）、J. Jones（Microsoft）、M. Risher（Google）· 2018 年 9 月 · 类别：Standards Track · ISSN: 2070-1721

摘要

现有多种用于在 SMTP 邮件传输代理（MTA）之间建立加密信道的协议，包括 STARTTLS、基于 DNS 的命名实体认证（DANE）TLSA，以及 MTA 严格传输安全（MTA-STS）。这些协议可能因配置错误或主动攻击而失败，导致邮件无法投递，或者在未加密或未认证信道上投递。本文档描述了一种报告机制与格式，发送系统借此可以与接收域共享关于潜在失败的统计信息与具体信息。接收域随后可以利用这些信息检测潜在攻击，并诊断无意的配置错误。

本备忘录的状态

本文档是一份互联网标准跟踪（Internet Standards Track）文档。

本文档是互联网工程任务组（IETF）的产物，代表 IETF 社区的共识，已经过公开评审，并由互联网工程指导组（IESG）批准发布。有关互联网标准的更多信息参见 RFC 7841 第 2 节。

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

Copyright (c) 2018 IETF 信托及被列为文档作者的个人。保留所有权利。

本文档受 BCP 78 以及 IETF 信托的《IETF 文档相关法律规定》（https://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细审阅这些文档，因为它们描述了您就本文档所享有的权利与限制。从本文档中提取的代码组件必须包含 [RFC 信托法律条款] 第 4.e 节所述的简化 BSD 许可证文本，并按该简化 BSD 许可证所述"不提供担保"的方式提供。

目录

1. 引言

对 SMTP 的 STARTTLS 扩展 [RFC3207] 允许 SMTP 客户端与主机通过 TLS 建立安全的 SMTP 会话。该协议设计采用一种后来被称为"机会性安全"（Opportunistic Security，OS）[RFC7435] 的方法。这种方法与不支 STARTTLS 的客户端保持互操作性，但这意味着任何攻击者都可能潜在地窃听会话。攻击者可以通过删除 SMTP 会话的某些部分（例如"250 STARTTLS"响应）来执行降级或拦截攻击，或者重定向整个 SMTP 会话（例如通过覆盖投递域解析到的 MX 记录）。

由于此类"降级攻击"对接收 MTA 而言未必显而易见，本文档定义了一种机制，供发送域就 MTA 到 MTA 对话多个阶段的失败进行报告。

接收域也可以利用 MTA-STS [RFC8461] 或 DANE [RFC6698] 所定义的机制来发布额外的加密与认证要求；本文档为兼容 MTA-STS 或 DANE 的发送域定义了一种机制，用于与接收域共享成功与失败统计信息。

具体而言，本文档定义了一种报告模式（schema），涵盖路由、DNS 解析以及 STARTTLS 协商中的失败；DANE [RFC6698] 与 MTA-STS [RFC8461] 的策略验证错误；以及一条标准 TXT 记录，接收域可用其指示此类格式的报告应发送到何处。该报告也可以作为"心跳"信号，表明系统正在按预期成功协商会话期间的 TLS。

本文档旨在作为 SMTP MTA-STS [RFC8461] 规范的配套文档，并为那些实现 DANE [RFC7672] 的部署添加报告能力。

1.1. 术语

本文档中的关键词"MUST（必须）"、"MUST NOT（不得）"、"REQUIRED（要求）"、"SHALL（应）"、"SHALL NOT（不应）"、"SHOULD（应该）"、"SHOULD NOT（不应该）"、"RECOMMENDED（推荐）"、"NOT RECOMMENDED（不建议）"、"MAY（可以）"和"OPTIONAL（可选）"，当且仅当它们以全大写形式出现（如这里所示）时，应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。

我们还为本文档后续使用定义以下术语：

2. 相关技术

3. 报告策略

某个域会向自己的 DNS 发布一条记录，表明它希望接收报告。这些 SMTP TLSRPT 策略经由 DNS 从策略域的区域（zone）以 TXT 记录的形式分发（类似于基于域的消息认证、报告与一致性（DMARC）策略），位于名称"_smtp._tls"之下。例如，对于策略域"example.com"，接收方的 TLSRPT 策略可以从"_smtp._tls.example.com"检索得到。

策略由以下指令组成：

示例 DKIM 记录：

      dkim_selector._domainkey.example.com TXT
            "v=DKIM1;k=rsa;s=tlsrpt;p=Mlf4qwSZfase4fa=="

"_smtp._tls" TXT 记录的形式化定义（使用 [RFC5234] 与 [RFC7405]）如下：

        tlsrpt-record     = tlsrpt-version 1*(field-delim tlsrpt-field)
                            [field-delim]

        field-delim       = *WSP ";" *WSP

        tlsrpt-field      = tlsrpt-rua /        ; Note that the
                            tlsrpt-extension    ; tlsrpt-rua record is
                                                ; required.

        tlsrpt-version    = %s"v=TLSRPTv1"

        tlsrpt-rua        = %s"rua="
                            tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri)

        tlsrpt-uri        = URI
                            ; "URI" is imported from [RFC3986];
                            ; commas (ASCII 0x2C), exclamation
                            ; points (ASCII 0x21), and semicolons
                            ; (ASCII 0x3B) MUST be encoded

        tlsrpt-extension  = tlsrpt-ext-name "=" tlsrpt-ext-value

        tlsrpt-ext-name   = (ALPHA / DIGIT) *31(ALPHA /
                            DIGIT / "_" / "-" / ".")

        tlsrpt-ext-value  = 1*(%x21-3A / %x3C / %x3E-7E)
                            ; chars excluding "=", ";", SP, and control
                            ; chars

如果解析器返回了多条"_smtp._tls"的 TXT 记录，则那些不以"v=TLSRPTv1;"开头的记录将被丢弃。如果所得记录的数量不为 1，发送方必须（MUST）假定接收域并未实现 TLSRPT。如果所得的 TXT 记录包含多个字符串（如 [RFC7208] 第 3.3 节所述），则该记录必须（MUST）被视为这些字符串被拼接在一起且不添加空格。

该记录支持声明多个 rua；如果存在多个，报告方可以（MAY）尝试投递到每个受支持的 rua 目标。接收方可以（MAY）选择仅尝试投递到其中一个端点；但是，在其中一个端点接受报告投递之前，不应（SHOULD NOT）认为报告已成功投递。

解析器必须（MUST）接受语法上有效（即由分号分隔的有效键/值对）的 TXT 记录，并实现本规范的超集，在此情况下未知字段应被忽略（SHALL）。

3.1. 报告策略示例

3.1.1. 使用 MAILTO 报告

            _smtp._tls.example.com. IN TXT \
                    "v=TLSRPTv1;rua=mailto:reports@example.com"

3.1.2. 使用 HTTPS 报告

           _smtp._tls.example.com. IN TXT \
                   "v=TLSRPTv1; \
                   rua=https://reporting.example.com/v1/tlsrpt"

4. 报告模式（Schema）

报告被构造成一个以互联网 JSON（I-JSON）格式 [RFC7493] 编码的纯文本文件。

聚合报告包含以下字段：

注意，失败类型并非互斥；当单次发送尝试遇到多个错误时，一条聚合报告可能包含彼此重叠的失败类型"计数"。报告方可以报告多个已应用的策略（例如，针对同一域与同一 MX 的 MTA-STS 策略与 DANE TLSA 记录）。因此，即使在仅应用了单一策略的情况下，报告正文中的"policies"字段也必须（MUST）是一个数组，而非单一值。

在存在多种失败类型的情况下，"failure-details"数组将包含多个条目。每个条目都拥有自身关于该类失败的信息集合。

4.1. 报告时间范围

报告应当（SHOULD）覆盖完整的一天，从 UTC 00:00 到 24:00。这应当有助于更轻松地关联失败事件。为避免无意中过载处理报告的系统，报告应当（SHOULD）在延迟一段时间（也许是数小时）之后再投递。

举例来说，某个发送站点可能希望引入最长四小时的随机延迟：

          func generate_sleep_delay() {
            min_delay = 1
            max_delay = 14400
            rand = random(min_delay, max_delay)
            return rand
          }

          func generate_report(policy_domain) {
            do_rpt_work(policy_domain)
            send_rpt(policy_domain)
          }

          func generate_tlsrpt() {
            sleep(generate_sleep_delay())
            for policy_domain in list_of_tlsrpt_enabled_domains {
              generate_report(policy_domain)
            }
          }

4.2. 投递摘要

4.2.1. 成功计数

4.2.2. 失败计数

4.3. 结果类型

结果类型列表将以如下的最小集合起步，并预期随着真实世界经验而增长。初始集合在 4.3.1 至 4.3.4 节中概述：

4.3.1. 协商失败

4.3.2. 策略失败

4.3.2.1. DANE 特有的策略失败

4.3.2.2. MTA-STS 特有的策略失败

4.3.3. 一般性失败

当某个协商失败无法归入上述任一"协商失败"类别时，报告方应当（SHOULD）使用"validation-failure"类别。随着 TLS 的发展与日益复杂，新的机制可能无法轻易归类。这使得一个通用的反馈类别成为可能。使用此类别时，报告方还应当（SHOULD）使用"failure-reason-code"向接收实体提供某些反馈。该字段旨在成为一个简短的文本字段，其内容应为错误码或错误文本，例如"X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION"。

4.3.4. 瞬时失败

由于网络过于繁忙、TCP 超时等导致的瞬时错误，不要求（不强制）报告。

4.4. JSON 报告模式

该 JSON 模式派生自 HTTP 公钥固定（HPKP）的 JSON 模式；参见 [RFC7469] 第 3 节。

 {
   "organization-name": organization-name,
   "date-range": {
     "start-datetime": date-time,
     "end-datetime": date-time
   },
   "contact-info": email-address,
   "report-id": report-id,
   "policies": [{
     "policy": {
       "policy-type": policy-type,
       "policy-string": policy-string,
       "policy-domain": domain,
       "mx-host": mx-host-pattern
     },
     "summary": {
       "total-successful-session-count": total-successful-session-count,
       "total-failure-session-count": total-failure-session-count
     },
     "failure-details": [
       {
         "result-type": result-type,
         "sending-mta-ip": ip-address,
         "receiving-mx-hostname": receiving-mx-hostname,
         "receiving-mx-helo": receiving-mx-helo,
         "receiving-ip": receiving-ip,
         "failed-session-count": failed-session-count,
         "additional-information": additional-info-uri,
         "failure-reason-code": failure-reason-code
         }
       ]
     }
   ]
 }

出于报告目的，IPv4 地址通过以下 ABNF 定义：

     IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
     dec-octet     = DIGIT                 ; 0-9
                   / %x31-39 DIGIT         ; 10-99
                   / "1" 2DIGIT            ; 100-199
                   / "2" %x30-34 DIGIT     ; 200-249
                   / "25" %x30-35          ; 250-255

而 IPv6 地址通过以下 ABNF 定义：

     IPv6address = <as defined in [RFC5954]>

4.5. 策略样例

报告正文的一部分包含了在尝试中转（relay）到目的地时所应用的策略。

对于 DANE TLSA 策略，这是一个字符串的 JSON 数组，每个字符串表示单个 TLSA 资源记录的 RDATA，以空格分隔列出其四个 TLSA 字段；这些字段采用呈现格式（定义于 [RFC6698] 第 2.2 节），内部没有空格或分组括号：

       [
       "3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513
              D747D1D085D",
       "3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513
              D747D1D1234"
       ]

对于 MTA-STS 策略，这是一个 JSON 字符串数组，表示接收站点所声明的策略，包括其中可能存在的任何错误。注意，当存在多个"mx"值时，它们必须作为策略数组中独立的"mx"元素列出，而不是作为单一的嵌套"mx"子数组。

                       [
                       "version: STSv1",
                       "mode: testing",
                       "mx: mx1.example.com",
                       "mx: mx2.example.com",
                       "mx: mx.backup-example.com",
                       "max_age: 604800"
                       ]

5. 报告投递

报告既可以通过 SMTP（作为一封电子邮件消息）投递，也可以通过 HTTP POST 投递。

5.1. 报告文件名

文件名建议（RECOMMENDED）使用以下 ABNF 构造：

    filename        = sender "!" policy-domain "!" begin-timestamp
                      "!" end-timestamp [ "!" unique-id ] "." extension

    unique-id       = 1*(ALPHA / DIGIT)

    sender          = domain ; from [RFC5321] -- this is used
                      ; as the domain for the `contact-info`
                      ; address in the report body.
                      ; In the case of Internationalized Domain
                      ; Names [RFC5891], the domain MUST consist of
                      ; the Punycode-encoded A-labels [RFC3492] and
                      ; not the U-labels.

    policy-domain   = domain
                      ; In the case of Internationalized Domain
                      ; Names [RFC5891], the domain MUST consist of
                      ; the Punycode-encoded A-labels [RFC3492] and
                      ; not the U-labels.

    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

    extension       = "json" / "json.gz"

对于普通的 JSON 文件，扩展名必须（MUST）为"json"；对于使用 gzip 压缩的 JSON 文件，扩展名必须（MUST）为"json.gz"。

"unique-id"允许发送 MTA 生成一个可选的唯一 ID，用于区分由不同来源同时为同一策略域生成的多个报告。例如，下面可能是来自发送 MTA "mail.sndr.example.com"、发往策略域"example.net"的一份压缩报告的可能文件名：

   "mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz"

5.2. 压缩

对于电子邮件与 HTTPS 两种传输方式，报告应当（SHOULD）经过 gzip [RFC1952] 压缩。拒绝应用压缩可能导致报告过大而无法被接收方处理（一个常见的可观察接收方限制是十兆字节）；压缩该文件能够提高报告被接受的概率，代价是一定的计算开销。

5.3. 电子邮件传输

报告可以（MAY）通过电子邮件投递。为使报告对接收方可被机器解析，我们定义了一个顶层媒体类型"multipart/report"，并带有一个新参数"report-type="tlsrpt""。在其内部有两个部分：第一部分是人类可读的，通常为"text/plain"；第二部分是机器可读的，使用所定义的新媒体类型"application/tlsrpt+json"。如果经过压缩，报告应当使用媒体类型"application/tlsrpt+gzip"。

此外，定义了以下两个新的顶层报文头字段：

   "TLS-Report-Domain: Receiver-Domain"

   "TLS-Report-Submitter: Sender-Domain"

"TLS-Report-Submitter"的值必须（MUST）与报告正文中"contact-info"的域 [RFC5321] 相匹配。这些报文头字段必须（MUST）被包含，并且应当便于轻松搜索由某个报告域或特定提交者提交的所有报告，例如在 IMAP [RFC3501] 中：

   "s SEARCH HEADER "TLS-Report-Domain" "example.com""

假定聚合报告地址具备处理能力，能够解析新的报文头字段并提取具有规定媒体类型与文件名的 MIME 部分，而忽略其余部分。这些附加头字段应当（SHOULD）被包含在消息的 DKIM [RFC6376] 签名中。

报告提交的 RFC5322.Subject 字段应当（SHOULD）符合以下 ABNF：

       tlsrpt-subject = %s"Report" FWS               ; "Report"
                        %s"Domain:" FWS              ; "Domain:"
                        domain-name FWS              ; per [RFC6376]
                        %s"Submitter:" FWS           ; "Submitter:"
                        domain-name FWS              ; per [RFC6376]
                        %s"Report-ID:" FWS           ; "Report-ID:
                        <" id-left "@" id-right ">" ; per [RFC5322]
                        [CFWS]                       ; per [RFC5322]
                                                     ; (as with FWS)

第一个 domain-name 指示生成该报告所关于的 DNS 域名。第二个 domain-name 指示代表生成该报告的发送 MTA 的 DNS 域名。"Report-ID:"字段部分的目的是使策略域能够识别并忽略可能由某个发送 MTA 发送的重复报告。

例如，下面可能是来自发送 MTA "mail.sender.example.com"、发往策略域"example.net"的一份报告的可能 Subject 字段。它按照 [RFC5322] 所允许的进行了折行：

              Subject: Report Domain: example.net
                  Submitter: mail.sender.example.com
                  Report-ID: <735ff.e317+bf22029@mailexample.net>

5.3.1. 报告示例

      From: tlsrpt@mail.sender.example.com
          Date: Fri, May 09 2017 16:54:30 -0800
          To: mts-sts-tlsrpt@example.net
          Subject: Report Domain: example.net
              Submitter: mail.sender.example.com
              Report-ID: <735ff.e317+bf22029@example.net>
          TLS-Report-Domain: example.net
          TLS-Report-Submitter: mail.sender.example.com
          MIME-Version: 1.0
          Content-Type: multipart/report; report-type="tlsrpt";
              boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
          Content-Language: en-us

          This is a multipart message in MIME format.

          ------=_NextPart_000_024E_01CC9B0A.AFE54C00
          Content-Type: text/plain; charset="us-ascii"
          Content-Transfer-Encoding: 7bit

          This is an aggregate TLS report from mail.sender.example.com

          ------=_NextPart_000_024E_01CC9B0A.AFE54C00
          Content-Type: application/tlsrpt+gzip
          Content-Transfer-Encoding: base64
          Content-Disposition: attachment;
              filename="mail.sender.example!example.com!
                        1013662812!1013749130.json.gz"

          <gzipped content of report>

     ------=_NextPart_000_024E_01CC9B0A.AFE54C00--
     ...

注意，当通过 SMTP 发送失败报告时，发送 MTA 不得（MUST NOT）遵从 MTA-STS 或 DANE TLSA 失败。

5.4. HTTPS 传输

报告可以（MAY）通过 POST 投递到 HTTPS。如果经过压缩，报告应当（SHOULD）使用媒体类型"application/tlsrpt+gzip"；否则应当（SHOULD）使用媒体类型"application/tlsrpt+json"（参见第 6 节"IANA 考量"）。

接收系统必须（MUST）从其 HTTPS 服务器返回一个"成功"响应，通常为 200 或 201 这样的 HTTP 代码 [RFC7231]。其他代码可能表示投递失败，并可以按照本地发送方策略进行重试。接收系统不要求在收到报告时即进行处理，并且可以（MAY）将其存储起来以便后续处理。

5.5. 投递重试

在发生投递失败的情况下，无论采用何种投递方式，发送方应当（SHOULD）在初次尝试之后最多 24 小时内尝试重新投递。如前所述，报告是可选的，因此虽然尝试重新投递是理想的，但并不要求。如果尝试了多次重试，理想情况下它们应当（SHOULD）以指数退避的方式进行。

5.6. 元数据差异

如上所述，声明其中数据信息的方式有多种可变之处。如果通过 subject 或 filename 声明的任何条目与报告本身不一致，则必须（MUST）将该报告视为权威来源。

6. IANA 考量

以下是本文档所讨论的 IANA 考量。

6.1. 报文头字段

以下是根据 [RFC3864] 的互联网编号分配局（IANA）永久报文头字段注册信息。

头部字段名适用协议状态作者/变更控制者规范文档
TLS-Report-DomainmailstandardIETFRFC 8460
TLS-Report-SubmittermailstandardIETFRFC 8460

6.2. 报告类型

本文档为 [RFC6522] 中定义的"multipart/report"顶层媒体类型的 Content-Type 头字段的"report-type"参数创建一个新的注册表。

该注册表名称为"Report Type Registry（报告类型注册表）"，更新该注册表的流程将为"Specification Required（需要规范）"[RFC8126]。

该注册表中的条目应包含：

初始条目如下：

Report-TypeMedia TypeRegistered ByComment
tlsrptapplication/tlsrpt+gzip, application/tlsrpt+json[RFC8460]可与本 report-type 一起使用的媒体类型在 [RFC8460] 第 6.4 与 6.5 节中定义
disposition-notificationmessage/disposition-notification[RFC8098] 第 10 节
disposition-notificationmessage/global-disposition-notification[RFC6533] 第 6 节
delivery-statusmessage/delivery-status[RFC3464] 第 6.2 节
delivery-statusmessage/global-delivery-status[RFC6533] 第 6 节

6.3. +gzip 媒体类型后缀

本文档注册一个新的媒体类型后缀"+gzip"。gzip 格式是一种公共领域、跨平台、可互操作的文件存储与传输格式，在 [RFC1952] 中规范；它支持压缩，并被多种文件格式用作底层表示。媒体类型"application/gzip"已为这类文件注册。后缀"+gzip"可以与任何其表示遵循为"application/gzip"所建立之表示的媒体类型一起使用。用于媒体类型的结构化语法后缀的注册表如下：

类型名称：gzip 文件存储与传输格式。

后缀：+gzip

参考： [RFC1952] [RFC6713]

编码考量：gzip 是一种二进制编码。

片段标识符考量：为 +gzip 指定的片段标识符的语法与语义应当（SHOULD）与为"application/gzip"所指定的相同。（在本文档发布时，尚未为"application/gzip"定义片段标识语法。）针对特定"xxx/yyy+gzip"的片段标识符的语法与语义应当按如下方式处理：

互操作性考量：N/A

安全考量：gzip 格式不提供机密性保护。完整性保护由 Adler-32 校验和提供，它并非密码学意义上强健。另见 [RFC6713] 的安全考量。每个以 +gzip 后缀注册的独立媒体类型可能有额外的安全考量。此外，gzip 对象可以包含多个文件及关联路径。在提取文件时，必须对文件路径进行验证；否则恶意文件路径可能导致提取程序覆盖应用程序或系统文件。

联系：art@ietf.org

作者/变更控制者：互联网工程任务组（iesg@ietf.org）。

6.4. application/tlsrpt+json 媒体类型

本文档注册多个媒体类型，从下表 1 开始。

TypeSubtypeFile ExtSpecification
applicationtlsrpt+json.json第 5.3 节

表 1：SMTP TLS 报告媒体类型

类型名称：application

子类型名称：tlsrpt+json

必需参数：N/A

可选参数：N/A

编码考量：与为"application/json"媒体类型所指定的编码考量相同。参见 [RFC7493]。

安全考量：与 SMTP TLS 报告相关的安全考量在第 7 节讨论。

互操作性考量：本文档规定了合规消息的格式及其解释。

发布规范：RFC 8460 第 5.3 节。

使用此媒体类型的应用：邮件用户代理（MUA）与邮件传输代理。

附加信息：

进一步联系的姓名与电子邮件地址：参见"作者地址"一节。

预期用途：COMMON

使用限制：N/A

作者：参见"作者地址"一节。

变更控制者：互联网工程任务组（iesg@ietf.org）。

6.5. application/tlsrpt+gzip 媒体类型

TypeSubtypeFile ExtSpecification
applicationtlsrpt+gzip.gz第 5.3 节

表 2：SMTP TLS 报告媒体类型

类型名称：application

子类型名称：tlsrpt+gzip

必需参数：N/A

可选参数：N/A

编码考量：二进制

安全考量：与 SMTP TLS 报告相关的安全考量在第 7 节讨论。与 gzip 压缩相关的安全考量在 RFC 6713 中讨论。

互操作性考量：本文档规定了合规消息的格式及其解释。

发布规范：RFC 8460 第 5.3 节。

使用此媒体类型的应用：邮件用户代理（MUA）与邮件传输代理。

附加信息：

进一步联系的姓名与电子邮件地址：参见"作者地址"一节。

预期用途：COMMON

使用限制：N/A

作者：参见"作者地址"一节。

变更控制者：互联网工程任务组（iesg@ietf.org）。

6.6. STARTTLS 验证结果类型

本文档创建一个新注册表"STARTTLS Validation Result Types（STARTTLS 验证结果类型）"。该注册表的初始条目如下：

Result TypeDescription
starttls-not-supported第 4.3 节
certificate-host-mismatch第 4.3 节
certificate-expired第 4.3 节
tlsa-invalid第 4.3 节
dnssec-invalid第 4.3 节
dane-required第 4.3 节
certificate-not-trusted第 4.3 节
sts-policy-invalid第 4.3 节
sts-webpki-invalid第 4.3 节
validation-failure第 4.3 节
sts-policy-fetch-error第 4.3 节

上述条目在第 4.3 节"结果类型"中描述。可以使用"Expert Review（专家评审）"这一 IANA 注册策略向该注册表添加新结果类型。

7. 安全考量

SMTP TLS 报告提供了对支 STARTTLS 的主机之间邮件被误配置或遭到拦截/篡改的可见性。这一报告信道的存在带来了若干安全风险：

最后，由于 TLSRPT 旨在帮助管理员发现针对传输层加密的中间人攻击，包括那些旨在通过降级机会性加密（或在 MTA-STS 的情况下阻止发现新 MTA-STS 策略）来挫败加密连接协商的攻击，我们还必须考虑这样一种风险：一个能够引发此类降级攻击的对手，同样能够阻止对 TLSRPT TXT 记录的发现（从而阻止对成功降级攻击的发现）。因此，建议管理员部署具有较大 TTL 的 TLSRPT TXT 记录（缩小针对该记录 DNS 解析成功施放瞬时攻击的窗口），或者在部署区域上部署 DNSSEC。

8. 隐私考量

MTA 通常被认为是公开可知的；然而，这些 MTA 的内部配置方式及其用户可能并不那么公开。应当指出，向接收站点提供关于 TLS 失败的信息，可能泄露关于发送方配置、甚至关于发送方自身的信息。例如，发送报告可能披露发送方所使用的 TLS 实现，因为无法协商会话可能是两种实现之间已知的兼容性问题。如果用户群体中或某些地区流行某种罕见的 TLS 实现，这可能会间接泄露关于报告方操作系统甚至地区的信息。

9. 参考文献

9.1. 规范性参考文献

9.2. 资料性参考文献

附录 A. 报告策略示例

A.1. 使用 MAILTO 报告

            _smtp._tls.mail.example.com. IN TXT \
                    "v=TLSRPTv1;rua=mailto:reports@example.com"

A.2. 使用 HTTPS 报告

           _smtp._tls.mail.example.com. IN TXT \
                   "v=TLSRPTv1; \
                   rua=https://reporting.example.com/v1/tlsrpt"

附录 B. 示例 JSON 报告

下面是一份来自 Company-X 发往 Company-Y 的示例 JSON 报告，其中 100 次会话尝试连接 Company-Y 的、证书已过期的服务器，200 次会话尝试连接未能成功响应"STARTTLS"命令的 Company-Y 服务器。此外，还有 3 次会话因"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"而失败。

   {
     "organization-name": "Company-X",
     "date-range": {
       "start-datetime": "2016-04-01T00:00:00Z",
       "end-datetime": "2016-04-01T23:59:59Z"
     },
     "contact-info": "sts-reporting@company-x.example",
     "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
     "policies": [{
       "policy": {
         "policy-type": "sts",
         "policy-string": ["version: STSv1","mode: testing",
               "mx: *.mail.company-y.example","max_age: 86400"],
         "policy-domain": "company-y.example",
         "mx-host": "*.mail.company-y.example"
       },
       "summary": {
         "total-successful-session-count": 5326,
         "total-failure-session-count": 303
       },
       "failure-details": [{
         "result-type": "certificate-expired",
         "sending-mta-ip": "2001:db8:abcd:0012::1",
         "receiving-mx-hostname": "mx1.mail.company-y.example",
         "failed-session-count": 100
       }, {
         "result-type": "starttls-not-supported",
         "sending-mta-ip": "2001:db8:abcd:0013::1",
         "receiving-mx-hostname": "mx2.mail.company-y.example",
         "receiving-ip": "203.0.113.56",
         "failed-session-count": 200,
         "additional-information": "https://reports.company-x.example/
           report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
       }, {
         "result-type": "validation-failure",
         "sending-mta-ip": "198.51.100.62",
         "receiving-ip": "203.0.113.58",
         "receiving-mx-hostname": "mx-backup.mail.company-y.example",
         "failed-session-count": 3,
         "failure-reason-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
       }]
     }]
   }

贡献者

Laetitia Baudoin
Google, Inc.
lbaudoin@google.com

作者地址

Daniel Margolis
Google, Inc.
Email: dmargolis@google.com

Alexander Brotman
Comcast, Inc.
Email: alex_brotman@comcast.com

Binu Ramakrishnan
Oath, Inc.
Email: prbinu@yahoo.com

Janet Jones
Microsoft, Inc.
Email: janet.jones@microsoft.com

Mark Risher
Google, Inc.
Email: risher@google.com