这篇文章系统记录了我对于SPF协议的RFC-7208文档的阅读,记录一些我认为重要的关键点和相关问题。
使用spf记录的意义
- 可以对发件方声称来自的域名进行验证防止伪造
- 在验证身份使用之后,可以根据发送方的域(而不是主机的IP地址)对邮件进行本地策略决策。这样可以参考域名的声誉来做决定。
rfc文档要点
2.1 如果ADMDs选择发布SPF记录,并且希望支持做出负面授权决定的接收者,则有必要发布以“-all”结尾的记录,或者重定向到具有此功能的其他记录;
2.1 修改SPF记录时要有过渡期 确保旧邮件的交付 [RFC5321], Section 4.5.4.1 讨论了消息的传递时长
2.2 spf检查不一定进行 取决于收件方MTA的检查配置 例如配置发信方ip白名单
2.3 建议同时检查HELO和MAIL FROM的标识,(It is RECOMMENDED that SPF verifiers not only check the “MAIL FROM” identity but also separately check the “HELO” identity by applying the check_host() function (Section 4) to the “HELO” identity as the
.) 2.3 同时检查HELO和MAIL FROM的话,建议先检查HELO。Checking “HELO” before “MAIL FROM” is the RECOMMENDED sequence if both are checked.只有当“HELO”字符串是一个有效的多标签域名时,才能执行此SPF检查。
2.4 允许MAIL FROM标识为空。allows the reverse-path to be null (see Section 4.5.5 in [RFC5321]).在这种情况下,没有显式的发件人邮箱,并且可以假定这样的消息是来自邮件系统本身的通知消息。本文档将“MAIL FROM”标识定义为由本地部分的“postmaster”和“HELO”标识(之前可能单独检查过,也可能没有)组成的邮箱。
2.5 应该在接收邮件的SMTP事务的处理过程中执行授权检查。也就是对话过程中进行检查,稍后检查带来安全问题。
2.6 有七种结果的说明
3.0 明确指出不能有多条SPF记录 multiple SPF records are not permitted for the same owner name.
3.1 记录的字符内容编码为[US-ASCII]。
3.3 spf记录是可以由多个引号字符串组成的
1
2
3IN TXT "v=spf1 .... first" "second string..."
is equivalent to:
IN TXT "v=spf1 .... firstsecond string..."3.4 对spf记录大小的描述 (涉及dns协议与其它rfc文档 暂未完全理解) 给定域名的已发布SPF记录应保持足够小,以便查询结果符合512个字节
4.6 如果结果记录集包含多个记录,check_host()将生成“permerror”结果。
4.6 首先验证记录的语法,如果记录中的任何地方有任何语法错误,check_host()将立即返回结果“permerror”,无需进一步解释或计算。
4.6.4 以下术语引起DNS查询:“include”、“a”、“mx”、“ptr”和“exists”机制,以及“redirect”修饰符。SPF实现必须在SPF评估期间将这些术语的总数限制为10,以避免DNS上不合理的负载。
4.6.4 the evaluation of each “MX” record MUST NOT result in querying more than 10 address records. If this limit is exceeded, the “mx” mechanism MUST produce a “permerror” result.
4.6.4 mta或其他处理器应该对计算check_host()的最大消耗时间进行限制。这样的限制应该至少允许20秒。如果超过了这个限制,授权的结果应该是“temperror”。
4.7 如果所有机制都不匹配,并且没有“重定向”修饰符,那么check_host()将返回“中性”的结果,就像“?all”
5 ip地址比较的说明 如果指令中没有给出CIDR前缀长度,则比较
和ip地址是否相等。如果指定了CIDR前缀长度,则只比较 的指定高阶位数和ip地址是否相等。 5 当任何机制获取主机地址与
进行比较时,当 为IPv4时,获取“A”记录;当 是IPv6地址时,获取“AAAA”记录。 5.1 Mechanisms listed after “all” MUST be ignored. 当记录中存在“all”机制时,必须忽略任何“redirect”修饰符。
5.2 include机制不影响发送方策略 发送方策略的确定仍然是由原始域的SPF记录的all机制决定
5.5 ptr机制不建议使用,但是check_host函数必须要支持检查,可以放在最后检查
5.6 If ip4-cidr-length is omitted, it is taken to be “/32”. If ip6-cidr-length is omitted, it is taken to be “/128”. 但是ip地址必须完整,不可省略。
6.0 在这个文档中定义的修饰符(“redirect”和“exp”)应该出现在记录的末尾
6.1 redirect 修饰符不能和 all 机制共存。(Any “redirect” modifier MUST be ignored if there is an “all” mechanism anywhere in the record.)
7 宏定义字符串相关说明
1
2
3
4
5
6
7
8s = <sender>
l = local-part of <sender>
o = domain of <sender>
d = <domain>
i = <ip>
p = the validated domain name of <ip> (do not use)
v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
h = HELO/EHLO domain8 两种处理决策
允许消息传递(成功的SMTP应答代码)并添加一个额外的头字段,该字段指示check_host()返回的结果和其他重要细节;
在SMTP会话中进行处理,返回一个永久SMTP错误(拒绝)或临时SMTP错误(“稍后重试”);
8.2 A “neutral” result MUST be treated exactly like the “none” result;
8.5 接收方的MUA可以突出显示“softfail”状态,或者接收方的MTA可以使用greylisting 并在第一次接收到消息时发出通知,但是根据接收方策略在稍后的尝试中接受该消息。
8.6 “temperror”结果表示SPF验证器在执行检查时遇到了暂时的(通常是DNS)错误。SMTP reply code of 451。
8.7 “permerror”结果意味着域发布的记录不能被正确解释。 SMTP reply code of 550。
9 it is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header. 建议SMTP接收者在消息头中记录SPF处理的结果。Received-SPF 包含全部spf消息,可以重建spf查询。Authentication-Results主要传递结果本身。
10.3 邮件传递中介 需要关注邮件地址的变化 [RFC5321], Section 3.9.
11 这一节介绍了一些可能由SPF带来的安全问题
11.1 通过SPF验证器来创建DoS攻击,恶意的一方可能会创建一个SPF记录,其中会引用受害者的域名,并向不同的SPF验证者发送许多电子邮件;这样攻击者可以隐藏攻击的真正来源。
11.1 恶意者可能会把伪造大量声称来自目标的邮件,传送到各式各样的合法邮件主机。通过spf查询给目标DNS服务器带来大量负载。
11.6 宏机制允许发送方将任意文本(任何非空 [US-ASCII]字符)注入接收方DNS查询。
12 这一节用ABNF表示法定义了spf记录的格式。其中文本字符串(引号中的字符串)不区分大小写。Hence, “mx” matches “mx”, “MX”, “mX”, and “Mx”.
查看SPF记录的方法
Windows下,在命令行下输入:
1 | nslookup -type=txt 域名 |
Unix操作系统下用:
1 | dig -t txt 域名 |
相关思考
记录更新是否会带来旧邮件丢失的问题 是否只增不删邮件转发服务 是否有可能导致邮件通过低安全性的邮箱进入高安全性的邮箱
灰名单技术
greylist(灰名单)的设计大体上是基于一种重试的原则,即第一次看到某个IP要想给某个收件人发信,那么它将简单的返回一个临时错误(4xx),并拒绝此请求,正常的邮件服务器都会在一段时间内(如5-10分钟左右)重发一次邮件。greylist(灰名单)发现还是刚才同样的ip地址和收件人,认为此ip是来自合法服务器的,予以放行。如果是非正常的邮件,那么或者将永远也不再进行重试,或者会疯狂重试,但由于间隔太近,而遭拒绝。
[RFC5598] describes the Internet email architecture.
4.6.4的限制是不是对递归依旧有效