TLS-RPT、DANE 和 MTA-STS

我们在信任电子邮件方面有两个关键要素。一是关于验证消息内容和发件人，这包括消息加密以及 DMARC（RFC 7489）、DKIM（RFC 6376）、SPF（RFC 7208）和 ARC（RFC 8617）。另一个是关于对邮件服务器本身的信任，这正是本文所讨论的内容。

根据 RFC 3207，公共可访问的电子邮件服务器在不需要 TLS 加密的情况下也必须是可访问的。这使得服务器容易受到降级攻击至明文传输的威胁。此外，实际上证书不需要满足任何有效性要求，因为 RFC 3207 并没有指定任何要求。为了对此进行保护，已经出现了两种技术，并且越来越多的主要电子邮件提供商也在支持它们：DANE 和 MTA-STS。这两种技术都告知电子邮件发件人 TLS 是可用的，并且不应使用明文进行传输。它们也都以自己的方式验证所提供的证书。还有一个名为 TLS-RPT 的附加协议，它允许向电子邮件服务器的管理员报告与 TLS 配置相关的任何问题，从而防止电子邮件无法送达。本文将解释如何部署这三种技术。

请注意，MTA-STS 和 DANE 应尽可能一起部署，而不是只部署其中一个。它们的设计不会相互干扰，并且许多邮件发送者对两者的支持程度不同。正如本文后面讨论的，Postfix 和 Exim 没有内置 MTA-STS 支持。使用其中任何一个的发送者只能与 DANE 一起工作，除非进行额外的配置（见下文）。类似地，DANE 需要 DNSSEC，并非所有邮件提供商都支持此扩展。目前，世界上最大的电子邮件提供商 Google Mail 不使用 DANE 或 DNSSEC，仅依赖 MTA-STS。

使用 MTA-STS 时，TLS 证书需要来自有效的证书颁发机构，并且当前对电子邮件服务器的主机名有效。而 DANE 则依赖于利用 DNSSEC 来提供证书的真实性。但是，DANE 需要发件人使用 DNSSEC 验证 DNS 解析器，并且在入站方向，需要对要注册的域启用 DNSSEC。这可能并非所有 DNS 注册商都支持。在这种情况下，入站方向只能使用 MTA-STS，但仍可以与 TLS-RPT 一起使用。当结合使用这两种技术时（这是推荐的），提供的证书可以由其中任何一种进行验证，因此需要有一个当前的 DANE DNS 记录 *并且* 由受信任的根 CA 签名。

德国国家安全标准 BSI TR-03108 要求同时使用这三种机制，这通常被认为是良好实践。

入站

本节将讨论入站方向，即设置其他邮件服务器向您的服务器发送邮件。

MTA-STS

邮件传输代理严格传输安全（MTA-STS）是一项技术，允许邮件服务器声明其接收传输层安全（TLS）连接的能力。它还规定了一个策略，要求发送 SMTP 服务器在接收服务器不提供受信任的服务器证书时，拒绝投递或不进行投递。

注意 RFC 3207 只说明客户端和服务器在建立 TLS 连接时应确保“达到了可接受程度的身份验证和隐私”。特别是，它没有指定任何类型的验证，例如证书由受信任的 CA 颁发、证书与服务器匹配，或证书通过吊销检查。在使用 MTA-STS 时，RFC 8461，第 4.2 节 要求进行验证，客户端必须确保证书由受信任的根 CA 签名、未过期，并且具有与服务器主机名匹配的主体备用名称（SAN）。吊销检查由客户端自行决定，但允许进行，因此证书需要处于良好状态。

MTA-STS 的工作方式是发布一个 DNS 条目，并在 https://mta-sts.<domain>/.well-known/mta-sts.txt 托管一个策略文件。

DNS 条目是在 _mta-sts.<domain> 发布的一个 TXT 记录。其形式如下：

v=STSv1; id=202408090200Z

v=STSv1 字段是部署的 MTA-STS 的修订版本，目前为 1。id 是一个包含 1-32 个字符的字母数字字段。每次增加它时，MTA-STS 策略就会被认为已更改。最佳实践是创建一个代表当前日期的字符串，并在策略发生任何更改时进行更新。

最后，策略是一个如下的文本文件：

version: STSv1
mode: enforce
max_age: 10368000
mx: mail.example.org
mx: *.example.org

有三种不同的模式：

none

告知发送者没有策略，这有效地禁用了 MTA-STS。

testing

表示策略应被视为非活动状态，但仍应生成 TLS-RPT 报告。此模式仅在配置了 TLS-RPT 时才有意义。

enforce

该模式指示发送者在无法通过 TLS 连接时拒绝与服务器的连接。

max_age 是策略的生命周期（以秒为单位）。这个值应该在几周之间，但小于 31557600（大约一年）。mx 字段只需要列出域的所有 MX 记录。

DANE

警告 DANE 要求该域已注册 DNSSEC。否则无法工作。

DANE 是 DNS-based Authentication of Named Entities（基于 DNS 的命名实体认证）的缩写。它是一种安全协议，使用 DNS 来验证与域名相关的数字证书的真实性。它旨在作为证书颁发机构（如 Let's Encrypt）的替代方案，通过利用 DNSSEC 的完整性来确保证书确实属于某个域名。虽然 DANE 适用于任何证书，但实际上它仅用于电子邮件，即 DANE SMTP。根据设计，私钥和证书可以自生成。虽然使用 CA 提供的证书也很好，但完全没有必要，它们也不会提供任何显著的好处。DANE 的一个关键目标是防止中间人攻击。DNSSEC，或 Domain Name System Security Extensions（域名系统安全扩展），可以保证通过 DNS 公布的公钥的完整性，因此没有 DNSSEC 就无法使用 DANE。

本节重点介绍如何专门将 DANE 与 SMTP 结合使用。如何使用 OpenSSL 创建 DANE TLSA 记录 是关于 DANE 所有内容的更全面的指南。

DANE 的工作方式是通过利用 DNSSEC 以特殊 TLSA 记录的形式在 DNS 中发布证书的哈希值。对于电子邮件，有两个可用的选项：

DANE-TA

发布了签署电子邮件服务器使用的 TLS 证书的证书颁发机构的证书。例如，如果使用了 Let's Encrypt 服务，这将是 Let's Encrypt 的根证书。

DANE-EE

通过发布电子邮件服务器使用的证书的哈希值来工作。

可以发布整个证书，也可以只发布其中嵌入的公钥。后一种选项允许重用证书的密钥对，因此无需更改 DNS 条目。发布整个证书时，每次颁发新证书时都需要更新 TLSA 记录。如果使用 ACME（例如与 Let's Encrypt 一起使用）时，这可能会相当频繁地发生。

警告 重用密钥对被认为比使用更改的密钥对安全性稍低。

TLSA 记录由三个数字字段和证书数据组成。例如，它可能看起来像这样：

_25._tcp.mail.example.org

3 1 1 3a8a378f19eef5c90f783ba44f8d0e8648e883926b16f1dfaf94eef9e1602531

记录名称的格式为 _[port]._[protocol].[service url]。对于 SMTP，这将意味着端口是 25，协议是 TCP。

数字字段如下：

1. 第一个字段是使用的 DANE 类型，称为 *证书使用字段*。值为 2 是 DANE-TA，3 表示 DANE-EE。值为 0 和 1 不适用于电子邮件，并且 不应使用。
2. 第二个字段称为 *选择器字段*，它指示是发布完整的证书 Cert(0) 还是仅发布证书的公钥 SPKI(1)。
3. 第三个字段称为 *匹配类型字段*，它指示数据是如何发布的。值为 1 是 SHA2-256 哈希。其他可能的选项通常被认为不适用于实际目的，因此在此不作讨论。

注意 RFC 7672 建议使用组合“DANE-EE(3) SPKI(1) SHA2-256(1)”，并将“DANE-TA(2) Cert(0) SHA2-256(1)”作为第二选择。

注意 使用完整证书或仅使用公钥对 DANE-EE 记录没有安全影响。选择任何一个都没有特别的优势，除了 SPKI(1) 允许在重新颁发证书时重用密钥对。使用 SPKI(1) 时，在证书重新颁发时，DNS 记录无需进行任何更改。对于 DANE-TA，在 RFC 6698，附录 A.1.2.2 和 RFC 7672，第 3.1.2 节 中讨论了选择。建议将匹配类型 Cert(0) 与 DANE-TA 一起使用。否则，中间 CA 可能会用不同的证书内容和相同的密钥对重新颁发其证书。在这种情况下，证书限制可能会被违反。

最后，数据字段将分别是证书或公钥的 SHA2-256 哈希值。为了计算这个值，可以使用 openssl。

Hashing the full certificate (option 0)

openssl x509 -in certificate.pem -outform DER | sha256sum

Hashing the public key only (option 1)

openssl x509 -in certificate.pem -pubkey -noout | openssl ec -pubin -outform der | sha256sum

对于 DANE-EE，certificate.pem 将是电子邮件服务器使用的实际 TLS 证书。另一方面，对于 DANE-TA，这将是任何颁发 CA 的证书。

注意 可以使用匹配类型 2 来使用 SHA2-512 而不是 SHA2-256。不推荐这样做，因为 RFC 6698 使实现 SHA2-512 支持成为可选的，并非所有解析器都支持它。RFC 7672 也不鼓励这样做，并建议使用 SHA2-256 TLSA 记录。

警告 DANE-EE 本身可以与自签名或不受信任的（非 CA）证书，甚至过期证书一起部署。同样，DANE-TA 也可以与任何 CA 一起使用。

然而，一些大型电子邮件公司即使在 DANE 可用的情况下也强制执行 MTA-STS（尽管 RFC 8461），因此如果您没有 CA 证书，它们将丢弃与您的邮件服务器的连接。

实际上，当部署 DANE 和 MTA-STS 时，有必要提供一个符合上述要求的 CA 证书。

根据 DNS 提供商的不同，可能可以自动化此记录的发布。gotlsaflare^AUR 例如允许将记录发布到 Cloudflare DNS 服务。鉴于存在众多提供商，无法为这一步提供任何具体说明。

还有 dns_tools^AUR 包用于管理使用 DNSSEC 的 DNS 服务器，以及 ssl-mgr^AUR 用于创建和续订 Let's Encrypt 证书、创建和更新 DANE TLSA 记录以及在证书续订时滚动密钥。有关这些内容的更多信息，请参阅 dns_tools 文档 和 ssl-mgr 文档。

警告 由于 DNS 记录会根据 TTL 的时间被缓存，因此更新 TLSA 记录必须分步进行，首先添加新记录，等待 TTL 过期，然后删除旧记录并将邮件服务器切换到新证书。此过程称为执行密钥滚动。

TLS-RPT

SMTP TLS 报告（TLS-RPT），在 RFC 8460 中定义，是一种用于报告与 TLS 加密失败和成功连接相关的邮件投递问题的标准。

TLS-RPT 的工作方式是发布一个 DNS 记录，告知发送者将 TLS 功能的报告发送到何处。只有一种类型的报告，即聚合报告，它总结了特定结果（无论是错误还是成功）发生的频率。它被格式化为 XML 文件以供进一步处理。

TLS-RPT 记录是在 _smtp._tls.[domain] 发布的一个 TXT 记录。内容必须以版本指示符 v=TLSRPTv1; 开头，后跟有关报告发送地址的信息。这可以是邮件地址或接受 POST 请求的 HTTPS 服务。完整的记录看起来像这样：

_smtp._tls.example.org

v=TLSRPTv1; rua=mailto:tlsrpt@example.org

rua 表示聚合报告应发送到此地址，mailto: 指定应通过邮件进行。https: 将是 HTTPS POST 解决方案的前缀。

警告 强烈建议不要使用 HTTPS POST 端点进行报告。BSI TR-03108 实际上禁止这样做。虽然电子邮件可以通过 DMARC 进行身份验证，但 HTTPS POST 机制不能。攻击者可以发送欺诈性报告以试图掩盖干扰。

由于报告是 XML 格式的，因此建议对其进行处理以提取信息。还有许多云服务提供商可以接收和处理这些报告。在 dmarc_report^AUR 包中也有 *tls-rpt*，它可以从 XML 文件生成可读的 DMARC 和 TLS-RPT 报告。有关更多信息，请参阅 dmarc_report 的 Readme。

出站

接下来讨论出站方向（即发送电子邮件时）。与入站方向不同，其中所有三种技术大多与所使用的邮件传输代理无关，该方向的步骤取决于使用的邮件服务器。

所有 MTA 的一个共同点是，为了发送 TLS-RPT 报告，所有处理出站邮件的邮件服务器都需要支持 RFC 8689 扩展，因为 TLS-RPT 报告必须以 Require-TLS: no 标头发送。

此外，需要一个 DNSSEC 功能的 DNS 解析器来解析 DANE，并强烈建议用于 MTA-STS，因为否则 可能导致连接降级。以下部分假定 DNS 使用 DNSSEC，并且不会重复说明。

Postfix

Postfix 自很久以来就支持 DANE（从 Postfix 2.11 开始），但 MTA-STS 和 TLS-RPT 依赖插件。

注意 TLS-RPT 和 RFC 8689 仅与 Postfix 3.10 及更高版本支持。为了发送报告，Postfix 设置中的所有出站邮件服务器都必须至少是该版本。

DANE

DANE 已内置到 Postfix 中，只需在 /etc/postfix/main.cf 中添加以下行：

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

MTA-STS

为了支持 MTA-STS，需要一个插件通过 smtp_tls_policy_maps 向 Postfix 提供有关 TLS 策略的信息。为此有两种可用选项：postfix-tlspol 和 postfix-mta-sts-resolver^AUR。

注意 postfix-mta-sts-resolver^AUR 存在一个问题，即它无法解析 DANE，因此如果服务器上同时部署了 MTA-STS 和 DANE，它将覆盖 DANE。这个问题在项目的 此处 有讨论。postfix-tlspol 没有此限制，并且优化效果更好。

安装 postfix-tlspol，并 启动 或 启用 postfix-tlspol.service。然后，编辑 Postfix 的 /etc/postfix/main.cf 以添加以下行：

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8642:QUERYwithTLSRPT

注意 postfix-tlspol 同时解析 MTA-STS 和 DANE，因此也需要启用 DANE 和 DNSSEC。

TLS-RPT

注意 为了使 TLS-RPT 有用，至少需要配置 DANE 或 MTA-STS（最好是两者都配置）。

安装 tlsrpt-reporter。至少调整 /etc/tlsrpt/reportd.cfg 中的以下行以适应您的域名和组织：

organization_name = EXAMPLE.COM
contact_info = tlsrpt@EXAMPLE.COM
sender_address = noreply@EXAMPLE.COM

之后，启动或启用 tlsrpt-collectd.service 和 tlsrpt-reportd.service。然后，将以下行添加到您的 Postfix /etc/postfix/main.cf：

smtp_tlsrpt_enable = yes
smtp_tlsrpt_socket_name = /run/tlsrpt/tlsrpt-collectd.socket

注意 tlsrpt-collectd.service 和 tlsrpt-reportd.service 可以在不同的系统上运行。请考虑 tlsrpt-reportd(1) 中的 fetcher 选项。

警告 目前存在 一个问题，导致如果 tlsrpt-collectd.service 未运行至少一天，tlsrpt-reportd.service 会输出重复的错误。这不会影响功能，并且已在 上游修复，因此应在下一个版本中得到解决。

Exim

Exim 只支持 DANE，不支持 MTA-STS 或 TLS-RPT。要激活 DANE，请编辑 /etc/exim/exim.conf 并添加：

dns_dnssec_ok = 1

此外，编辑 remote_smtp 传输并向其中添加以下行：

hosts_try_dane = *

有关此主题的进一步信息，请参阅 Exim 文档。

Stalwart

Stalwart 已内置 DANE、MTA-STS 和 TLS-RPT。请参阅其文档 以获取有关如何启用和配置它们的说明。