IL SPF I meccanismi a e mx autorizzano gli indirizzi scoperti tramite DNS . Possono ridurre la manutenzione manuale degli indirizzi, ma associano anche l'autorizzazione in uscita ai record conservati per altri lavori. Una migrazione del sito web o una modifica della posta in entrata può quindi alterare SPF senza che nessuno modifichi il file Registro SPF si.
La domanda giusta non è se questi meccanismi siano validi. Indica se la dipendenza DNS esprime la politica di invio prevista.
Ciò che effettivamente valuta
Il meccanismo risolve il nome di destinazione selezionato negli indirizzi appropriati per la famiglia di connessioni SMTP . Utilizza A per una connessione IPv4 e AAAA per IPv6 nativo; IPv6 mappato su IPv6 viene trattato come IPv4 in RFC 7208 §5. Nonostante il nome, a non si limita a IPv4 . Se un obiettivo viene omesso, viene utilizzato il dominio di valutazione SPF corrente.
Con a:mail.example.com, un indirizzo corrispondente può passare sotto il qualificatore predefinito +. Con nudo a su example.com , gli indirizzi di example.com diventano rilevanti. Se quel nome punta a un host di sito Web o a una rete CDN, chiedi perché tali indirizzi dovrebbero essere autorizzati a inviare posta per l'identità valutata. La semantica appare in RFC 7208 sezione 5.3.
Ciò che mx valuta effettivamente
Il meccanismo mx recupera gli host MX per il dominio di destinazione e quindi i loro indirizzi. Confronta l'IP di connessione con gli indirizzi risolti. Record MX normalmente descrivono il routing in entrata, ma i server in entrata non sono necessariamente gli stessi sistemi che inviano la posta in uscita.
SPF mx non utilizza il fallback implicit-MX di SMTP . Se la destinazione non dispone di record MX , SPF non deve trattare i relativi record A o AAAA come host MX fallback. Questa distinzione è esplicita in RFC 7208 sezione 5.4.
Esempio realizzato: due dipendenze, autorizzazioni diverse
Presupponendo una singola politica SPF valida, risposte DNS corrette, prefissi host predefiniti e nessun errore di valutazione precedente, questa politica sintetica è v=spf1 a:out.example.com mx:example.com -all. Supponiamo che out.example.com si risolva in A 192.0.2.40 . L' MX di example.com è inbound.example.com , di cui Un record è 198.51.100.12 .
Una connessione da 192.0.2.40 corrisponde a. Una connessione da 198.51.100.12 manca a, quindi corrisponde a mx. Una connessione da 203.0.113.18 manca entrambi e raggiunge il fail. Se l'host MX in entrata cambia, la seconda autorizzazione può cambiare nonostante l' SPF registrazione TXT rimane identico.
Per una connessione IPv6 , controlla le risposte AAAA pertinenti invece di riutilizzare la traccia IPv4 . Se una destinazione è assente o non restituisce alcun indirizzo applicabile, distinguere la condizione di mancata corrispondenza da un errore DNS ; un timeout non è una prova che l'host previsto non sia autorizzato.
Esaminare il lavoro di ricerca e i limiti secondari
Entrambi i meccanismi contribuiscono al limite di dieci termini che causano query DNS quando valutati. L'espansione MX prevede inoltre limiti aggiuntivi per le query degli indirizzi definiti in RFC 7208 §4.6.4. Una politica può non rispettare questi limiti anche quando un conteggio superficiale dei termini di alto livello sembra accettabile.
Cattura il set di risposte MX e le successive ricerche di indirizzi nelle prove del test. Non considerare dieci come una garanzia che ogni record con dieci parole visibili sia sicuro. Dipendenze ricorsive, espansione e ricerche nulle necessitano di una propria valutazione.
Decidere se mantenere la dipendenza
Mantieni un o mx quando il proprietario del dominio desidera intenzionalmente che il record DNS governi l'autorizzazione di invio e i team operativi comprendano l'accoppiamento. Prendere in considerazione meccanismi ip4/ip6 espliciti per un'uscita dedicata stabile o un'inclusione supportata dal provider quando il provider mantiene l'infrastruttura in uscita.
Prima di rimuovere una dipendenza, identificare quali indirizzi legittimi attualmente la corrispondono. Un mx apparentemente non necessario può essere l'unica autorizzazione per un relè utilizzato raramente. Crea la sostituzione, confronta i set di autorizzazioni e verifica i messaggi rappresentativi prima di eliminare il vecchio termine.
Il pratico takeaway
Un meccanismo a o mx trasforma un'altra modifica DNS in una modifica dell'autorizzazione SPF . Rendi tale relazione intenzionale, visibile ai relativi proprietari e coperta da test.
Registrare la decisione e i suoi limiti
Mantieni una riga di dipendenza per out.example.com e un'altra per ciascun host MX : proprietario DNS , famiglia di indirizzi, risposta osservata e servizio legittimo che lo utilizza. Una migrazione del provider in entrata dovrebbe attivare la revisione della riga MX anche se TXT è invariato. I risultati del campione sono analitici; le prove reali devono includere timestamp delle risposte ed errori del terminale, nonché corrispondenze.