在我的客户端邮件应用程序（ThunderBird）中，我选择（并且我的邮件服务器接受）带有 STARTTLS 的 SMTP，带有 SSL/TLS 的 POP（或 POP3）。我了解这仅适用于从我的客户端应用程序到我的 ISP 邮件服务器的邮件内容。
我的问题是专门针对与邮件服务器的连接的安全性——即 ThunderBird 的连接安全下拉选项是，无身份验证、普通密码、加密密码、Kerberos / GSSAPI、NTLM 和 OAuth2。ThunderBird 还可以探测我的电子邮件服务器，以了解它最终能够遵守或实施的内容。我为我的服务器找到的只是“普通密码”。
所以显然我的电子邮件服务器不提供加密连接，我推测我的密码可以被有足够技能的人看到。此外，我很好奇是否有任何电子邮件服务器（ISP 提供或其他）提供密码加密。
这里的配置有两个不同的方面 - 连接级安全性和身份验证级安全性。在实践中，由于连接级别 (TLS) 保护两者，身份验证级别的安全性通常较低（“普通密码”）。 只要您使用 TLS（通过 SSL/TLS 或 STARTTLS 的 SMTP/POP/IMAP），就可以了。
回到过去，在 SSL/TLS/STARTTLS 变得普遍之前，凭据是人们关心保护的唯一连接部分。正如您所说，电子邮件一离开您的服务器就可能在未加密的情况下传输 - 所以人们并不十分担心被阅读的可能性。但是，他们担心自己的凭据。那些用于通过未加密的 SMTP/POP/IMAP 链接传递的凭据。
出于这个原因，设计了许多专门用于加密凭证的协议。Digest-MD5、GSSAPI 和 OAUTH 都是更安全的SMTP AUTH方法，可以在未加密的连接上使用。更常见的 PLAIN 和 LOGIN 类型不加密凭据，如果没有连接级加密，则会使密码易受攻击。
但随后世界开始加密连接。SMTP、POP 和 IMAP 客户端和服务器增加了对 SSL/TLS 或 STARTTLS 的支持，以保护整个连接。一旦它们变得普遍，就没有动力使用更复杂的受保护的 SMTP AUTH 方法，因为 TLS 将提供所有必要的保护。这就是为什么您的 ISP 只提供“普通密码”（即 PLAIN 和/或 LOGIN）很舒服的原因——他们知道 TLS 层可以保护您。
（事实上，一些更强的方法削弱了安全性，要求服务器存储每个用户密码的明文或可逆加密副本，而不是它的单向哈希。引用Wikipedia on Digest Authentication），“有些服务器需要密码使用可逆加密进行存储。但是，可以存储用户名、领域和密码的摘要值。 “后一语句的脚注链接转到RFC 2617，其中详细介绍了安全权衡Digest Authentication... 这些年来，我一直在考虑使用 Postfix、Dovecot、Courier 和 Cyrus 实现 Digest Authentication；每次我决定我不喜欢这种权衡。）