☰

SPF 记录中 DNS 交互术语的最大限制超出了，如何解决？

tag-icon • tag-icon domain-name-system spf
SPF 记录中 DNS 交互术语的最大限制超出了，如何解决？

作为托管服务提供商，我们代表客户发送电子邮件，因此我们帮助他们在 DNS 中设置 DKIM 和 SPF 电子邮件记录，以确保电子邮件传递率。我们一直建议他们使用http://mail-tester.com来测试他们没有错过任何东西，我非常喜欢这个工具。

我们遇到过几次的一个问题，我不确定，是基于域名的 SPF 记录的 DNS“限制”。因此，如果您有以下情况：

v=spf1 a include:aspmx.googlemail.com include:campaignmonitor.com include:authsmtp.com include:mail.zendesk.com include:salesforce.com include:_hostedspf.discourse.org ~all

你会得到

example.com ... campaignmonitor.com: Maximum DNS-interactive term limit (10) exceeded

就像这样：

邮件测试结果

我对此有一些疑问。

  1. 我在这里数了一下，有 6 个域名，而不是 10 个，那么为什么这里的 DNS 请求达到“10”呢？ 在此处回答

  2. 这 10 个 DNS 交互式术语限制是警告或真实的错误？例如，我们应该关心吗？这让我们的客户有点烦，他们给我们发电子邮件寻求支持。 在此处回答

  3. 这 10 个 DNS 交互式术语限制在当今的网络上是否是一个真正的问题？如您所见，这位客户有一个很多为他们发送电子邮件的服务，并且它们都是合法的。也许这个 DNS 限制是在 2000 年设置的，当时委派电子邮件服务并不常见？

是的，我们可以让客户将 SPF 记录中的 IP 更改为包含 IP但如果我们更改 IP，这会让我们陷入困境，很多客户的东西都会损坏。真的不想这样做。

有什么办法可以解决这个问题？

答案1

  1. 大部分已经回答过了，请注意包括谷歌这样是错的- 您想要使用_spf.google.com重定向或承担重定向的惩罚：

     ○ → host -t txt aspmx.googlemail.com
 aspmx.googlemail.com descriptive text "v=spf1 redirect=_spf.google.com"

 ○ → host -t txt _spf.google.com
 _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

该查找本身将消耗 5/10 - 4/10 仍然很糟糕，但减少了 20%。

  1. 它会停止处理并返回永久错误- 由使用 SPF 的引擎来决定如何处理永久性错误。

  2. 是的 - 如果没有处理限制，SPF 机制可以用作 DoS 放大器针对第三方或者第二方。

作为一种解决方法，电子邮件可以来自主属性的子域 -community.largecorporation.com例如。

答案2

  1. 假设冗余（如对记录的多次引用_spf.google.com和它所引用的记录）仅计算一次，我从您已经查找初始记录的位置开始计算 17 次查找。（见下文。）

  2. 它拒绝查找评估您的 SPF 记录所需的所有记录，因为这会“太麻烦”。据推测，这意味着它会将您的域视为没有 SPF 记录（或可能拒绝它）。规范说这会导致 pererror， 哪个让接收者可以自由决定做什么。

  3. 我认为滥用行为总体上是增加了，而不是减少了。这一限制似乎是为了阻止滥用的发件人域，否则这些域可能会用大量的 SPF 链压垮收件人，从而可能导致 DoS。

我认为，虽然外包电子邮件很常见，但将电子邮件外包给六家不同的提供商实际上并不常见。您必须以某种方式优化 SPF 记录。
（首先，引用aspmx.googlemail.com似乎很浪费，因为它会立即重定向到不同的名称。） 

<lookup of example.com A>                   #1
$ dig aspmx.googlemail.com TXT +short       #2
"v=spf1 redirect=_spf.google.com"
$ dig _spf.google.com TXT +short            #3
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig _netblocks.google.com TXT +short      #4
"v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
$ dig _netblocks2.google.com TXT +short     #5
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig _netblocks3.google.com TXT +short     #6
"v=spf1 ~all"
$ dig campaignmonitor.com TXT +short        #7
"google-site-verification=HcHoB67Mph6vl5_x4gK5MN9YwN5gMgfZYdNmsP07tIg"
"v=spf1 mx ptr ip4:23.253.29.45/29 ip4:203.65.192.250 include:cmail1.com include:_spf.google.com include:stspg-customer.com ~all"
$ dig cmail1.com TXT +short                 #8
"google-site-verification=HSJ8sL4AxQo0YHHNk9RwDqs0p3lJPGmc1nCrSsmous8"
"mailru-verification: 95d4c6eb0645b43c"
"v=spf1 ip4:103.28.42.0/24 ip4:146.88.28.0/24 ip4:163.47.180.0/22 ip4:203.55.21.0/24 ip4:204.75.142.0/24 ~all"
$ dig stspg-customer.com TXT +short         #9
"v=spf1 ip4:166.78.68.221 ip4:166.78.69.146 ip4:23.253.182.103 ip4:192.237.159.42 ip4:192.237.159.43 ip4:167.89.46.159 ip4:167.89.64.9 ip4:167.89.65.0 ip4:167.89.65.100 ip4:167.89.65.53 -all"
$ dig authsmtp.com TXT +short               #10
"v=spf1 include:spf-a.authsmtp.com include:spf-b.authsmtp.com ~all"
"google-site-verification=skc1TleK4GylDiNZUayfvWWgqZIxmmiRj4KgXlCgB8E"
$ dig spf-a.authsmtp.com TXT +short         #11
"v=spf1 ip4:62.13.128.0/24 ip4:62.13.129.128/25 ip4:62.13.136.0/22 ip4:62.13.140.0/22 ip4:62.13.144.0/22 ip4:62.13.148.0/23 ip4:62.13.150.0/23 ip4:62.13.152.0/23 ~all"
$ dig spf-b.authsmtp.com TXT +short         #12
"v=spf1 ip4:72.52.72.32/28 ip4:64.49.192.16/29 ip4:209.61.188.242 ip4:64.49.192.24 ip4:64.49.192.25 ip4:64.49.210.64/29 ip4:64.49.210.72/30 ip4:64.49.210.76 ip4:64.49.210.77 ip4:64.49.210.78 ~all"
$ dig mail.zendesk.com TXT +short           #13
"v=spf1 ip4:192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ~all"
$ dig salesforce.com TXT +short             #14
"adobe-idp-site-verification=898b7dda-16a9-41b7-9b84-22350b35b562"
"MS=749862C9F42827A017A6EA2D147C7E96B3006061"
"MS=ms68630177"
"v=spf1 include:_spf.google.com include:_spfblock.salesforce.com include:_qa.salesforce.com ip4:136.146.208.16/28 ip4:136.146.210.16/28 ip4:136.146.208.240/28 ip4:136.146.210.240/28 ip4:85.222.130.224/28 ip4:136.147.62.224/28 ip4:136.147.46.224/28 mx ~all"
$ dig _spfblock.salesforce.com TXT +short   #15
"v=spf1 ip4:96.43.144.0/20 ip4:182.50.76.0/22 ip4:202.129.242.0/23 ip4:204.14.232.0/21 ip4:62.17.146.128/26 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:68.232.207.20 ip4:207.67.38.45 ip4:198.245.81.1 ip4:198.245.95.4/30 ip4:136.146.128.64/27  ~all"
$ dig _qa.salesforce.com TXT +short         #16
"v=spf1 ip4:199.122.122.176/28 ip4:199.122.121.112/28 ip4:199.122.122.240/28 ip4:66.231.95.0/29 ~all"
$ dig _hostedspf.discourse.org TXT +short   #17
"v=spf1 ip4:64.71.148.0/29 ip6:2001:470:1:3c2::/64 -all"

答案3

作为对其中一个链接问题接受的答案明确地说，UNIX 系统的许多底层工具确实会强制执行此限制（尽管并非所有工具都以完全相同的方式执行），因此任何使用它们的 SPF 实现（几乎全部在 UNIX 上）也会强制执行这些限制。Windows 系统有自己的一套规则，我无法解释它们。

解决方法是执行一个 cron 作业来评估您的外包 SPF 记录链，将它们全部表示为 ipv4 和 ipv6 网络块，并将其纳入您的记录。 不要忘记-all。

在您的案例中，您希望客户能够发布 SPF 记录，然后他们无需维护该记录。一种可能性是让每个客户发布一条包含 的记录redirect=spf.client1.jeffs-company.example，然后您负责维护 处的网络块列表jeffs-company.example。

也许这个 DNS 限制是在 2000 年设置的，当时这种委托电子邮件服务并不常见？

这个限制确实使你将电子邮件外包给六七家大型公司变得困难；但可以说，如果你这样做，从实际意义上来说你已经失去了对电子邮件的控制。

某天，某个地方，某个分包程序员（你完全不知道他的存在，你也无法控制他）会放错一个分号，然后一大堆带有你的 SPF 许可的虚假电子邮件就会被发送出去。完全控制你的电子邮件需要完全控制你的电子邮件基础设施，在我看来，这与大量外包完全不一致。

答案4

解决这些问题的另一种方法是查看到底使用哪种软件来检查 SPF 设置。在我的例子中，它是 cluebringer/PolicyD，它Mail::SPF::Server最终使用接受参数放宽原本硬编码的限制。问题是 cluebringer 本身目前不支持放宽这些论点，但这种情况将来可能会发生变化，人们可以简单地告知接收服务提供商这些可能性以放宽他们的设置。

如果他们决定这样做当然是不可接受的，但这至少是一个机会。

相关内容