RFC 3207 – SMTP STARTTLS 扩展

Proposed Standard Transport Security Obsoletes RFC 2487 Published March 2026

ELI5: 想象你在一个拥挤的房间里聊天。任何人都可以听到。STARTTLS就像在对话中途说"我们进一个私人房间吧"。你先以明文开始SMTP会话，然后双方在交换任何敏感内容之前同意切换到加密通信。之后，没有人能够窃听正在传输的电子邮件。

此 RFC 存在的原因

当 SMTP 在 1982 年设计时，加密不在考虑范围内。消息以明文形式在互联网上传输，任何可以访问网络路径的人都可以读取它们。随着互联网变得更加恶劣，传输中的电子邮件加密变得至关重要。

RFC 3207 定义了 SMTP 的 STARTTLS 扩展，允许将明文 SMTP 连接升级为加密的 TLS 连接。发布于 2002 年，它取代了 RFC 2487，并澄清了安全考虑和服务器行为。

STARTTLS 是在端口 25 上加密服务器到服务器（MTA 到 MTA）电子邮件流量的主要机制。对于客户端到服务器提交，RFC 8314 现在建议在端口 465 上使用隐式 TLS，但端口 587 上的 STARTTLS 仍然广泛使用。

工作原理

STARTTLS 作为 SMTP 扩展工作，在 EHLO 交换期间协商：

客户端以明文形式连接到端口 25（或 587）上的服务器。
客户端发送 EHLO。服务器以其功能响应，如果支持加密，则包括 250-STARTTLS。
客户端发送 STARTTLS。
服务器以 220 Ready to start TLS 响应。
双方执行 TLS 握手，建立加密通道。
客户端通过加密连接发送新的 EHLO。服务器的功能列表可能会更改（例如，AUTH 现在已公布）。
SMTP 会话正常继续，但所有流量现在都已加密。

SMTP 示例

服务器到服务器传输期间的 STARTTLS 协商：

# 在端口 25 上建立的明文连接 S: 220 mx.example.com ESMTP C: EHLO sender.example.net S: 250-mx.example.com S: 250-SIZE 52428800 S: 250-STARTTLS S: 250 ENHANCEDSTATUSCODES # 客户端看到 STARTTLS 可用，请求升级 C: STARTTLS S: 220 2.0.0 Ready to start TLS # --- TLS 握手在此进行 --- # 所有后续流量都已加密 # 客户端必须在 TLS 后重新发出 EHLO C: EHLO sender.example.net S: 250-mx.example.com S: 250-SIZE 52428800 S: 250-AUTH PLAIN LOGIN S: 250 ENHANCEDSTATUSCODES # 注意：STARTTLS 不再公布（已处于活动状态） # 注意：AUTH 现已公布（仅在 TLS 后可用） C: MAIL FROM:<alice@sender.example.net> S: 250 2.1.0 OK C: RCPT TO:<bob@example.com> S: 250 2.1.5 OK C: DATA S: 354 Start mail input C: [message content...] C: . S: 250 2.0.0 OK

关键技术细节

机会性 vs. 强制性 TLS

RFC 3207 中定义的 STARTTLS 的关键限制是默认情况下它是 机会性的：

机会性 TLS： 客户端在服务器公布时尝试 STARTTLS，但如果不可用或 TLS 握手失败，则回退到明文。这是 MTA 到 MTA 连接的默认行为。
强制性 TLS： 客户端拒绝发送消息，除非可以建立 TLS。这可以按域配置或使用 MTA-STS (RFC 8461) 或 DANE (RFC 7672) 强制执行。

机会性 TLS 容易受到 降级攻击：网络攻击者可以从 EHLO 响应中删除 STARTTLS 功能，强制连接保持明文。客户端无法知道服务器是否支持 TLS，因为初始协商以明文方式进行。

证书验证

RFC 3207 不要求对 MTA 到 MTA 连接进行严格的证书验证。实际上，许多服务器使用自签名证书或不匹配 MX 主机名的证书。理由是：机会性加密且不验证仍然好于完全不加密。它保护免受被动监视，即使它无法防止主动中间人攻击。

为获得更强的保证，请使用：

DANE (RFC 7672) — 通过 DNSSEC 保护的 TLSA 记录在 DNS 中发布服务器的 TLS 证书。
MTA-STS (RFC 8461) — 发布要求 TLS 和证书验证的策略，由发送服务器缓存。

STARTTLS 后重新 EHLO

TLS 握手完成后，客户端必须发出新的 EHLO 命令。必须丢弃 STARTTLS 前的服务器功能列表。这很重要，因为：

服务器可能在建立加密后公布不同的功能（例如，AUTH）。
服务器不应再公布 STARTTLS，因为加密已处于活动状态。
攻击者可能已修改了 TLS 前的 EHLO 响应。

不同端口上的 STARTTLS

端口	协议	TLS 行为
25	SMTP 中继	STARTTLS（MTA 到 MTA 的机会性）
587	提交	STARTTLS（实际上强制性 — AUTH 需要它）
465	提交	隐式 TLS（任何 SMTP 命令前的 TLS 握手）

TLS 报告

RFC 8460 定义了 SMTP TLS 报告 (TLSRPT)，允许域所有者接收有关 TLS 连接失败的报告。这是 STARTTLS 的 DMARC 聚合报告等效项 — 它告诉您何时与您的服务器的连接 TLS 协商失败。

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

常见错误

假设 STARTTLS 意味着消息是端到端加密的。 STARTTLS 仅加密两个相邻服务器之间的连接。如果消息通过多个跳跃，每个跳跃独立协商 TLS。消息可能为一个跳跃加密，为下一个跳跃明文。
STARTTLS 后不重新发出 EHLO。 在 TLS 握手后未发送新的 EHLO 是协议违规。您将使用过时的功能数据，可能会错过新可用的功能，如 AUTH。
将 STARTTLS 失败视为永久错误。 如果 STARTTLS 协商失败，连接处于未定义状态。关闭连接并启动新连接。不要尝试在同一连接上继续使用明文。
公布 STARTTLS 但使用过期或配置不当的证书。 虽然许多客户端会继续执行，尽管证书错误，但一些越来越严格的客户端（和 MTA-STS/DANE 策略）会拒绝。保持您的 TLS 证书有效且配置正确。
仅依赖 STARTTLS 的安全。 因为 STARTTLS 是机会性的并易受降级攻击，应该用 MTA-STS 或 DANE 来补充它，以用于加密很关键的域。
在端口 587 上忘记 STARTTLS。 对于提交，客户端应始终在验证前 STARTTLS。以明文发送 AUTH 凭据会将您的 SMTP 密码暴露给任何监控连接的人。

可交付性影响

Google 和主要提供商标记未加密的邮件。 Gmail 为未使用 TLS 加密接收的消息显示红色开锁图标。这向收件人表示消息可能在传输中被拦截，降低信任度。
TLS 采用几乎是通用的。 截至 2025 年，发送到 Gmail 的电子邮件中超过 95% 使用 TLS 加密。不在您的发送基础设施上支持 STARTTLS 使您成为异类，可能会对您的发件人声誉产生负面影响。
MTA-STS 执行正在增长。 主要提供商发布需要 TLS 和证书验证的 MTA-STS 策略。如果您的发送服务器无法成功与有效证书协商 TLS，发送到这些域的邮件将失败。
TLS 报告暴露问题。 如果您发布 TLSRPT 记录并且您的服务器有 TLS 问题，您将收到报告。如果您不发布 TLSRPT，您对连接失败一无所知。
合规性要求。 HIPAA、GDPR、PCI-DSS 和其他法规越来越多地要求电子邮件传输中的加密。STARTTLS 是满足此要求的服务器到服务器电子邮件的基准机制。