SPF 简介摘要: SPF 是发送方策略框架 (Sender Policy Framework) 的缩写,希望能成为一个防伪标准,来防止伪造邮件地址。这篇文章对 SPF 进行了简单介绍,并介绍了它的一些优点和不足。 |
SPF 诞生于2003年,它的缔造者 Meng Weng Wong 结合了反向 MX 域名解析(Reverse MX) 和 DMP (Designated Mailer Protocol) 的优点而付予了 SPF 生命。
SPF 使用电子邮件头部信息中的 return-path (或 MAIL FROM) 字段,因为所有的 MTA 都可以处理包含这些字段的邮件。不过微软也提出了一种叫做 PRA (Purported Responsible Address)的方法。PRA 对应于 MUA (比如 thunderbird) 使用的终端用户的地址。
这样,当我们把 SPF 和 PRA 结合起来的时候,就可以得到所谓的“Sender ID”了。Sender ID 允许电子邮件的接收者通过检查 MAIL FROM 和 PRA 来验证邮件的合法性。有的说法认为,MAIL FROM 检查由 MTA 进行,而 PRA 检查由 MUA 来完成。
事实上,SPF 需要 DNS 以某种特定的方式来工作。也就是必须提供所谓的“反向 MX 解析”记录,这些记录用来解析来自给定域名的邮件对应的发送主机。这和目前使用的 MX 记录不通,后者是用来解析给定域名对应的接收邮件的主机的。
要想用 SPF 来保护你的系统,你必须:
上述第一步要在邮件服务器所属的域名服务器上进行调整,下一节中,我们将讨论这个记录的细节内容。你首先需要确定的一点是你的域名服务器(bind,djbdns)所使用的语法。但别担心,SPF 的官方网站提供了一个很好用的向导来指导你如何添加记录。
SPF 记录包含在一个 TXT 记录之中,格式如下:
v=spf1 [[pre] type [ext] ] ... [mod]
每个参数的含义如下表所示:
参数 | 描述 | ||||||||||||||||||
v=spf1 | SPF 的版本。如果使用 Sender ID 的话,这个字段就应该是 v=spf2 | ||||||||||||||||||
pre | 定义匹配时的返回值。 可能的返回值包括:
|
||||||||||||||||||
type | 定义使用的确认测试的类型。 可能的值包括:
|
||||||||||||||||||
ext | 定义对 type 的可选扩展。如果没有这个字段,那么仅使用单个记录进行问询。 | ||||||||||||||||||
mod | 这是最后的类型指示,作为记录的一个修正值。
|
ISP 实施 SPF 可能对于他们处于漫游状态(roaming)的用户带来一些麻烦,当这些用户习惯使用 POP-before-Relay 这样的方式处理邮件,而不是 SASL SMTP 的时候问题就会出现。
嗯,如果你是一个被垃圾邮件、地址欺骗所困扰的 ISP 的话,你就必须考虑你的邮件策略、开始使用 SPF 了。
这里是你可以考虑的几个步骤。
这样,你就保护了你的服务器、你的客户和整个世界免受垃圾邮件之类的困扰了。
SPF 是一个对于欺骗的完美保护。但它有一个局限:传统的邮件转发方式不再有效了。你不能仅仅从你的 MTA 接受邮件并简单地重新发送它了。你必须重写发送地址。常见的 MTA 的补丁可以在 SPF 的网站找到。换句话说,如果你把 SPF 记录加入到了域名服务器,你就必须更新你的 MTA 来进行发送地址改写,即使你还没有对 SPF 记录进行检查。
你可能觉得 SPF 的实施有点难以理解。不过这确实不算复杂,而且还有一个不错的向导来帮你完成这个转换(参见参考文献)。
如果你被垃圾邮件所困扰的话,SPF 将可以帮助你,保护你的域名免受伪造邮件地址的影响,你所要做的仅仅是在域名服务器上添加一行文本并配置你的电子邮件服务器而已。
SPF 的优点有很多。不过,像我对一些人所说的,这不是一夜之间就可以达到的,SPF 的好处将通过日积月累来表现出来,当其他人都使用它的时候就能明显地看到了。
我也提到了 Sender ID,这和 SPF 有关,但我没有去解释它。可能你已经知道原因了,微软的策略一向如此---软件专利。在参考文献中,你可以看到 openspf.org 对于 Sender ID 的立场声明。
下一篇文章中,我们将讨论 MTA 的设置,我们到时再见。
我仅仅希望给你一个 SPF 的简短说明。如果你对此感兴趣,想要了解更多信息的话,你可以看看参考文献,本文的内容就来自于此。
转:http://www.linuxfocus.org/ChineseGB/December2004/article354.shtml