![在解析 SPF 记录时,其中间的“~all”是否表示该记录的结束?](https://linux22.com/image/654942/%E5%9C%A8%E8%A7%A3%E6%9E%90%20SPF%20%E8%AE%B0%E5%BD%95%E6%97%B6%EF%BC%8C%E5%85%B6%E4%B8%AD%E9%97%B4%E7%9A%84%E2%80%9C~all%E2%80%9D%E6%98%AF%E5%90%A6%E8%A1%A8%E7%A4%BA%E8%AF%A5%E8%AE%B0%E5%BD%95%E7%9A%84%E7%BB%93%E6%9D%9F%EF%BC%9F.png)
我公司的SPF记录格式如下:
“v=spf1 包括:_spf.google.com~全部mx ip4:XX0.0/23 包括:spf.example.com ?全部”
因此,SPF 记录中间有一个“~all”。在openspf.com 网站对于“全部”机制,他们是这样说的:
此机制始终匹配。它通常位于 SPF 记录的末尾。
因此,他们并不是说“全部”都必须放在 SPF 记录的末尾,而是说它通常放在最后。
在我们公司,最近我们发现从我们的 SPF 记录中列出的服务器发送的电子邮件中存在一些软故障,但我们的 SPF 记录通过了迄今为止我发现的所有验证工具。
我想知道的是,在 Google Apps (_spf.google.com) 的包含后面直接加上这个“~all”是否会导致解析停止,无法识别 SPF 记录的其余部分?通过还是软失败是否取决于解析者以及他们处理 SPF 记录的具体实现?是否有理由使用不在 SPF 记录末尾的“all”机制?
是的,我知道我们可以更改我们的 SPF 记录。这个问题更多的是为了澄清这一切是如何运作的,而不一定是为了解决我们的具体情况。
答案1
RFC 7208§5.1对此有明确的说明:all
出现之后,其后的所有内容都必须被忽略。
“全部”之后的机制永远不会被测试。“全部”之后列出的机制必须被忽略。任何“重定向”修饰符(第 6.1 节) 当记录中存在“全部”机制时,必须被忽略,无论术语的相对顺序如何。
它废除了 RFC,RFC 4408,说了同样的事情;新版本的 RFC 只是阐明了意图。
“all” 之后的机制将永远不会被测试。任何“重定向”修饰符(第 6.1 节) 在存在“全部”机制时无效。
因此,符合 SPF 规范的实现将完全忽略第一个 之后的所有内容~all
。但这并不意味着每个实现都符合规范。特别是,这可能被认为值得澄清因为一个或多个实现不符合。
目前还不清楚为什么在线验证工具无法发现这种错误配置,但如果您打算在第一次all
使用之后使用任何东西,您应该更正记录,因为正确的实现会忽略它。
答案2
“v=spf1 包括:_spf.google.com ~all a mx ip4:XX0.0/23 包括:spf.example.com ?all”
按顺序说:
“通过 SPF 记录的电子邮件
_spf.google.com
对我们的域名有效”“对我们域中的所有其他发件人进行软失败”
“来自我们的 A 记录的电子邮件对我们的域名有效”
“来自我们的 MX 记录的电子邮件对我们的域名有效”
“来自该 IP 范围的电子邮件
x.x.0.0/23
对于我们的域名有效”“通过 SPF 记录的电子邮件
spf.example.com
对我们的域名有效”“我们的域名所有其他发件人的电子邮件都无法通过任何方式验证”
根据记录语法:
机制按顺序进行评估。如果没有机制或修饰符匹配,则默认结果为“中立”。
因此,对于您来说,一旦它达到“所有其他人的软失败”,这实际上就是它......它应该忽略您指定的其余机制。
您的 SPF 记录应尽可能简洁。我非常怀疑您是否拥有整个 /23 网络来为您的域发送电子邮件,您的所有 A 记录也不应该如此。也许如此...但很可能不是。
一个干净的 SPF 记录应该是这样的:
“v=spf1 包括:_spf.google.com 包括:spf.example.com mx -all”
这基本上表明 _spf.google.com、spf.example.com 和您的 MX 记录是您域名的唯一有效发件人……其他所有内容都应被视为无效。
答案3
A得到妥善实施SPF 检查器将短路机制match,check_host() 函数将返回限定符值作为结果。我没有任何“真实世界”数据可以提供给您,以说明大多数电子邮件服务器是否遵循 RFC。
来源:RFC7208(见第 17 页)