传输TLS和S/MIME解决不同的问题。 TLS保护相邻系统之间的连接。 S/MIME可以对邮件内容进行签名或加密，以便保护随邮件一起传递。这是否是真正的端到端取决于密钥的保存位置以及签名或解密发生的位置，而不仅仅是电子邮件客户端是否显示安全图标。
选择控件之前绘制路径
参考： RFC 3207 §1, RFC 8551 §1.
使用从 Alice 的客户端到她的提交服务的消息，然后是出站网关、收件人的MX服务以及 Bob 的邮箱和客户端。每个网络跃点都可以有自己的TLS连接和策略。成功的域间SMTP TLS连接本身并没有说明提交、内部中继、邮箱访问或存储加密。
在终止TLS每个服务器上，普通消息内容可用于处理，除非单独加密。因此，过滤器、网关和受损端点仍然是机密边界的一部分。 MTA-STS 和SMTP DANE 改进适用路线的运输认证和执行；两者都不会将逐跳TLS转换为消息加密。 RFC 8461第 2 节.
区分签名和加密
参考： RFC 8551 §3.3, RFC 8551 §3.4, RFC 8551 §3.5, RFC 8551 §3.7, RFC 8551 §4.
S/MIME签名内容根据证书信任和验证提供完整性和签名者身份验证证据。单独签名并不能隐藏该消息。 S/MIME封装内容对受保护的材料进行加密，收件人的密钥可以对其进行解密；单独的加密并不等同于经过验证的作者签名。正如RFC 8551 §3.4 所解释的那样，经过身份验证的封装内容还可以提供机密性和数据完整性，而无需证明来源。不要将这种保护与经过验证的作者签名等同起来。工作流程可以结合签名和加密。 RFC 8551第 2 节和第 3 节.
密钥和证书身份需要生命周期管理。确认谁可以访问私钥、收件人如何获取证书、过期或丢失的密钥如何影响对存档邮件的访问以及授权的恢复过程。这些是操作设计问题，而不是广泛分发私钥或假设域身份验证检查取代证书验证的原因。
比较同一邮件的威胁
参考： RFC 8551 §3.1, RFC 8551 §6.
为了被动观察正确加密的SMTP跃点， TLS会保护该跃点上传输的字节。对于在TLS终止后阅读邮件的网关管理员来说，跃点加密不提供内容机密性障碍。如果客户端S/MIME加密不持有解密密钥，则可以保护加密主体免受该网关的攻击。这个词可能很重要，因为某些部署有意在网关处解密。
对于传输后的更改，有效的S/MIME签名可以公开对签名内容的更改；事实上，较早的TLS连接无法成功。对于拥有解密密钥的受损接收方客户端， TLS和S/MIME加密都不会阻止客户端访问明文。对于可见的路由元数据和外部标头，不承诺完全隐藏：覆盖范围取决于消息包装和实现。
私人审查证据包含描述这些边界的明确路径和威胁矩阵。它是一个设计模型，而不是加密互操作性测试。当地的 TLSA 包中其他位置的证书装置不会建立S/MIME签名或解密行为。
一起选择控制和验收证据
参考： RFC 8551 §4, RFC 8551 §6.
指定哪些跃点需要强制TLS 、哪些内容需要签名或加密以及允许解密的位置。在受控环境中测试代表性客户端、附件、转发和存档访问。在声明工作流程在特定路径上保留签名或机密性之前，保留正面验证和负面更改内容的情况。
保持 网络钓鱼 和业务流程声明是分开的。经过身份验证的发件人或签名的消息仍然可能包含错误或欺诈性的付款请求，尤其是在帐户泄露之后。对后续行动的独立验证仍然是必要的。本指南没有对S/MIME消息进行签名、加密、传送或解密；其证据是可检查的控制到威胁矩阵，而客户端互操作性仍然是一项明确待验收的任务。