等保 2.0 的通信传输要求是不是等于邮件必须加密？只开 STARTTLS 够不够？

GB/T 22239-2019 在安全通信网络层面设有通信传输控制点。它把「完整性」与「保密性」拆成两项独立要求：一项要求采用校验技术或密码技术保证通信过程中数据的完整性，另一项要求采用密码技术保证通信过程中数据的保密性。随着保护级别提高，要求逐步收紧。

这个拆分很重要，因为它对应两种不同的失败：

• 完整性失败是「内容在途中被改了而收方不知道」——中间人插入链接、替换附件、篡改收款账号。
• 保密性失败是「内容在途中被看到了」——链路监听、镜像流量、中继侧留存。

与之配套，GB/T 25070-2019 从安全设计的角度给出技术要求，GB/T 39786-2021 则专门规定了信息系统密码应用的基本要求，其技术部分覆盖物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全四个层面。邮件的传输加密同时落在「网络和通信安全」与「应用和数据安全」两个层面上，因为邮件既是网络传输，其报文本身又是应用数据。

RFC 3207 定义的 STARTTLS 是 SMTP 上最普遍的加密手段，但它有一个必须被正确理解的性质：它默认是机会性的。客户端在 EHLO 响应中看到服务端通告 STARTTLS 就升级，看不到就以明文继续。

由此产生两个具体风险：

1. 降级剥离。处于路径上的中间人可以从 EHLO 响应中删掉 STARTTLS 通告，客户端「看不到」就会退回明文，而两端均无异常感知。这种攻击不留任何错误日志，投递照常成功。
2. 证书不校验。大量 MTA 之间的 TLS 握手并不校验对端证书。连接是加密的，但你不知道加密给了谁。这满足不了完整性要求中「防止被篡改」的实质，因为中间人可以用自己的证书完成一次完整的解密再加密。

RFC 3207 本身还规定了一条容易被忽视的安全要求：TLS 握手完成后，SMTP 协议状态必须复位到初始状态，握手前从对端获得的信息必须被丢弃。不遵守这一条的实现，会把明文阶段被篡改的信息带进加密会话。

结论是明确的：「开了 STARTTLS」不等于「满足了保密性与完整性要求」。测评时若只能出示「服务端支持 STARTTLS」的截图，而拿不出「实际投递中加密比例、证书校验策略、降级发生时的处置」的证据，这一项的论证是不完整的。

要让加密从「碰运气」变成「可保证」，需要额外的机制：

1. MTA-STS（RFC 8461）。域名通过 HTTPS 发布策略文件，声明本域的 MX 必须以 TLS 接收且证书须通过校验。发送方遵循该策略后，降级剥离攻击会导致投递失败而非静默退回明文——失败是可见的，静默降级是不可见的，这是本质区别。策略有 testing 与 enforce 两种模式，应当先以 testing 模式观察一段时间再切换。
2. DANE。基于 DNSSEC 在 DNS 中发布 TLSA 记录来约束对端证书。它与 MTA-STS 解决同一问题但信任根不同，前提是 DNSSEC 已经部署到位。
3. TLS-RPT（RFC 8460）。让发送方把 TLS 协商的成功与失败情况汇总报告给收方域。没有这一步，你无法知道有多少投递实际发生了降级——而「无法度量」在测评中就是「无法举证」。
4. REQUIRETLS（RFC 8689）。由发送方对特定报文声明「必须加密投递，否则宁可不投」。它把决策粒度细化到单封邮件，适合少量高敏感邮件，代价是链路上各跳都需要支持。

此外，用户侧的接入必须单独处理。RFC 8314 给出的方向很清晰：邮件提交与访问应当使用 TLS，明文方式应被视为过时。落地上意味着提交、IMAP、POP3 的明文端口应当关闭或强制升级，Webmail 强制 HTTPS，并对老旧客户端的兼容例外设定期限与清单。

密码法把密码分为核心密码、普通密码和商用密码，其中核心密码、普通密码用于保护国家秘密信息，商用密码用于保护不属于国家秘密的信息。企业邮件系统的加密属于商用密码范畴。

GB/T 39786-2021 对信息系统的密码应用提出基本要求，其核心逻辑是「合规性、正确性、有效性」三层递进：算法与产品要合规，实现与配置要正确，实际运行中要真正起作用。据此，邮件系统需要能回答的问题包括：

• 用了哪些算法？对称、非对称、杂凑各自是什么，是否在允许使用的范围内。
• 密钥从哪来、存在哪、怎么轮换、怎么销毁？密钥管理是密码合规中失分最多的部分——算法选对了，但私钥明文躺在配置文件里、多年未轮换、离职人员仍有访问权限，这些都会直接否定前面的工作。
• 弱套件是否已禁用？SSL 早期版本、TLS 早期版本、无前向保密的套件、导出级套件、以及已被证明不安全的杂凑算法。兼容性理由不能无限期成立，应设定明确的下线时间表。
• 能不能证明它在跑？需要能从日志中统计出实际使用的协议版本与套件分布，而不是只看配置文件里写了什么。

最后需要厘清三个经常被混为一谈的概念，它们保护的是完全不同的区间：

1. 传输加密（TLS）：保护报文在两个节点之间的这一段链路。报文到达每一跳后都是明文，中继方能看到全部内容。它防的是链路监听，不防中继方。
2. 存储加密：保护落盘后的数据。它防的是介质失窃与越权读取存储，不防已经取得应用层权限的攻击者——因为应用需要能解密才能工作。
3. 端到端加密（如 S/MIME 报文加密，见 RFC 8551）：由发送人加密、只有收件人能解密，中间任何一跳都看不到明文。它是唯一能防住中继方的方案，代价是密钥分发与管理的复杂度，且加密后的报文无法在网关侧做内容检测。

这个代价必须被显式决策：一旦启用端到端加密，反病毒扫描、数据防泄漏、合规归档的可读性都会同时失效。常见的折中是按数据分级选择——普通业务邮件依赖强制传输加密加存储加密，少量高敏感邮件使用端到端加密并配套单独的归档与审计安排。

NIST SP 800-177 Rev. 1 从工程角度给出了可信邮件的整体建议，可作为交叉参照，但落地时仍应以国内标准与法律要求为准绳，两者在技术方向上并不冲突。