拥有带有最终 ~all 规则的 SPF 记录有什么意义？

Question

在过去的一个小时里，我一直在研究 SPF，浏览 RFC-4408，然后浏览 another tutorial。

我拥有自己的域，并在该域后面的服务器上安装了 postfix。除了我的普通地址之外，我还希望能够使用我自己的电子邮件地址作为发件人使用 GMail 发送电子邮件。

我确实收到了很多退回的垃圾邮件，其中垃圾邮件发送者将我的电子邮件地址用作“发件人”行:(据我了解，SPF 用于检查是否允许给定的 SMTP 服务器发送具有特定发件人域名的邮件。这将有助于上述反弹。

很明显，如果我想通过 gmail 发送邮件，我必须允许 gmail 通过 SPF 记录以我的名义发送邮件。

在their help之后，我添加了以下TXT记录：

v=spf1 include:_spf.google.com ~all

他们特别地建议不要使用-all 作为失败规则。

鉴于~all 是一个“软失败”，它仍然接受所有消息，启用 SPF 有什么意义？

我尝试从外部主机发送一些邮件，但它们被接受了，唯一的区别是我的邮件服务器假定没有 SPF 记录。

通过 GMail 发送时的日志摘录：

May  8 15:15:58 h2150855 policyd-spf[6184]: None; identity=helo; client-ip=300.300.300.300; helo=mail-lf0-f52.google.com; envelope-from=mygmailaddress@gmail.com; receiver=mypersonaladdress@example.com
May  8 15:15:58 h2150855 policyd-spf[6184]: Pass; identity=mailfrom; client-ip=300.300.300.300; helo=mail-lf0-f52.google.com; envelope-from=mygmailaddress@gmail.com; receiver=mypersonaladdress@example.com

...并通过第三方服务器发送：

May  8 15:19:17 h2150855 policyd-spf[6554]: None; identity=helo; client-ip=301.300.300.300; helo=theserver.example.com; envelope-from=exhuma@theserver.example.com; receiver=mypersonaladdress@example.com
May  8 15:19:17 h2150855 policyd-spf[6554]: None; identity=mailfrom; client-ip=301.300.300.300; helo=theserver.example.com; envelope-from=exhuma@theserver.example.com; receiver=mypersonaladdress@example.com

我能看到的唯一区别是 postfix SPF 插件将 gmail 邮件显式标记为Pass，而另一个标记为None。

我现在认为添加 SPF 并没有真正对我的邮件设置产生任何影响，我正在考虑再次删除它。

Answer 1

~all 在某些 DMARC 包（如 OpenDMARC）中默认被解释为失败，但您可以更改标志以将其解释为通过。

同样，?all 在 OpenDMARC 中默认被解释为失败。

相比之下，-all 始终被解释为失败，无论您部署了什么 DMARC 包。

我已经写了一篇关于这个主题的帖子：Why SPF Authentication Fails。

还涵盖了其他相关概念，包括 none、neutral、temperror、permerror 等。

Answer 2

它之所以推荐~all 而不是-all 是因为它与 DMARC 交互的方式；使用 -all 的建议早于 DMARC 的存在。 -all 确实是一个有效（且正确）的设置如果您单独使用 SPF，但 -all 通常会破坏 DMARC，因为它的规则不会被评估。如果您设置~all 默认 SPF 操作，它会将决定交给 DMARC 层，此时您可以说“我们认为 SPF 软故障是硬故障”，然后继续获得 DMARC 的其他好处。

所以，简而言之，~all 并非毫无意义如果您使用的是 DMARC。 （?all总是毫无意义！）

Answer 3

您最好的选择是仅将 ~all 用于测试并将 -all 用于生产。甚至 RFC 也建议：

如果域所有者选择发布 SPF 记录，建议这样做 它们以“-all”结尾，或者重定向到其他记录，所以 可以做出最终的授权决定。

当遇到软故障时，某些站点实际上会拒绝电子邮件，或将其定向到垃圾邮件文件夹，但简单地强制硬故障将改善站点的更改，这些站点拒绝尝试将您的域伪造为发件人的邮件.