Problemumgehungen für das maximale Limit für DNS-Interactive-Begriffe im SPF-Datensatz überschritten?

Als Hosting-Anbieter senden wir E-Mails im Namen unserer Kunden, damit diese DKIM- und SPF-E-Mail-Einträge in ihrem DNS einrichten können, damit die Zustellbarkeit von E-Mails genau richtig ist. Wir haben ihnen geraten , http://mail-tester.com zu verwenden, um zu testen, dass sie nichts verpasst haben, und ich mag dieses Tool sehr.

Ein Problem, auf das wir einige Male gestoßen sind und bei dem ich mir nicht sicher bin, ist das DNS-Limit für den SPF-Eintrag basierend auf dem Domain-Namen. Also, wenn Sie dies haben:

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

Du wirst kriegen

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

Wie so:

Ich habe einige Fragen dazu.

1. Ich zähle hier sechs Domain-Namen, nicht zehn. Warum werden hier also zehn DNS-Anfragen gestellt? Hier geantwortet

2. Ist dieser interaktive Begriff von 10 DNS eine Warnung oder ein echter Fehler? zB sollten wir uns interessieren? Es nervt unsere Kunden ein bisschen und sie mailen uns um Unterstützung. Hier geantwortet

3. Ist diese interaktive Beschränkung von 10 DNS ein echtes Problem im heutigen Web? Wie Sie sehen, hat dieser Kunde viele Dienste, die ihm E-Mails senden, und alle sind legitim. Vielleicht wurde dieses DNS-Limit im Jahr 2000 festgelegt, als das Delegieren von E-Mail-Diensten wie diesem nicht üblich war?

Ja, wir können unsere Kunden dazu bringen, das Include in IPs im SPF-Datensatz zu ändern, aber das bringt uns in eine schwierige Lage, wenn wir jemals die IPs ändern. Wirklich nicht wollen, dass zu tun ..

Welche Workarounds gibt es dafür?

1. Meistens bereits beantwortet, bitte beachten Sie, dass Google auf diese Weise falsch ist - Sie möchten _spf.google.comfür die Weiterleitung eine Strafe verhängen oder verwenden:

   ○ → 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"
   

Diese Suche wird 5/10 für sich allein verbrauchen - 4/10 ist immer noch schlecht, aber 20% weniger.

2. Die Verarbeitung wird angehalten und ein permanenter Fehler wird zurückgegeben. Die Entscheidung, wie ein permanenter Fehler behandelt werden soll, liegt beim Motor, der den SPF verwendet.

3. Ja - ohne die Verarbeitungsgrenzen könnten SPF-Mechanismen als DoS-Verstärker gegen Dritte oder Dritte eingesetzt werden.

Um dieses Problem zu umgehen, können E-Mails beispielsweise von einer Unterdomäne der Haupteigenschaft stammen community.largecorporation.com.

1. Unter der Annahme, dass Redundanzen (wie mehrfache Verweise auf _spf.google.comund die Datensätze, auf die sie sich beziehen) nur einmal gezählt werden, zähle ich 17 Suchvorgänge ab dem Punkt, an dem Sie den ursprünglichen Datensatz bereits nachgeschlagen haben. (Siehe unten.)

2. Es weigert sich, alle Datensätze nachzuschlagen, die zur Auswertung Ihres SPF-Datensatzes erforderlich sind, da dies "zu viel Arbeit" bedeuten würde. Vermutlich bedeutet dies, dass Ihre Domain so behandelt wird, als ob sie keinen SPF-Eintrag hätte (oder möglicherweise ablehnt). Die Spezifikation besagt, dass dies zu einem Fehlerspiegel führt , der es dem Empfänger ziemlich offen lässt, zu entscheiden, was zu tun ist .

3. Ich denke, Missbrauch hat im Allgemeinen eher zugenommen als abgenommen. Diese Beschränkung scheint dazu gedacht zu sein, missbräuchliche Absenderdomänen zu vereiteln, die den Empfänger ansonsten möglicherweise mit enormen SPF-Ketten überwältigen und möglicherweise zu DoS führen.

Ich denke, dass das Auslagern von E-Mails zwar üblich ist, es jedoch nicht so üblich ist, E-Mails an sechs verschiedene Anbieter auszulagern. Sie müssen den SPF-Datensatz irgendwie optimieren.
(Zum einen aspmx.googlemail.comscheint der Verweis auf verschwenderisch, da er sofort zu einem anderen Namen umleitet.)

<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"

Wie die akzeptierte Antwort auf eine der verknüpften Fragen verdeutlicht, setzen viele der zugrunde liegenden Tools für UNIX-Systeme diese Grenze tatsächlich durch (wenn auch nicht alle auf genau dieselbe Weise), sodass jede SPF-Implementierung, die sie verwendet - fast alle unter UNIX - wird auch diese Grenzen durchsetzen. Windows-Systeme sind ein Gesetz für sich, und ich kann sie nicht beleuchten.

Die Problemumgehung besteht darin, einen Cron-Job zu haben, der Ihre Kette von ausgelagerten SPF-Datensätzen bewertet, sie alle als IPv4- und IPv6-Netblocks ausdrückt und dies in Ihren Datensatz umwandelt. Vergiss das nicht -all.

In Ihrem Fall möchten Sie, dass Kunden einen SPF-Datensatz veröffentlichen können, den sie dann nicht mehr pflegen müssen. Eine Möglichkeit wäre, dass jeder Kunde einen Datensatz mit redirect=spf.client1.jeffs-company.exampledem Inhalt veröffentlicht und Sie dann die Liste der Netblocks unter pflegen jeffs-company.example.

Vielleicht wurde dieses DNS-Limit im Jahr 2000 festgelegt, als das Delegieren von E-Mail-Diensten wie diesem nicht üblich war?

Das Limit macht es schwierig, Ihre E-Mails an sechs oder sieben große Vorgänge auszulagern. aber wenn Sie das tun, haben Sie für alle praktischen Zwecke die Kontrolle über Ihre E-Mail trotzdem verloren.

Irgendwann, irgendwann, wird ein Programmierer, dessen Existenz Sie nicht gewusst haben und über den Sie keine Kontrolle haben, ein Semikolon falsch platzieren, und eine Tonne gefälschter E-Mails wird mit Ihrem SPF-Imprimatur direkt darauf gesendet. Die vollständige Kontrolle über Ihre E-Mail-Infrastruktur setzt die vollständige Kontrolle über Ihre E-Mail-Infrastruktur voraus.