postfix 的 SNI 支持与 gmail 的兼容问题
内容提要
这篇文章讨论了Postfix的SNI支持与Gmail的兼容性问题。作者在修改票务系统时观察到邮件服务器日志中出现了一些奇怪的现象。通过分析日志，作者发现问题出在没有正确告知对方自己尝试连接的SNI名字。解决方法是让Postfix在verify的时候提供一个SNI名字，并重建tls_policy的hash db。这样就能正常发送邮件到Gmail了。作者还提到Gmail在部署新变动时会在TLS握手时送出一个自签名证书，但作者暂时还不理解这么做的好处是什么。
延伸解读
Postfix 默认不发送 SNI 的兼容性考量
Postfix 文档指出，在没有 DANE 的情况下，默认不发送 SNI 名称。这是为了避免与某些服务器不兼容：这些服务器在收到未配置证书链的 SNI 名称时可能中止连接。虽然这提高了与部分服务器的互操作性，但可能导致与依赖 SNI 选择证书的服务器（如 Gmail）的兼容问题。
Gmail 对无 SNI 客户端返回自签名证书
根据日志，Gmail 在 TLS 握手时对未提供 SNI 的客户端返回一个自签名证书，其主题为“No SNI provided; please fix your client.”，CN 为 invalid2.invalid。这导致 Postfix 在 verify 策略下验证失败，邮件投递被拒绝，直到遇到一个提供可验证证书的 MX 才成功。
解决方案：在 tls_policy 中指定 SNI 名称
解决方法是在 tls_policy 中将 verify 替换为 verify servername=hostname，其中 hostname 是 DNS 解析得到的 MX 主机名。这相当于对特定域名启用 smtp_tls_servername，使 Postfix 在验证时发送 SNI 名称。修改后需重建 tls_policy 的 hash db，邮件即可正常发送到 Gmail。
Gmail 新变动的观察与疑问
作者观察到 Gmail 在太平洋时间 06:00 到 09:17 部署了新变动：对无 SNI 的客户端返回自签名证书。作者不理解其好处，并指出有 SNI 时服务器使用 P-256 证书，无 SNI 时使用 2048-bit RSA 自签名证书，而通常认为 P-256 大致相当于 3072-bit RSA。
Q&A
Postfix的SNI支持是什么？
Postfix的SNI支持指的是在TLS连接中，Postfix能够提供一个SNI名称，以便邮件服务器正确选择证书链。
为什么Gmail的TLS连接会出现自签名证书验证失败的问题？
因为在与Gmail的TLS握手时，Postfix未能提供正确的SNI名称，导致Gmail返回自签名证书。
如何解决Postfix与Gmail的兼容性问题？
通过在Postfix的验证过程中提供SNI名称，并重建tls_policy的hash db，可以解决与Gmail的兼容性问题。
Gmail在TLS握手时发送自签名证书的好处是什么？
文章中提到作者暂时不理解Gmail这样做的好处，可能是为了兼容未提供SNI的客户端。
Postfix如何配置强制使用TLS？
Postfix通过设置smtp_tls_cert_file、smtp_tls_key_file和smtp_tls_CAfile等参数来强制使用TLS。
邮件发送失败的主要原因是什么？
邮件发送失败的主要原因是未正确提供SNI名称，导致Gmail返回自签名证书，Postfix拒绝投递邮件。
