SPF，Sender Policy Framework发信者策略架构，
主要目的是防止假冒域名来发邮件，阻止垃圾邮件
spf提出一种DNS记录类型，它是一种TXT类型的记录，它用于登记某个域名拥有的用来外发邮件的所有IP地址
SMTP通讯过程中， MAIL FROM address 命令或 HELO domain 产生的这个发件人地址，一般标识为"Return-Path"
例下面的DNS字段
example.net. TXT "v=spf1 mx a:pluto.example.net include:aspmx.googlemail.com -all"
v=spf1 SPF version 1 //版本1
mx the incoming mail servers (MXes) of the domain are authorized to also send mail for example.net //所有的MX记录IP都通过
a:pluto.example.net the machine pluto.example.net is authorized, too // pluto.example.net主机也通过
include:aspmx.googlemail.com everything considered legitimate by gmail.com is legitimate for example.net, too //所有已经被aspmx.googlemail.com验证过的都通过
-all all other machines are not authorized //其他的都不通过
再比如下面的，所有本域名下面的A记录主机，MX记录主机都通过，所有google.com通过的都通过 ， 其他的都软失败
v=spf1 a mx include:_spf.google.com ~all
软失败就是说这个IP不被允许通过，但是还是进行投递并标记
"v=spf1 +all" //表示所有的都通过，基本就等于是没用SPF
"v=spf1 ip4:192.168.0.1/16 -all" //允许来自192.168.0.1到192.168.255.255.
"v=spf1 a/24 a:offsite.example.com/24 -all" //如果offsite.example.com 解析IP为192.0.2.1 那么192.0.2这个C段的IP都通过， 如果offsite.example.com返回多个A地址 ，那么每个C段都通过
"v=spf1 exists:example.com -all"
//这个表示如果example.com能被解析就通过，而不去管example.com被解析的结果是什么
宏：
-exists:%{ir}.sbl.spamhaus.example.org
比如客户端IP是192.0.2.1 ，%{i} 就是解释为192.0.2.1" ，
r表示反向，%{ir} would expand to "1.2.0.192".
那么这句解释就是判断只要存在 1.2.0.192.sbl.spamhaus.example.org 就不通过
转发问题
比如你的域名是a1.com 已经使用的SPF，你的邮件地址为 ，
你在client.a1.com机器上收到一封来自 的邮件，想把这封邮件转发到
直接使用转发的话，这时的信头的mail from却是a2.com， 于是你的a1.com的SPF就会拿你的client.a1.com这个源IP去和a2.com的DNS记录进行验证
于是验证就失败了
所以如果你的域名使用的邮件服务器已经支持了SPF，就不能原封不动直接转发
而需要重写信头，重新写mail from，
==========================================================
Sender ID 或者叫 SIDF（Sender ID Framework）
这个是微软提出的，只是一个名字而已，实际上还是使用SPF类似，使用DNS记录（SPF txt字段）来对发件人的域名进行验证
上面说的SPF验证的是MAIL FROM这个地址， Sender ID（或叫SIDF）要验证的是PRA ，那什么是PRA？
PRA , Purported Responsible Address ,声称的邮件地址。
前面说的SPF中，SPF框架都是spf1, 验证的元素是“MAIL FROM” 命令 or EHLO 命令，声称发件人的邮件地址也就是return-path
PRA是微软提出的在Sender ID这个框架里可以验证的除了spf1里面的元素外， 还有from字段
使用Sender ID 验证的话，理论上应该在DNS中使用的txt字段标明v=spf2.0/pra
使用SPF 验证的话DNS中使用的字段是 v=spf1 ，而spf2.0/mfrom可以理解为等同于spf1
spf1 只检查MAIL FROM和HELO ，也就是return-path
比如的邮件的from地址是 需要回复到这个from地址
我的实际的域名是a.com,实际的邮件地址是，或者说是要通过来发送
现在从client.a.com机器用账户来连mail.a.com发邮件出去
于是信头里就是：
from:x@b.com // 因为需要回复地址是
return-path: // 从这个邮件账户发送
这个是由MUA产生的信头, SPF 因为只判断return-path，而且源地址是client.a.com 这个是不会有问题的（源地址client.a.com , return-path:x@a.com ）
但是如果是sender id验证的话，就需要验证from字段 ，但是源地址是client.a.com, 于是SIDF就会去检查b.com的SPF字段，源地址就不能通过sender id的验证了
虽然80%的情况下from和return-path是一样的
在这种20%的情况下，Sender ID验证框架就会认为这样的是不合法的（大部分垃圾邮件就是不一致，不合法也的确有道理），
但是有的时候确实是会有这样的使用情况，解决办法是让MUA 添加一个sender字段
于是信头就是：
from:x@b.com
return-path:
sender:x@a.com
这样sender字段就override覆盖了from字段 也就通过验证了， 当然要MUA支持这个功能了
SIDF验证后并打分（Reputation data）然后这个打分会和其他的数据一起(比如用户的反馈投诉等)形成一个数据库给isp查询，从而ISP会知道你的域名或IP是否abuse
==============================================================
DKIM
DKIM是2004年提出，现在已经是IETF标准化了的，它是把yahoo的DomainKeys和cisco的Identified Internet Mail结合而成
DKIM工作的原理是，在信头里插入一个DKIM签名，然后接收方邮件服务器会查询DNS里面的签名字段来和信头里面的签名对比，一致则通过
DKIM和DomainKeys是兼容的，就是说比如你以前为了支持domainkeys验证在DNS里面添加了txt字段
现在你需要使用DKIM就只需要在你的邮件服务器里面改下配置，
让邮件服务器每次发邮件的时候在信头里添加DKIM签名，
而不需要再去改以前的DNS里面的txt的东西
或者这么说：如果你需要同时使用DKIM和DomainKeys， DNS里面并不需要为这两个验证分别添加两个txt， 只需要一个txt就可以了，
然后邮件服务器里面设置可以两个一起用，DomainKeys和DKIM签名
阅读(3374) | 评论(0) | 转发(0) |
