最大のDNSインタラクティブ用語の制限の回避策は、SPFレコードで超えていますか？
ホスティングプロバイダーとして、私たちはクライアントに代わってメールを送信します。そのため、クライアントがDNSでDKIMおよびSPFメールレコードを設定して、メール配信を適切に行うのを支援します。 http://mail-tester.com を使用して、何も見落とさなかったことをテストするようにアドバイスしています。このツールはとても気に入っています。
何度か遭遇した1つの問題で、よくわかりませんが、ドメイン名に基づく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
そのようです：
これについていくつか質問があります。
ここでは、10ではなく6つのドメイン名を数えますが、なぜここで「10」のDNSリクエストをヒットするのですか？ここで回答この10 DNSインタラクティブ用語の制限は警告または実際のエラーですか。私たちは気にする必要がありますか？それは私たちの顧客を少し悩ませています、そして彼らはサポートのために私達に電子メールを送ります。ここで回答この10 DNSインタラクティブ用語の制限は、今日のWebで実際の問題ですか？ご覧のとおり、この顧客にはメールを送信するサービスがlotあり、それらはすべて正当です。おそらく、このDNS制限は、このようなメールサービスの委任が一般的ではなかった2000年に設定されたのでしょうか。
はい、お客様にSPFレコードのインクルードをIPに変更させることができますが、これにより、IPを変更した場合、大量の顧客のものは壊れます。本当にそれをしたくありません。
これにはどのような回避策がありますか？
冗長性（
_spf.google.comへの複数の参照とそれが参照するレコードなど）が1回だけカウントされると仮定して、最初のレコードをすでに調べたところから17回のルックアップをカウントします。 （下記参照。）SPFレコードを評価するために必要なすべてのレコードを検索することは拒否されます。おそらくこれは、ドメインをSPFレコードがないかのように処理する（または拒否する可能性がある）ことを意味します。仕様では これによりpermerrorが発生する 、つまり 受信者が何をするかを決定するためにかなりオープンなままにします です。
一般的に、虐待は下がるのではなく上がっていると思います。この制限は、SPFの巨大なチェーンで受信者を圧倒し、DoSにつながる可能性のある不正な送信者ドメインを阻止することを意図しているようです。
電子メールのアウトソーシングは一般的ですが、実際には6つの異なるプロバイダーに電子メールをアウトソーシングすることはそれほど一般的ではないと思います。どういうわけか、SPFレコードを最適化する必要があります。
（1つには、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"
主にすでに回答済みです。Googleを含めてこのようにメモしてください 不正解 -使用したい
_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％少なくなります。
それは 処理を停止し、永続的なエラーを返す -永続的なエラーの処理方法を決定するのは、SPFを使用するエンジン次第です。
はい-処理制限がない場合、SPFメカニズムはサードパーティまたはセカンドパーティに対して DoSアンプとして使用される になる可能性があります。
回避策として、メールはメインプロパティのサブドメインから送信できます-community.largecorporation.com 例えば。
リンクされた質問の1つに対する受け入れられた回答 が明らかにするように、UNIXシステムの基礎となるツールの多くは実際にこの制限を強制します（ただし、すべてが正確に同じ方法ではない）ので、それらを使用するすべてのSPF実装-UNIXではほぼすべてです-これらの制限も適用されます。 Windowsシステム自体は法律であり、私はそれらに光を当てることはできません。
回避策は、アウトソーシングされたSPFレコードのチェーンを評価し、それらすべてをipv4およびipv6ネットブロックとして表現し、それをレコードにするcronジョブを作成することです。 -allを忘れないでください。
あなたの場合、顧客が維持する必要のないSPFレコードを公開できるようにしたいとします。 1つの可能性は、各顧客にredirect=spf.client1.jeffs-company.exampleを含むレコードを公開してもらい、ネットブロックのリストをjeffs-company.exampleで維持するというレッグワークを行うことです。
おそらく、このDNS制限は、このようなメールサービスの委任が一般的ではなかった2000年に設定されたのでしょうか。
この制限により、メールを6つまたは7つの大規模な業務にアウトソーシングすることが難しくなります。しかし間違いなく、あなたがそうしているなら、とにかくあなたはすべての実用的な目的のためにとにかくあなたの電子メールの制御を失っています。
どこかに、いつの日か、あなたがその存在を完全に認識しておらず、自分で制御できない一部の下請けのプログラマーがセミコロンを置き忘れてしまい、大量の偽の電子メールがSPFの無罪で真正面に送信されます。電子メールを完全に制御するには、電子メールインフラストラクチャを完全に制御する必要があります。これは、多くのアウトソーシングと完全に矛盾していると私は考えています。
これらの問題を回避する別の方法は、SPF設定を確認するためにどのソフトウェアが正確に使用されているかを調べることです。私の場合、それはcluebringer/PolicyDであり、最後にMail::SPF::Serverを使用し、その 引数を受け入れる ハードコードされた制限を緩和します。問題は、クルーブリンガー自体 現在、これらの引数の緩和をサポートしていません ですが、将来的に変更される可能性があり、受信サービスプロバイダーに設定を緩和する可能性について単に伝えることができるかもしれません。
彼らがそうすることを決定した場合、もちろんそれは人の制御の外にありますが、それは少なくともチャンスです。