SMTP 身份验证究竟如何工作?

SMTP 身份验证究竟如何工作?

我正在研究 SMTP,希望能够更好地了解它的工作原理,但我不确定我是否了解身份验证的工作原理以及什么控制着谁可以使用电子邮件地址发送消息。

所以基本上这就是我所做的。

我可以通过运行以下命令连接到公司的 smtp 服务器:

telnet smtp.company.com

然后我执行了以下一系列命令向自己发送消息:

EHLO company.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: Test
From: [email protected]
To: [email protected]

The content of the message
.
QUIT

我还可以使用同事的电子邮件地址向自己发送消息,基本上是这样的:

EHLO company.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: Test
From: [email protected]
To: [email protected]

The content of the message
.
QUIT

我可以在不知道或不被要求提供他的密码的情况下做到这一点。

然后,我也尝试发送到我的 Gmail 帐户,但失败并出现错误:

.
421-4.7.0 [MY.LOCAL.IP.ADDRESS      15] Our system has detected that this message is
421-4.7.0 suspicious due to the very low reputation of the sending IP address.
421-4.7.0 To protect our users from spam, mail sent from your IP address has
421-4.7.0 been temporarily rate limited. Please visit
421 4.7.0  https://support.google.com/mail/answer/188131 for more information. 
Connection closed by foreign host.

我的理解是,不允许这样做的唯一原因是我的本地 IP 地址信誉低,而不是因为任何身份验证。

所以我的问题仍然存在...电子邮件/SMTP 的身份验证如何工作?我怎么能使用同事的电子邮件地址发送消息而无需他的授权呢?

答案1

身份验证的全部意义在于根据身份验证结果授权呼叫者。经过身份验证后,服务器知道您是谁,并且可以为您提供其他服务。对于电子邮件,它将把您的邮件转发到外部服务器,即使它不会为未经身份验证的客户端进行转发。请注意,您的前两个示例并非用于转发,因此服务器接受了邮件;这通常是两个服务器之间的对话。

我经常配置服务器,以便它们还会检查经过身份验证的用户是否允许使用此信封发件人(MAIL FROM)地址。因此,即使您经过身份验证,您也无法将信封发件人设置为老板的电子邮件来发送外部邮件。

为 SMTP 定义了三个端口。众所周知的端口 25 最初用于所有中继,后来用于从邮件用户代理 (MUA) 提交;现在建议仅将其用于中继(服务器之间的通信)。它通常在 ISP 级别被禁用,因此用户甚至无法连接到外部端口 25,这有助于防止受感染的计算机发送垃圾邮件。由于此端口上不期望有 MUA,因此通常会禁用该端口上的身份验证。

另一个端口是 587;它被定义为 SMTP 提交,它是 MUA 客户端使用的端口。它以纯文本形式启动,但在命令后可升级为 STARTTLS。这可以实现更广泛的支持和一些自动检测。此端口通常使用身份验证。

第三个端口 465 是 SMTPS,也用于提交,但需要客户端首先初始化 TLS,然后在其中启动 SMTP 会话。它还需要 MUA 进行身份验证。

SMTP 身份验证在RFC 4954,其过程如下:

I. 仅支持 ESMTP,即扩展;原始 SMTP 没有身份验证。要初始化,您必须连接到服务器并发出 ESMTP HELLO:

   EHLO my.host.name

II. 远程服务器将显示扩展答复,其中列出了它支持的扩展在协议的这个阶段。我们现在对 AUTH 和 STARTTLS 扩展感兴趣。AUTH 最初可能不可用(即没有 AUTH 行),但如果有 STARTTLS 支持,您可以发出 STARTTLS 命令并建立 TLS 会话,然后 AUTH 可能会出现。请注意,您将无法在telnet会话中使用 STARTTLS;要测试它在加密隧道内的感觉,只需使用openssl s_client工具。总之,如果 AUTH 在列表中,它将后面跟着一个可用的身份验证方法列表:

250-AUTH DIGEST-MD5 LOGIN CRAM-MD5 NTLM

III. 然后客户端选择身份验证方法并继续:

AUTH LOGIN

对于 LOGIN 方法,服务器需要两行,用户名和密码。它首先询问:

334 VXNlcm5hbWU6

如果你解码这个 base64 字符串,就会发现这是单词“用户名”。你用 base64 编码的用户名回答,它用另一行回答:

334 UGFzc3dvcmQ6

这是 base64 编码的单词“Password”,服务器现在需要您的纯文本密码。同样,此时您使用 base64 编码的密码进行回复。

IV. 服务器会提示认证是否成功:

535 5.7.8 Error: authentication failed: authentication failure
235 2.7.0 Authentication successful

之后您继续 SMTP 会话。

其他身份验证方法使用不同的程序。它们各自都有优点和缺点。LOGIN 和 PLAIN 要求您以明文形式发送密码,这只能通过 STARTTLS 完成,但服务器可以存储加密密码而不存储纯文本。使用 CRAM-MD5 机制,服务器会向您提出挑战,您必须计算出正确的响应来证明您知道密码,而无需通过网络以纯文本(或任何可逆编码)发送密码。它可以防止通过非加密连接窃听,但要求服务器以纯文本形式存储密码。DIGEST-MD5 类似。一般而言,SRP-6 被认为是最安全的基于密码的机制,但它很难实现,并且需要双方进行相当复杂的计算,因此并未得到广泛使用。

这些方法是可插入的。整个过程由 SASL 库处理,该库实现具体过程。在我的示例中,服务器上的 SASL 库要么不支持任何 SRP 变体,要么已在配置中禁用。

答案2

就您而言,似乎根本不需要身份验证。

SMTP 身份验证按照配置的方式工作。从历史上看,电子邮件软件仅对未经身份验证的第三方可以使用的源地址和目标地址进行正式限制。

除了要求一些身份验证类型(显式或隐式)应该在中继(将邮件提交到服务器自身处理范围之外的目的地)之前是必需的,但对于要执行哪些操作并没有太多共识。大多数服务器在接受来自其最终目的地的邮件之前会要求显式登录。大多数服务器会要求信封发件人与每个登录允许的别名列表相匹配。一些服务器会对发件人地址的标题强制执行额外的限制,甚至可能是显示名称。

哪种级别的限制合适取决于你的环境以及您采用哪些其他方法来 a) 打击和 b) 诊断潜在的滥用。

建议:

  1. 定义并检查有权代表您发送并受信任执行限制的系统列表:典型的做法是搜索关键字“防晒指数
  2. 要求所有中继邮件只能在明确身份验证后提交;这意味着停止提供“开放中继

如何最好地做到这一点在很大程度上取决于您使用的软件和邮件用户(可能当前依赖于大多数不受限制的配置),因此超出了我在单个答案中所能表达的范围,但为了让更多的事情更加清楚:

我坚信您所描述的情况:任何人都可以在信封和标题中使用任何源地址- 是鲁莽的并且将会被(并且可能已经被)滥用来欺骗您的公司和其他人。

答案3

邮件服务器通常具有非常灵活的配置可能性。您可以定义一组不需要身份验证的 IP 地址或网络(例如,在 Postfix 中,这通常称为“mynetworks”参数),而对于所有其他 IP 地址,服务器可能需要身份验证。或者可以完全拒绝来自其他地址的连接,而忽略可能的身份验证。

在公司网络中,从公司网络内部连接的客户端无需进行身份验证是一种很常见的配置。这可能是您的情况。

现在,端口 25(您可能在测试中使用过)仅用于传入邮件,即发送邮件到该特定服务器要服务的域。就您而言,公司的 SMTP 服务器要为域提供邮件服务company.com,因此它将接受它而无需任何身份验证,因为任何外部人员都可以发送邮件,[email protected]而 SMTP 服务器在发送邮件时不会相互验证 - 这没有意义。但是,如果您尝试通过端口 25 向任何其他域发送邮件company.com(称为邮件中继),这条消息很可能会被直接拒绝。

对于邮件中继,还有另一个端口 587,并且通常邮件服务器配置为在端口 587 上强制进行身份验证。通常,该端口上的连接 TLS 加密也是强制的。

相关内容