SPF 是一种新兴的反伪造标准，旨在防止蠕虫、病毒和垃圾邮件在 SMTP 中伪造任意电子邮件地址作为信封发件人。SPF 包括两个部分：域名管理员需要在 DNS 中发布 SPF 记录，而电子邮件管理员需要安装启用 SPF 的 MTA 以读取这些记录。SPF 记录指示域发送出站邮件的服务器。来自其他任何地方的邮件都被认为是伪造的。

本文是分为两部分的系列文章的第一篇，解释了 SPF 保护中涉及的概念和权衡，并向 DNS 管理员展示了如何设置 SPF 记录。第二篇文章旨在向电子邮件管理员展示如何在他们的 MTA 中激活 SPF 保护。本文写于 2004 年 1 月初，反映了当时互联网的现状。

今天我收到了来自我自己的垃圾邮件。我是 pobox.com 的创始人，也是一个电子邮件专家。所以我按了 H 查看邮件头，并阅读了 Received 行。正如我所想：就像我收到的大部分垃圾邮件一样，这封邮件来自一台宽带机器。它可能是一台旧的 PIII，运行着未打补丁的 Windows 2000，用于游戏和 MP3，在某人的床脚下安静地嗡嗡作响，上面还搭着脏内衣。也许它位于爱达荷州的马铃薯农场；也许它俯瞰着中央公园。无论怎样，它可能感染了 Sobig 病毒的变种，这是根据垃圾邮件发送者的合同编写的。机器的合法所有者不知道他已感染，不知道他的机器自很久以前某个被遗忘的日子以来，每小时都在发送数百封垃圾邮件和病毒，就因为他点击了那个无法打开的奇怪附件。

垃圾邮件伪装它们的来源。垃圾邮件发送者使用被入侵的机器发送垃圾邮件。他们伪造邮件头。他们伪造 Received 标头以迷惑追踪，编造虚假的主题以欺骗贝叶斯过滤器，并伪造 From 行来冒充 PayPal 或 eBay。

垃圾邮件发送者还会伪造返回路径。当邮件无法投递时，它们会弹回给返回路径中地址的发送者。不是邮件头中的 From: 地址，而是 SMTP 信封的返回路径，即 RFC2821 MAIL FROM。通常，垃圾邮件软件使用旧地址列表，或者他们只是猜测常用用户名或发起字典攻击。结果是大量的错误地址和大量的退回邮件。

垃圾邮件发送者不希望收到这些退回邮件。他们宁愿别人收到它们。因此，他们随机选择一个地址或使用收件人的地址。这就是他们如何让我看起来像收到了来自我自己的垃圾邮件。有时他们会选择一个憎恨的敌人，恶意伪造他的地址，使他被数千封退回邮件淹没。

1997 年，一位垃圾邮件发送者在 joes.com 伪造了一个返回地址，结果 joes.com 被大量退回邮件淹没，宕机了十天——并给世界带来了术语 joe-job。Hotmail 和 AOL 每天都会受到 joe-job 攻击：很多垃圾邮件伪装成来自 AOL，但实际上并非通过他们的服务器发送。在传统的 SMTP 下，AOL 对此无能为力。如果你把 AOL 的标志印在 T 恤上并试图出售，AOL 的律师会立即让你停止销售。但是垃圾邮件发送者每天都在伪造 @aol.com。他们可以逍遥法外，因为他们使用 SMTP。

简单邮件传输协议 (SMTP) 设计于 20 多年前——一个更友善、更温和的时代。整个互联网只有少数几个研究机构。SMTP 从那时起就为我们提供了很好的服务，但它开始显得老旧。

SMTP 是开放和信任的。它的规则相对宽松。你可以声明任何信封发件人，并编造你想要的所有邮件头。不过，你今天可能会争辩说，一个允许 joe-job 发生的协议有点太开放，有点太信任了。这就是发件人身份验证的用武之地。SPF 收紧了规则。

当你向域发送邮件时，你的 MTA 会进行 DNS 查找（MX 查询）以找出将邮件路由到哪个服务器。这样的服务器称为邮件交换器 (MX)。小型域往往只有一个 MX 服务器。大型域往往有更多。发送到域的邮件会发送到其 MX 服务器。

现在来说重点。在 99% 的情况下，当一个域发送邮件时，该邮件都源自于该域控制的相对较小的服务器集。域可以使用 DNS 指定这些服务器，然后声明任何未从这些服务器收到的邮件都可能是伪造的。这被称为指定发件人方案（图 1）。

图 1. 使用 SPF，一个邮件服务器可以检查另一个服务器是否真的与邮件声称来自的地址相关联。

指定发件人方案很有用，因为它们有助于打击伪造，并且易于设置。毕竟，域名所有者已经知道哪些服务器从该域发送邮件。当我说从该域发送邮件时，我的意思是指发起一个 SMTP 事务，其中 MAIL-FROM 信封发件人显示该域。我说的不是 From: 标头。这是一个重要的区别。

来自域的邮件往往来自少数服务器。这对于大型和小型域都是如此。来自 aol.com 的邮件来自 AOL 的服务器。来自我的个人域的邮件来自我的个人服务器。它当然不是来自一台布满脏内衣的机器。

许多 ISP 已经在以一种随意且往往略有缺陷的方式实施这些类型的规则。问题是，一个 ISP 不了解另一个 ISP 的内部情况，并且很容易猜错。也许 aol.com 的邮件服务器也为 aol.net 或反之亦然发送邮件。如果 AOL 自己以一种简单、灵活、可扩展、开放的格式宣布他们的指定服务器，让每个人都可以使用，岂不是更好？

是的，他们做到了。SPF 是一种标准的、灵活的、可扩展的、开放的格式，每个人都可以使用。在撰写本文时，AOL 最近已经开始发布他们的 SPF 记录。

MTA 可以解释该记录，并使用它来判断声称来自 @aol.com 的邮件是否是伪造的。

图 2. SPF 对每条传入消息执行简单的基于 DNS 的查找。

所有这些规则的收紧都是完全自愿的：不发布 SPF 记录的域可以继续像以前一样发送邮件。一些不寻常的域可能不发布 SPF 会更好；这取决于他们。但是大多数域都应该希望使用 SPF。

要发布 SPF，域只需在其区域文件中添加一行。该行是一个 TXT 记录，你可以今天就发布它。让我们看看 TXT 记录是什么样的。

假设 example.com 想要发布 SPF。它期望各地的 MTA 读取其 SPF 记录，并使用它来拒绝伪造尝试。它希望 SPF 减少 joe-job 退回邮件和虚假滥用报告的数量。因此，它在其区域文件中添加了以下行

example.com.  IN TXT  "v=spf1 a mx ptr -all"

v=spf1 版本字符串将此标识为 SPF 记录。-all 表示默认拒绝所有邮件。不发送任何邮件的域，例如 altavista.com，可以简单地使用v=spf1 -all。但是，如果域确实发送邮件，它会声明机制来描述合法邮件应该是什么样子。机制位于中间，在 -all 之前。第一个匹配的机制为 SPF 查询提供结果。-all始终匹配，因此位于末尾。

机制从左到右解释。使用v=spf1 a mx ptr -all首先会检查连接的客户端是否在域的 A 记录中找到，如果找不到，则在 MX 服务器列表中查找。然后 MTA 将检查客户端的主机名是否与域匹配。如果所有机制都不匹配，则将评估 -all，结果将为 fail，并且 MTA 将有理由拒绝该邮件。

A、MX、PTR 和 IP4 对于绝大多数域来说已经足够了。spf.pobox.com/wizard.html 上的设置向导可以帮助你为你的域配置 SPF。但是，如果你的情况很复杂，你可以使用“高级 SPF”侧边栏中描述的机制。

SPF 有许多内置机制。基本机制让你指定从你的域发送邮件的主机。这对于几乎所有域都适用，因为每个域的邮件都只来自一小部分主机。但是，如果来自你的域的邮件以其他方式区分，例如你总是使用 S/MIME 签名，而不是输入a或mx你可以输入smime.

使用指定的发件人机制（A、MX、PTR 和 IP4）是发件人身份验证的一种可能方法。新的发件人身份验证方法正在开发中。不过，SPF 是可扩展的，因此它可以与它们很好地协同工作。理解未来扩展机制的 SPF 插件将能够正确解释它们。不理解这些机制的 SPF 插件将返回 unknown，你的域将被视为根本没有 SPF 记录。

今天，垃圾邮件发送者伪造域名。明天，他们可能会伪造主机名。他们可能会尝试通过编造 username@ibook.example.com 来 joe-job 你的笔记本电脑。保护你的子域也是一个好主意。你应该从你的 MX 服务器开始，然后转向具有 A 记录的其他主机。原因如下。

退回邮件使用 MAIL FROM: <> 发送。空发件人地址确保退回邮件本身不会再次退回并创建循环。当 SPF 看到空发件人地址时，它会回退到 HELO 命令中给出的主机名。当你的 MTA 发送退回邮件时，它会在它发送的 HELO 命令中声明其主机名。如果该主机名列出了 SPF A 机制，则邮件通过。因此，SPF 也防止 HELO 伪造。

SPF 的设计目的是以最低的成本获得最大的收益。它以一种使坏人难以做坏事的方式收紧规则，同时又不打扰做好事的好人。即便如此，一些利用 SMTP 宽松规则的高级用户可能会因 SPF 而感到不便。本节描述了 SPF 给高级用户带来的两个问题，并提供了解决这些问题的方法。

大多数最终用户通过其 ISP 的 SMTP 服务器中继其出站邮件。大多数现代客户端还支持 SASL 身份验证或 POP-before-SMTP，以供需要从 ISP 网络外部拨号回家的用户使用。始终通过其 ISP 的 SMTP 服务器发送邮件的用户自动符合 SPF 标准，无需做任何事情。

但是，一些在笔记本电脑上安装了 MTA 的高级用户习惯于从随机 IP 地址发起邮件，完全绕过其 ISP 的 SMTP 服务器。SPF 适应这些用户：高级机制（参见“高级 SPF”侧边栏）是一种免除某些用户必须使用其 ISP 的 SMTP 服务器的方式。他们可以继续做他们想做的事情。

一些高级用户有十几个或更多地址，他们使用 /etc/aliases 或 .forward 文件中的条目将邮件转发到各处。在经典转发中，信封发件人保持不变，而收件人地址被重写。然而，当邮件到达目的地时，这就成了一个问题——它仍然具有原始发件人地址，并且 SPF 测试失败。

然而，解决方法很简单；你只需要切换到 重发邮件，发件人地址也会随之更改。有很多方法可以实现这一点。阅读 SPF FAQ (spf.pobox.com/faq.html#forwarding) 以选择适合你的方法。大多数最终用户与转发无关；只有高级用户才需要实施此解决方法。如果你通过校友会、虚名域或其他商业转发提供商（例如 pobox.com）获得第三方服务，你应该期望他们为你实施重发邮件。

SPF 的主要目标是阻止伪造。我不希望再收到来自我自己的垃圾邮件，我当然也不希望你收到任何声称来自我的垃圾邮件。蠕虫和病毒也倾向于伪造信封发件人，我们可以使用 SPF 阻止它们。而且，阻止伪造带来一个额外的好处。当垃圾邮件发送者被迫使用他们的真实姓名时，我们可以弄清楚哪些域是合法的，哪些是垃圾邮件发送者。人们已经在这样做了：右手侧阻止列表 (RHSBL) 是 DNS 阻止列表 (DNSBL) 的域名版本。不怕使用自己域名的垃圾邮件发送者很快就会出现在 RHSBL 上，并且可以通过这种方式阻止他们。在 SPF 世界中，RHSBL 将变得更加重要和有效。

包括 ISP、银行和知名品牌在内的大型域关心控制他们的商标。他们有义务保护自己的名称。Altavista.com 发布了 SPF 记录，AOL 和牛津大学也是如此。每天都有更多的域加入进来。较小的域发布 SPF 只是因为他们不想受到 joe-job 攻击。

在接收端，ISP 升级他们的 MTA 并启用 SPF 仅仅是因为这意味着更少的伪造——更少的垃圾邮件、蠕虫和病毒。他们的带宽成本也降低了，因为 SPF 使他们能够在数据传输之前切断垃圾邮件发送者。他们不必执行任何密码学或验证任何签名。SPF 可以省钱。

到本文发布时，SPF 支持应该已捆绑在最新版本的 SpamAssassin、Postfix、Sendmail、Exim 和 qmail 中，或者可以作为可下载的插件使用。商业反垃圾邮件供应商已承诺支持 SPF；Declude JunkMail 就是其中之一，报告称 SPF 正在现场成功阻止垃圾邮件。

如果一切顺利，SPF 标准将在不久的将来作为 RFC 发布。但是数千个域，包括一些非常大的域，已经发布了 SPF 记录。没有理由等待；你应该今天就发布 SPF。