Soluzioni alternative per il limite massimo di termini DNS-interattivi superato nel record SPF?

Come provider di hosting, inviamo e-mail per conto dei nostri clienti, quindi li aiutiamo a impostare i record e-mail DKIM e SPF nel loro DNS per ottenere la consegna delle e-mail nel modo giusto. Abbiamo consigliato loro di usare http://mail-tester.com per testare che non hanno perso nulla e questo strumento mi piace molto.

Un problema che abbiamo riscontrato alcune volte, e non ne sono sicuro, è il "limite" DNS sul record SPF basato sul nome di dominio. Quindi se hai questo:

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

Otterrai

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

Così:

Ho alcune domande a riguardo.

1. Conto qui sei nomi di dominio, non 10, quindi perché risponde "dieci" richieste DNS qui? Risposto qui

2. Questo limite di 10 DNS interattivi è un avvertimento o un errore reale ? ad es. dovremmo preoccuparci? Sta assillando un po 'i nostri clienti e ci inviano un'e-mail per il supporto. Risposto qui

3. Questo limite di 10 DNS interattivi è un vero problema sul web di oggi? Come puoi vedere, questo cliente ha molti servizi che inviano e-mail per loro e sono tutti legittimi. Forse questo limite DNS è stato fissato nel 2000 quando delegare servizi di posta elettronica come questo non era comune?

Sì, possiamo fare in modo che i nostri clienti cambino l'inclusione in IP nel record SPF ma ciò ci mette in difficoltà se cambiamo IP, un sacco di cose dei clienti si romperanno. Davvero non voglio farlo ..

Quali soluzioni alternative ci sono per questo?

1. Per lo più già risposto, tieni presente che includere Google in questo modo è errato : vuoi utilizzare _spf.google.como incorrere in una penalità per il reindirizzamento:

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

Quella ricerca consumerà 5/10 da sola - 4/10 fa ancora schifo ma il 20% in meno.

2. Sarà interrompere l'elaborazione e restituire un errore permanente - spetta al motore utilizzando l'SPF per decidere come si vuole trattare un errore permanente.

3. Sì, senza i limiti di elaborazione, i meccanismi SPF potrebbero essere utilizzati come amplificatore DoS contro una terza o seconda parte.

Come soluzione alternativa, le e-mail possono provenire da un sottodominio della proprietà principale, community.largecorporation.comad esempio.

1. Supponendo che le ridondanze (come i riferimenti multipli _spf.google.come i record a cui fa riferimento) vengano conteggiate una sola volta, conto 17 ricerche dal punto in cui hai già cercato il record iniziale. (Vedi sotto.)

2. Rifiuta di cercare tutti i record necessari per valutare il tuo record SPF perché sarebbe "troppo lavoro". Presumibilmente questo significa che tratterà il tuo dominio come se non avesse alcun record SPF (o possibilmente rifiutarlo). La specifica afferma che questo si traduce in permerror , che lascia abbastanza aperto per il destinatario decidere cosa fare .

3. Penso che l'abuso sia andato su piuttosto che giù, in generale. Questo limite sembra inteso a contrastare domini di mittenti offensivi che potrebbero altrimenti essere in grado di sopraffare il destinatario con enormi catene di SPF, portando potenzialmente a DoS.

Penso che mentre l'outsourcing della posta elettronica è comune, in realtà non è così comune esternalizzare la posta elettronica a sei diversi provider. Dovrai ottimizzare il record SPF in qualche modo.
(Per prima cosa, il riferimento a aspmx.googlemail.comsembra dispendioso in quanto immediatamente reindirizza a un nome diverso.)

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

Come chiarisce la risposta accettata a una delle domande collegate , molti degli strumenti sottostanti per i sistemi UNIX applicano effettivamente questo limite (anche se non tutti esattamente allo stesso modo), quindi qualsiasi implementazione SPF che li utilizza - che è quasi interamente su UNIX - applicherà anche questi limiti. I sistemi Windows sono una legge a sé stante e non posso far luce su di essi.

La soluzione alternativa consiste nell'avere un cron job che valuta la catena di record SPF in outsourcing, li esprime tutti come netblock ipv4 e ipv6 e li inserisce nel record. Non dimenticare il -all.

Nel tuo caso, desideri che i clienti siano in grado di pubblicare un record SPF che non devono quindi conservare. Una possibilità potrebbe essere quella di pubblicare ogni record di un cliente contenente redirect=spf.client1.jeffs-company.example, e quindi fare il lavoro di mantenimento dell'elenco di netblock a jeffs-company.example.

Forse questo limite DNS è stato fissato nel 2000 quando delegare servizi di posta elettronica come questo non era comune?

Il limite rende difficile esternalizzare la tua e-mail a sei o sette operazioni di grandi dimensioni; ma probabilmente se lo stai facendo hai perso il controllo della tua email a tutti gli effetti.

Da qualche parte, un giorno, un programmatore subappaltato della cui esistenza eri completamente inconsapevole e su cui non hai controllo sta per sbagliare un punto e virgola, e una tonnellata di email fasulle verranno inviate con il tuo imprimatur SPF esattamente su di esso. Il pieno controllo della tua e-mail richiede il pieno controllo della tua infrastruttura e-mail, e questo è secondo me del tutto incompatibile con la maggior parte dell'outsourcing.

Un altro modo di aggirare questi problemi è guardare quale software viene utilizzato esattamente per controllare le impostazioni SPF. Nel mio caso è cluebringer / PolicyD, che utilizza Mail::SPF::Serveralla fine e accetta argomenti che allentano i limiti altrimenti codificati. Il problema è che lo stesso cluebringer non supporta il rilassamento di questi argomenti al momento , ma che potrebbe essere cambiato in futuro e si potrebbe essere in grado di dire semplicemente ai fornitori di servizi di ricezione di tali possibilità di allentare le proprie impostazioni.

Se decidono di farlo è ovviamente fuori controllo, ma è almeno una possibilità.