Il record SPF di Office365 ha troppe ricerche

Per alcuni motivi amministrativi assolutamente ridicoli abbiamo un dominio diviso con una cassetta postale su Office365 che ci richiede di aggiungere include:outlook.comal nostro record SPF. Il problema è che questa sola regola richiede nove ricerche DNS di massimo 10.

Seriamente, è orribile. Basta guardarlo:

v=spf1
include:spf-a.outlook.com
include:spf-b.outlook.com
ip4:157.55.9.128/25
include:spfa.bigfish.com
include:spfb.bigfish.com
include:spfc.bigfish.com
include:spf-a.hotmail.com
include:_spf-ssg-b.microsoft.com
include:_spf-ssg-c.microsoft.com
~all

Dato che noi abbiamo il nostro sistema di posta grande-ish abbiamo bisogno di avere regole per a, mx, include:_spf1.mydomain.com, e include:_spf2.mydomain.comche ci mette a lookup 13 DNS che cause PERMERRORs con severe validatori SPF, e la validazione del tutto inaffidabile / imprevedibile con i non-severe / validatori male implementati .

È possibile in qualche modo eliminare 3 di quelle include:regole dal record di outlook.com gonfio, ma coprire ancora i server utilizzati da O365?

Modificare:

I commentatori hanno detto che dovremmo semplicemente usare il spf.protection.outlook.comrecord più breve . Mentre questa è una novità per me, ed è più breve, è solo un record in meno:

spf.protection.outlook.com
  include:spf-a.outlook.com
  include:spf-b.outlook.com
  include:spf-c.outlook.com
  include:spf.messaging.microsoft.com
    include:spfa.frontbridge.com
    include:spfb.frontbridge.com
    include:spfc.frontbridge.com

Edit²

Suppongo che possiamo tecnicamente ridurre questo a:

v=spf1 a mx include:_spf1.mydomain.com include:_spf2.mydomain.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com ~all

ma i potenziali problemi che vedo con questo sono:

Dobbiamo tenerci aggiornati su eventuali modifiche al genitore spf.protection.outlook.come ai spf.messaging.microsoft.comregistri. Se qualcosa viene cambiato o [dio vietato] dovremmo aggiornare manualmente il nostro per riflettere ciò.
Con il nostro nome di dominio effettivo la lunghezza del record è di 260 caratteri, il che richiederebbe 2 stringhe per il record TXT, e onestamente non mi fido che tutti i client DNS e i risolutori SPF là fuori accetteranno correttamente un record TXT più lungo di 255 byte .

email spf microsoft-office-365

— Sammitch
fonte

Non puoi semplicemente aggiungere spf.protection.outlook.com per tutto Office365? technet.microsoft.com/en-us/library/hh852557.aspx

— Cold T

Perché il record SPF per O365 non è quello attuale semplice? include:spf.protection.outlook.com (curioso a dire il vero, non hai mai visto cosa hai impostato ... il portale ti ha detto di mettere tutto questo?)

— TheCleaner

Tutta la documentazione che ho trovato diceva di usare include:outlook.com, quindi anche le spf.protection.outlook.comnotizie per me. Il problema rimane però, dal momento che quel record richiede ancora 8 ricerche e devo ridurlo a 6 o meno.

— Sammitch,

Non dimenticare di contare le due ricerche PTR in "spfa.frontbridge.com". Secondo RFC 7208 contano anche per il limite di 10 ricerche. :(

— Martijn Heemels,

Risposte:

A partire da qualche data recente, Microsoft ha "risolto" questo problema eliminando tutti i record secondari e utilizzando invece 2 o 3 record "ptr":

$ dig TXT spf.protection.outlook.com
spf.protection.outlook.com. IN  TXT "v=spf1 ptr:protection.outlook.com ptr:o365filtering.com -all"

$ dig TXT spf.messaging.microsoft.com
spf.messaging.microsoft.com. IN TXT "v=spf1 ptr:protection.outlook.com ptr:messaging.microsoft.com ptr:o365filtering.com -all"

Ecco il problema: mentre questo aiuterà i client di Office 365 a non rimanere sotto il PermError "Troppe ricerche" ... lo fa costringendo tutti i server di posta al mondo a fare (costose) ricerche PTR per ogni indirizzo IP che si connette a loro.

Secondo la specifica SPF :

Se possibile, dovresti evitare di usare questo meccanismo nel tuo record SPF, perché si tradurrà in un numero maggiore di costose ricerche DNS.

— John Hart
fonte

@ChrisS - Ci ho pensato anche io, tuttavia la specifica SPF afferma che il meccanismo "ptr:" deve essere verificato in entrambi i modi per DNS reciproco - il mailserver ricevente dovrebbe prima fare un PTR sull'IP, quindi fare A su il nome host risultante e l'IP devono essere elencati nel record A. Quindi non penso che sia un buco nella sicurezza, almeno non per le implementazioni SPF conformi.

— John Hart,

Ah, buona scoperta lì. Non ero a conoscenza dell'avvertimento.

— Chris S,

Abbiamo riscontrato anche questo problema. Microsoft ti sta "incoraggiando" a utilizzare Office 365 esclusivamente per la tua e-mail poiché non c'è più spazio per aggiungere nuovi elementi.

Il modo in cui lo aggiravamo era duplice.

Innanzitutto, possiamo ridurre le ricerche DNS aggiungendo le altre voci come voci esplicite IPv4. Questo ci consente di aggiungere un numero di IP espliciti prima di noiinclude:outlook.com

In secondo luogo, abbiamo creato un sottodominio separato nel nostro dominio principale per le cose di Office 365. In questo modo, email @ foo.company.com ottiene l'SPF di Office 365 e email @ comapny.com ottiene il nostro SPF normale. Non è perfetto, ma fortunatamente i luoghi in cui abbiamo utilizzato Office 365 sono tutti in grado di utilizzare gli indirizzi e-mail all'interno del sottodominio anziché nel dominio di base.

— Steve Shipway
fonte