RFC 7817《邮件协议中更新的 TLS 服务器身份校验规程》中文导读
非官方中文导读声明：本页为 IETF RFC 7817《Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols》 的非官方中文技术导读，按原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc7817.txt。
1. 它替换了什么
在此之前，邮件客户端如何校验 TLS 服务器证书上的名字，散落在多份文档里且各不相同。RFC 7817 统一了这件事：它替换了 RFC 2595 第 2.4 节（服务器身份检查），并更新了 RFC 3207 第 4.1 节（STARTTLS 之后的处理）、RFC 3501 第 11.1 节（IMAP STARTTLS 安全考量）与 RFC 5804 第 2.2.1 节（ManageSieve 服务器身份检查）。
适用对象是邮件客户端——SMTP 提交、IMAP、POP3 与 ManageSieve 客户端，也就是用户代理连接自己邮箱服务器的这一段，而不是 MTA 之间的转发。
2. 校验的总体框架
在 TLS 协商过程中，邮件客户端必须把自己对服务器身份的理解（客户端的参考标识）与服务器证书中呈现的身份做比对，以防中间人攻击。这项检查只在证书按 RFC 5280 第 6 节完成路径验证之后进行；匹配本身遵循 RFC 6125 第 6 节的规则，包括不同标识类型的匹配优先次序、证书固定（pinning）以及匹配失败时的处理流程。
3. 参考标识如何取值
规范给出两条输入规则：
- 对 DNS-ID 与 CN-ID 类型，客户端必须使用以下一项或多项作为参考标识：(a) 用户邮件地址的域名部分；(b) 用于建立连接所使用的主机名（不做 CNAME 规范化）。客户端可以另外使用 (c) 由 (a) 或 (b) 安全派生出的值，例如经 DNSSEC 验证的查询结果。
- 当使用 RFC 6186 定义的邮件服务发现规程时，客户端还必须把用户邮件地址的域名部分作为另一个参考标识，用于与证书中的 SRV-ID 比对。
“不做 CNAME 规范化”这一条尤其重要：如果客户端先把主机名沿 CNAME 展开再拿展开结果去匹配证书，攻击者只要能操纵 DNS 就能把校验引向自己控制的名字。
4. 标识类型的支持要求
| 标识类型 | 要求 | 说明 |
|---|---|---|
| DNS-ID | 客户端实现必须支持 | subjectAltName 中的 dNSName。 |
| SRV-ID | 支持 RFC 6186 的客户端必须支持 | subjectAltName 中的 SRVName；ManageSieve 使用服务名 “sieve”。 |
| URI-ID | 不得用于服务器校验 | 历史上邮件领域并未使用 URI-ID。 |
| CN-ID | 可以使用 | 仅为与已部署软件向后兼容；主体名中的 CN 属性。 |
5. 通配符规则
邮件协议允许证书中的标识使用一定形式的通配符，但边界很严格：* 可以作为 DNS-ID 或 CN-ID 的最左侧名字组件出现。例如 *.example.com 匹配 a.example.com、foo.example.com，但不匹配example.com 本身。通配符不得出现在其他位置，也不得用于 SRV-ID。
这条“不匹配裸域”的规则常被误解，是签发证书时遗漏 SAN 条目、导致客户端校验失败的典型原因。
6. 给 CA 与邮件服务商的检查清单
文档专门用两节给出可直接对照的合规清单。对证书颁发机构：必须支持签发带 DNS-ID 的服务器证书，必须支持签发带 SRV-ID 的证书，并需妥善处理受托管邮件服务（服务商为客户域名提供服务）的签发场景。
对邮件服务商与证书签署者：证书中应当包含客户可能用到的全部名字——既包括用户邮件地址的域名部分，也包括客户端实际连接的主机名；托管多个域名时，需要把这些域名分别列入 SAN，或采用支持 SNI 的独立证书方案。
运维上一个常见的失败模式是：服务商只在证书里放了 mail.provider.example，而用户配置里填的是自己的域名 mail.customer.example——两者不匹配，严格执行本规范的客户端就会拒绝连接。
参考：https://www.rfc-editor.org/rfc/rfc7817.txt