tl;博士

• 即使启用了 SPF 控件，也很容易欺骗域。

• 解决方案是使用DKIM + DMARC或SPF + DMARC

• 邮件客户端负责告诉你邮件是否通过了 DMARC Display From验证

• 电子邮件协议允许使用 Resent-* 标头和 Sender 标头进行合法欺骗。只要存在此异常，电子邮件客户端 (MUA) 就应显示该异常。

关于SPF有一些误解，即：

1. SPF 不能防止电子邮件欺骗。
2. 仅 SPF 不会影响、影响或控制 RFC 2822 Display From。
3. 默认情况下，SPF 的用处是防止反向散射问题和非常简单的欺骗场景。

微软试图用 SenderID 解决这个问题，（使 SPF 应用于显示发件人地址）但它太复杂了，并没有真正解决整个问题。

一些背景

首先要知道每个 SMTP 消息中有两个“发件人”地址和两个“收件人”地址。一种称为 RFC2821 信封，另一种称为 RFC2822 消息。它们服务于不同的目的

信封：（RFC2821）

• 信封是未出现在 SMTP 标头中的元数据。当邮件转到下一个 MTA 时它会消失。

• 这RCPT From:就是 NDR 的去向。如果邮件来自 Postmaster 或 remailer 服务，这通常是<>或someSystem@place.com。有趣的是，salesforce 使用类似于 constantContact 作为数据库中的键toUserContactID@salesforce.com来查看消息是否被退回。

• 这RCPT TO:是消息实际发送给的人。它用于“to”和“bcc”用户。这通常不会影响邮件客户端中的“地址显示”，但有时 MTA 会显示此字段（如果 RFC2822 标头损坏）。

消息 (RFC2822)

• 消息部分在data发出命令时开始。

• 此信息包括您熟悉的 SMTP 标头、邮件及其附件。想象一下，所有这些数据都从每个 MTA 复制并粘贴到下一个 MTA，直到邮件到达收件箱。

• 每个 MTA 通常会在上述复制和粘贴前加上有关 MTA 的信息（源 IP、目标 IP 等）。它还粘贴 SPF 检查详细信息。

• 这Display From是放置的。这个很重要。欺骗者可以修改它。

• 信封中的Mail From:被丢弃，通常作为return-path:NDR 的地址放在这里

那么我们如何防止人们修改Display From呢？那么 DMARC 重新定义了 SPF 记录的第二个含义。它认识到Envelope From和Display From之间存在差异，并且它们不匹配是有正当理由的。由于 SPF 最初被定义为只关心信封发件人，如果显示发件人不同，DMARC 将需要第二次 DNS 检查以查看是否允许来自该 IP 地址的邮件。

为了允许转发场景，DMARC 还允许 DKIM 对Display From进行加密签名，如果任何未经授权的垃圾邮件发送者或网络钓鱼者尝试使用该身份，加密将失败。

什么是 DKIM？DKIM 是一种轻量级加密技术，可对驻留在消息中的数据进行签名。如果您曾经收到过来自 Gmail、Yahoo 或 AOL 的邮件，那么您的邮件是经过 DKIM 签名的。重点是，除非您查看标题，否则没有人会知道您正在使用 DKIM 加密和签名。它是透明的。

DKIM 通常可以在被转发并转移到不同的 MTA 时存活下来。SPF不能做的事情。电子邮件管理员可以利用这一点来防止欺骗。

问题在于 SPF 仅检查 RFC2821 信封，而不是Display From。由于大多数人关心的是电子邮件中显示的显示来源，而不是返回路径 NDR，因此我们需要一个解决方案来保护和保护这件作品。

这就是 DMARC 的用武之地。DMARC 允许您结合使用修改后的 SPF 检查或 DKIM 来验证Display From。只要 SPF 与Display From不匹配（这种情况经常发生），DKIM 允许您对 RFC2822 Display From 进行加密签名。

你的问题

为什么仍然可以在电子邮件中伪造“发件人：”标题？

一些服务器管理员尚未实施最新技术来防止此类事情的发生。阻碍采用这些技术的主要因素之一是“电子邮件转发服务”，例如邮件列表软件、自动转发器或学校校友转发器 (.forwarder)。即：

2. 未配置 SPF 或 DKIM。

3. 未设置 DMARC 政策。

4. 电子邮件客户端未显示Display From和 Resent-* 或 Sender 字段的验证结果。

是什么阻止了用户简单地丢弃发件人的源域与 SMTP 服务器的域不匹配的电子邮件？

什么不匹配：信封或身体？好吧，根据电子邮件标准，如果通过重新邮寄者，信封不应该匹配。在这种情况下，我们需要 DKIM 签署 Display From 并确保 MUA 验证这一点。

最后，MUA（电子邮件客户端）需要显示发件人是否经过 DMARC 验证，以及是否有人试图用Sender或Resent-From标头覆盖它。

是什么阻止了用户简单地丢弃发件人的源域与 SMTP 服务器的域不匹配的电子邮件？

没有什么。他们被允许，并且许多人使用它来过滤垃圾邮件。

与许多存在安全缺陷的技术一样，电子邮件在设计时并未考虑到安全性和身份验证。“发件人”字段的用途与传统的普通邮件信封大致相同。为了使电子邮件在 21 世纪的需求和滥用情况下可用，我们不得不添加附件。具体来说，SPF解决了您问题的第一部分：

有这么多流行的电子邮件提供商强迫用户使用他们的 SMTP 服务器登录，为什么仍然可以在电子邮件中伪造“发件人：”标头？

解决方案是在接收时验证标头/IP。虽然这在技术上不会阻止实际锻造头部，但它确实使伪造的头部变得不那么有用。

[...] 为什么仍然可以在电子邮件中伪造“发件人：”标题？

SMTP 是在您可以命名 Internet 上的每台机器时设计的协议，并且运行提供邮件的机器是一件相对大的事情，由大型组织和非常敬业的爱好者承担。它没有针对不良行为者的任何内置保护或安全性，并且几乎信任您告诉它的任何内容。

还有很多正当理由，您可能希望您的“发件人：”标头与您的域不同 - 也许您的邮件服务器与许多其他域（例如网络/邮件托管公司）共享，在这种情况下，您的反向 (PTR) 记录和您的正向 (A/MX) 记录必然不同。

但是，鉴于大多数用户在大多数情况下将使用与其邮件域匹配的邮件服务；我们可以围绕SMTP 应用一些逻辑。这导致您的下一个问题：

是什么阻止了用户简单地丢弃发件人的源域与 SMTP 服务器的域不匹配的电子邮件？

这里的答案是没有，人们这样做。

有很多方法可以识别垃圾邮件，例如：

• 正如您所建议的 - 检查发件人域是否与发送域匹配（通过 DNS，或通过连接到发件人并检查）
• 检查“允许”主机的发送域的SPF 记录
• 贝叶斯垃圾邮件过滤/马尔可夫判别
• 黑名单

识别垃圾邮件/非垃圾邮件等分类问题是主要研究领域。不幸的是，这不仅仅是丢弃不是来自您期望的地方的邮件（见证大量垃圾邮件从 gmail 帐户发送到 gmail 帐户）那么简单，并且应用该规则可能会打击巨大障碍的数量（在您的邮件服务器以某种方式共享的情况下）；但是，您可以将其包含在您对消息的分析中并减少对它的信任，一旦您超过了一定程度的确定性，就放弃它。

电子邮件很可能总是存在此类滥用问题，因为它本质上是一个允许人们以尽可能少的摩擦向任何人发送和接收消息的系统。就其本质而言，它允许您不认识的人向您发送您不期望的消息，并且，就像使用常规邮件系统一样，这既是好事也是坏事。

已经有部分保护措施：https : //en.wikipedia.org/wiki/Sender_Policy_Framework

所有流行的电子邮件提供商都使用它。但是他们处理 SPF 失败的方式不同，一些邮件提供商会根据该检查完全丢弃邮件，而一些提供商只会将其放入垃圾邮件文件夹。

任何人都可以创建自己的电子邮件服务器并尝试以任何人的身份发送。

您可以检查您的 gmail 地址（如果有的话）并打开任何电子邮件的标题，您将在顶部看到 SPF 检查的结果：

spf=pass (google.com: domain of *****@*****.com designates 174.**.**.** as permitted sender) smtp.mail=*****@*****.com;