使用 SSL/TLS 可以使用LOGIN/ PLAIN。

您应该在 SSL 加密连接之上提供 SMTP。虽然您列表中的某些方案（例如DIGEST-MD5）即使在不受信任的通道上也可以保持密码安全，但它们不会保护用户免受中间人攻击者篡改会话的影响。（通常，电子邮件服务器通过直接 TLS 或使用STARTTLS在端口 465/587的连接升级来包装 SMTP 。）

任何 SMTP 身份验证类型，无论您使用PLAIN的是高级方法还是高级方法，都只提供应用程序级别的身份验证。但是您想要的是传输级别的安全性。通过 SMTP 对用户进行身份验证后，将不会有自动加密连接。根据 SMTP 协议，命令和电子邮件以纯文本形式与服务器交换，允许中间人攻击者读取和修改通信并注入新命令。这就是为什么您应该在 SSL 加密之上提供它，就像 HTTPS 在 SSL 之上提供 HTTP 一样。

HTTP 类比：如果您使用 HTTPS 保护您的网站，那么登录表单实际上在 HTTP 请求的 POST 正文中将您的密码作为纯字符串传输并不重要，因为数据传输是 SSL 加密的。启用CRAM-MD5SMTP 类似于在将登录凭据传输到网站之前在 Javascript中实施质询-响应方案。（您偶尔会在不提供 HTTPS 的路由器接口中看到这种技术，但这种技术并不常见。）

至于现实生活中的示例，在建立安全 SSL 连接后，GMail 可以提供LOGIN/身份验证（凭据以计划文本形式发送）：PLAIN

$ openssl s_client -starttls smtp -connect smtp.gmail.com:587 
 ...
250 SMTPUTF8
EHLO 富
250-smtp.gmail.com 为您服务，[127.0.0.1]
250 尺寸 35882577
250-8BITMIME
250-AUTH 登录 PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250 增强状态代码
250-流水线
...

（如您所见，它们还提供了一些您未列出的方法，例如XOAUTH2对于 OAuth2 令牌，如果您进行无密码身份验证，这可能会很有趣。）

我称之为好的身份验证是具有以下属性的身份验证：

• 服务器永远不必知道实际密码，而只保留它的哈希值

  这确保了即使密码数据库遭到破坏，攻击者也只会难以反转哈希，并且用户将有足够的时间来更改他们的密码

• 密码永远不会以明文形式交换

  交换的内容很容易被窥探，通过非加密通道以明文形式传递的密码应被视为已泄露

假设 SMTP 服务器允许 TLS，PLAIN 在以下情况下同时尊重两者：HELO、STARTTLS、LOGIN

除了 SMTP 的最佳建议外，以下是您可用的列表：

• LOGIN, PLAIN：密码以明文形式传输。
• CRAM-MD5：对选择的明文较弱，并且存在密码存储问题。
• DIGEST-MD5：比 CRAM-MD5 更好，因为它对选择的明文攻击更强大，并且允许使用第三方身份验证服务器
• NTLM/SPA/MSN： NTLM 身份验证也容易受到所选明文的攻击。