我正在开发一个应用程序，该应用程序必须能够发送可能包含敏感信息的电子邮件。我想知道是否有关于企业环境中通常使用哪些 SMTP 服务器的数据（例如，除了 Exchange 之外还有什么？）以及它们是否支持 SSL 连接？
答案1
许多 SMTP 服务器确实支持机会性 TLS，但它并不能真正很好地满足您的需求。
- 通常使用自签名证书，
- 如果你不与没有 TLS 的中继对话，你将遇到许多无法向其投递邮件的域名，并且
- 一旦您将消息发送到第一跳，您就无法控制中继对消息的操作 - 该中继可以转身并将其以纯文本形式发送到其他地方。
相反，您应该寻找端到端加密解决方案，如 PGP 或 S/MIME，或者更用户友好的解决方案，如 HTTPS 门户，他们可以在其中阅读消息（通过纯文本 SMTP 收到消息通知后）。
答案2
是的，大多数现代邮件提交/传输代理（大事记、大事记) 支持通过 SSL/TLS 和 STARTTLS 进行加密连接，包括 Exim、Postfix 和 Sendmail。由于您专注于发送而不是接收，因此设置起来相对容易 - 您不必获取或生成安全证书。但是，不能保证收件人的 MSA 支持加密，您可能会遇到需要在发送服务器上安装的自签名证书。
电子邮件通常不是一个安全的消息传递平台，您最好采用其他解决方案，例如 Shane Madden 建议的解决方案。
答案3
我不反对到目前为止所说的任何内容，但我想补充一些我的看法和数据。SSL/TLS 与所有安全功能一样，旨在防范威胁。它是否是一种良好的保护取决于功能的性质和威胁模型。
如果您的威胁模型包括服务器管理员的攻击，那么网络上的 SSL 数量再多也救不了您；端到端加密是必需的。如果您的威胁模型仅限于随机窥探者，那么未经身份验证的 SSL 会有所帮助；但是如果您的威胁模型包括装备精良的对手的窥探，那么中间人攻击就会成为问题，并且还需要身份验证。
如果没有威胁模型，再多的安全措施也无济于事。 在决定需要什么样的安全保护之前，您需要知道要保护什么，以及要防范谁。
为了提供一些有关加密普遍性的数据，我查看了我的邮件服务器上一个相当有特征的一周。
它在那一周尝试建立 4411 个传出连接。其中 1392 个是与未提供加密的服务器建立的，3019 个是与提供加密的服务器建立的；其中 838 个的证书无法验证（要么是因为它们未签名，要么是因为我不信任签名者；我怀疑绝大多数是前者）。2121 个的证书已记录为已经验证。
因此，根据这种细分，32％的服务器不提供加密，19％的服务器提供加密但具有自签名证书，48％的服务器具有正确签名的证书。
互联网上有关于不同品牌邮件服务器的研究。 这个来自 2012 年 1 月，表明 sendmail 和 Exchange 都变得同样不受欢迎。老实说，我真不知道是该笑还是该哭。
答案4
2014 年 5 月 13 日，Facebook 发布了有关 SMTP STARTTLS 适配的调查结果：
SMTP STARTTLS 部署的当前状态：https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223