“v = spf1 include：_spf.google.com~所有mx ip4：X.X.0.0 / 23包括：spf.example.com？all”
因此,我们在SPF记录中间有一个“全部”.在openspf.com website,他们说这关于“所有”机制：
This mechanism always matches. It usually goes at the end of the SPF
record.
所以,他们并没有说“所有”都要在SPF记录结束时说,但它通常会在最后结束.
在我们公司,最近我们看到从我们的SPF记录中列出的服务器发送的电子邮件中有一些软故障,但我们的SPF记录通过了迄今为止我发现的所有验证工具.
我想知道的是,在Google Apps(_spf.google.com)的包含之后,这个“〜all”是否会导致解析停止并且无法识别剩余的SPF记录？传递与软故障取决于谁在解析它以及它们如何处理SPF记录的具体实现？是否有任何理由要求“全部”机制不在SPF记录的末尾？
是的,我知道我们可以改变我们的SPF记录.这个问题更多的是澄清这一切是如何运作的,而不一定是解决我们的具体情况.
解决方法
Mechanisms after “all” will never be tested. Mechanisms listed after “all” MUST be ignored. Any “redirect” modifier (07001) MUST be ignored when there is an “all” mechanism in the record,regardless of the relative ordering of the terms.
它淘汰的RFC,RFC 4408,说了很多相同的事情;较新版本的RFC只是澄清了意图.
Mechanisms after “all” will never be tested. Any “redirect” modifier (07003) has no effect when there is an “all” mechanism.
因此,符合SPF的实现将完全忽略第一个〜所有之后的所有内容.但是,这并不意味着每个实现都符合规范.特别是,这可能被认为值得澄清,因为一个或多个实现不符合.
目前还不清楚为什么在线验证工具不能捕获这种错误配置,但是如果你想在第一次使用之后做任何事情,你应该更正记录,因为正确的实现会忽略它.
原文地址：https://www.jb51.cc/html/229758.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
