自从 RFC2487 中定义了 SMTP+STARTTLS（显式 SSL）以来，SMTPS（隐式 SSL）已被弃用/过时。我并不完全清楚这背后的原因，但当时它显然被认为是一个好主意。
可以看到 IMAP 和 POP3 的并行，IMAP+STARTSSL 使用端口 143，IMAPS 使用端口 993，POP3+STARTTLS 使用端口 110，POP3S 使用端口 995。
由于这些协议与 SMTP 加密选项的不同之处在于，为什么这些隐式 SSL 选项没有以相同的方式被弃用？
也就是说，我不明白为什么应该将显式 STARTTLS 视为更好的选择——当然最好尽快开始加密，而 STARTTLS 不会这样做，所以隐式加密服务肯定更可取吗？似乎我并不是唯一一个有这种想法的人，因为有一份互联网草案正好表明了这一点。
我可以看到显式加密的唯一好处是您可以在同一个端口上运行明文服务——但这似乎不是我们应该鼓励或继续支持的事情，如果可以避免的话。
这一切背后的理由是什么？
tl;博士：
这本质上不是一个，而是两个不同的问题，我将分别解决它们。
您可能已经注意到，近年来，谷歌或 Facebook 等大公司在保护 HTTP 通信方面付出了很多努力，并在很大程度上取得了成功。但造成这种情况的主要驱动力之一似乎是 ISP用自己的 .
顺便说一句，这隐含的后果是巨大的，互联网的结构将因此发生很大变化。来自 APNIC 的 Geoff Huston 在他出色的博客文章和相关演示文稿（幻灯片、视频）中对此进行了总结，所以我最好只是参考一下，而不在这里进一步解释。
当然，还有其他驱动因素，但其中很多仍然与保护某人的商业模式（例如PCI SSC 活动等）密切相关。
这里最重要的是，虽然 HTTP 领域的那些成就提高了一个相当高的门槛，但许多其他的通信方式，包括电子邮件，似乎都缺乏HTTP 所幸拥有的那种商业驱动，这可能是他们取得成功的主要原因之一。与我们目前在 HTTP 中的安全性相比，安全性仍然相当过时。因此，在 2018 年，仍然需要支持大量只能以明文进行通信的过时的邮件访问服务器、用户和传输代理。
希望这会改变，但我个人目前无法对此提供明确的估计。
隐式和显式 TLS 方法都比明文更好，因为无论哪种方式保护通信都比完全不保护通信要好。一些 MUA 和 MTA 部署仅支持隐式或显式 TLS，并且弃用任何概念会使这些部署没有任何针对中间人攻击的对策。弃用在 Internet 上积极使用的协议和方法——本质上总比没有好——而赞成什么都不支持是一种不好的做法。
如您所见，仅弃用 SMTPS 并没有给我们带来任何好处：它仍然存在。这是一个广泛使用的互联网协议不能随意关闭的例子。是的，听起来很有趣，但在大约 1998 年发生的时候，它可能还没有今天那么清楚。
此外，宣布其中一个概念已过时而支持另一个概念必须得到互联网社区的支持，尽管大多数人都同意在一天结束时应该只剩下两个选项中的一个作为首选，但这并不是那么容易实现关于显式 TLS 是否更好的共识（更多内容见下文）。您所指的互联网草案是一项基本举措，旨在在所有这些混乱中带来一点理智，而不会带来共同的标准困境：
一旦最终确定，明确的 TLS 弃用过程将在未来的某个时候开始，但这需要时间。
免责声明：这只是对当前 Internet 协议设计方法的概述。我在这里不偏袒任何一方，反对这些方法的正确位置是 IETF工作组邮件列表和会议。
隐式 TLS 非常适合从头设计的协议，考虑到当代威胁模型，并且不需要支持明文通信。然而，隐式 TLS 在保护旧的明文协议方面有些争议。它似乎对 HTTPS 运行良好，但需要付出一些努力，包括为安全 HTTP 通信分配不同的端口 (443)。
这种方法的缺点是，对于每个剩余的明文协议，您需要分配另一个 TCP/UDP 端口，而全局 TCP 端口空间受到严重限制。在某些时候，IETF 工作组普遍认为以这种方式浪费端口是一种不好的做法，甚至端口 465（最初是 SMTPS）后来也被重新分配用于不同的目的（这实际上发生在大约 20 年前，这也揭示了速度有多慢互联网采用变化）。
同样，正如您在draft-ietf-uta-email-deep中看到的那样，这种考虑可能会在不久的将来撤回。另请注意，该草案最初可以追溯到 2013 年，现在才接近最终状态，这让您了解这个选择的整体难度。
机会性（或显式）TLS的一般思想是以某种方式提前通知客户端（使用不同的通信通道，之前已经验证并因此受信任）特定远程服务器支持 STARTTLS，因此客户端必须仅使用 STARTTLS 进行数据传输向该服务器，从而防止STRIPTLS攻击。最初 DNSSEC应该提供这个单独的通道，但是，它的全球部署不知何故停滞不前，因此，工作组正在考虑其他方式（例如TOFU）来做到这一点。
请注意，隐式方法本身也不是抗降级的，因为中间的人能够剥离隐式 TLS。像HSTS这样的方法依赖于 TOFU 本身。一个常见的论点是，用户可以通过在客户端首选项中明确指定端口号来强制其软件客户端进行安全通信，但软件客户端也可以为用户提供在旧端口上明确强制执行 STARTTLS 的能力，因此从用户的角度来看两种方法之间的区别是微妙的。