M3AAWG：2027 年 SMTP 客户端认证信任缺口——电子邮件需要一种新的行业模型

来源机构：M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group)　|　原文：The 2027 SMTP Client Authentication Trust Gap: Email Needs a New Industry Model　|　原文发布：2026-10-13　|　页面性质：中文翻译与摘录（非原创综述）

概述

由于近期公共 Web PKI（公钥基础设施）策略的变更，客户端证书在公共 TLS（传输层安全）场景中的未来用途已被取消，电子邮件生态系统正面临 SMTP 客户端证书认证方面一个新兴的信任缺口。许多依赖客户端证书的发件方，一旦在 2027 年 3 月 15 日之后尝试获取新签发的证书，就会受到这一变更的影响。

依赖基于证书的 SMTP 客户端认证的组织，应当评估自身的暴露面；与此同时，产业界需要共同协作，在未来的证书续签之前，定义出可互操作、且在运维上可行的替代方案。需要解决的问题包括：社区是否应当创建新的技术标准和 / 或新的 PKI 基础设施，专门用于解决经由 SMTP 发送电子邮件的认证问题。

变更、截止日期与限制

自 2027 年 3 月 15 日起，Chrome 根程序策略（Chrome Root Program Policy）1.8 版 §1.3.2 将要求：纳入 Chrome 根存储（Chrome Root Store）的 PKI 体系下签发的订阅者证书，只能签发仅含 serverAuth（服务器认证）EKU 的证书。自该根程序于 2022 年建立以来，Chrome 一直表示其计划是将体系限制为仅用于 Web；这一变更适用于该根程序根存储下的体系，而非全球所有 PKI 体系。Mozilla、Apple、Microsoft 等其他 TLS 根程序迄今尚未实施此类限制，可作为 Chrome 根程序的替代方案。2027 年 3 月 15 日是一个签发截止日期，此变更不影响该日期之前已签发的证书。

公共 TLS 服务器认证仍然可用。这并非预示所有电子邮件都会失败：SMTP 的 TLS 认证取决于本地策略，且双向 TLS（mTLS）并非普遍部署（参见 RFC 3207）。2027 年 3 月 15 日之后的风险在于，发送方 SMTP 系统所用证书将失去客户端认证（clientAuth）能力。用仅含 serverAuth 的证书替换 clientAuth 证书，可能会破坏强制执行的 clientAuth 要求。

这是根程序层面的要求，而非 CA/Browser Forum（证书颁发机构 / 浏览器论坛）的全面禁令。该论坛的基线要求（Baseline Requirements）覆盖公开信任的 TLS 服务器证书；各个根程序可施加自身的条件。这些变更并不直接规定单个邮件服务器的信任配置。

所有发件方都应检查其 TLS 证书根，判断是否会受 Chrome 根程序变更的影响，并相应调整，或可迁移到 Apple、Microsoft 和 / 或 Mozilla 根存储所含的根。

邮件产业需要解决的关键问题

目前，基于证书的 SMTP 客户端认证尚无达成一致的未来形态。Mozilla、Apple 等其他根程序虽未发布正式声明，但已透露出将自身体系专用于 Web 的类似意向；并且，目前不存在专门面向公共证书的 SMTP、乃至 mTLS（双向 TLS）根程序。当务之急是产业界就替代方案必须是什么达成一致。

邮件社区必须确定以下事项：

• 任何拟议模型如何跨邮箱服务商、邮件安全服务、网关和企业邮件系统协同工作。
• SMTP 发件方身份（SMTP-OUT）的使用——该机制目前规范薄弱，且实际应用中几乎无从体现。
• 如果公开信任的 clientAuth 证书不再可用，SMTP 发件方应如何以密码学方式证明自身身份。
• 接收系统应强制校验何种证书身份、颁发者、证书链与校验要求。
• 是否需要新的标准、证书配置文件或行业指引；尤其是，是否有必要建立面向电子邮件的公共密钥基础设施（PKI）。
• 产业界将如何在不中断合法邮件流转的前提下，测试互操作性与过渡方案。

在这些问题得到解决之前，邮件服务商应当识别自身的 clientAuth 场景，并参与面向未来的协作式互操作性工作。不应假定 SMTP 领域已经存在一个经过验证、可替代 clientAuth EKU 的方案。

行动呼吁：与 M3AAWG 一起弥合缺口

产业界目前还没有答案。电子邮件生态系统需要为 SMTP 客户端认证定义一套持久、可互操作的信任模型。

M3AAWG 成员应加入同行邮件专家参与的 ClientAuth EKU Initiative（客户端认证 EKU 倡议），共同探讨如何平稳完成这一过渡并制定出未来的模型。目标是：在服务商被迫采用碎片化、互不兼容的方案之前，为 SMTP 发件方身份与信任确立一个未来形态。请将你的用例、信任要求与互操作性经验带到这项工作中。这是一个共享的电子邮件生态系统问题，进展取决于服务商共同解决。

常见问题（答案均取自上述人类原文章节）

什么是 SMTP 客户端证书认证（clientAuth），它为何会受影响？

SMTP 客户端认证指发送方邮件系统使用 TLS 客户端证书（含 clientAuth 扩展密钥用途 EKU）向接收方证明自身身份。自 2027 年 3 月 15 日起，Chrome 根程序策略 1.8 版 §1.3.2 要求该根存储下的证书只能签发 serverAuth EKU，不再签发可用于 SMTP 客户端认证的 clientAuth 证书，因此依赖公开信任客户端证书的发件方将受影响。

2027 年 3 月 15 日之后，我的邮件还会正常发送吗？

取决于本地策略与是否强制使用双向 TLS。公共 TLS 服务器认证仍然可用，RFC 3207 指出 SMTP 的 TLS 认证依赖本地策略、mTLS 并非普遍部署；真正的风险是发送方证书失去 clientAuth 能力，强制 clientAuth 的场景可能中断。发件方应检查所用 TLS 证书根，必要时迁移到 Apple、Microsoft 或 Mozilla 根存储所含的根。

这是否意味着所有电子邮件都将失效？

不是。该变更是根程序层面的要求，不是 CA/Browser Forum 的全面禁令，也不直接规定单个邮件服务器的信任配置。SMTP TLS 认证取决于本地策略，风险在于失去 clientAuth 能力，而非电子邮件全面失效。

邮件产业现在需要解决什么？

为 SMTP 客户端认证定义可跨邮箱服务商、邮件安全服务、网关和企业邮件系统互操作的新信任模型；明确当公开信任的 clientAuth 证书不可用时，发件方应如何以密码学方式证明身份，以及是否需要新建面向电子邮件的 PKI、证书配置文件或行业指引。