Appiattimento SPF è un modo per sostituire alcune autorizzazioni dipendenti dal DNS con intervalli di indirizzi espliciti. Può rendere una valutazione meno dipendente dalle ricerche nidificate. Può anche lasciarti mantenere una copia della rete in evoluzione di qualcun altro. Una decisione utile quindi confronta il record proposto e il processo che lo manterrà corretto.
Stabilire il vincolo effettivo
Inizia con l'esatto dominio della busta utilizzato dall'applicazione interessata, non semplicemente con il dominio del sito web dell'azienda. Raccogliere il presente documento, le sue dipendenze e gli indirizzi di invio dei rappresentanti. Esegui una valutazione basata sugli standard con tali input e conserva la traccia. Un'etichetta che dice "troppe ricerche" non è sufficiente per decidere cosa sostituire.
RFC 7208 sezione 4.6.4 limita la valutazione dei termini dipendenti dal DNS a livello globale attraverso la ricorsione. I meccanismi espliciti ip4 e ip6 sono fuori budget. Questo è il potenziale vantaggio della ricerca; non è una promessa che ogni record appiattito sia piccolo, corretto o veloce.
Per prima cosa rimuovere le autorizzazioni i cui titolari delle attività commerciali confermano che sono obsolete. Verifica se un'applicazione distinta può utilizzare un sottodominio della busta opportunamente configurato. Né la pulizia né la segmentazione dovrebbero essere eseguite alla cieca: elencare i messaggi interessati e verificare che il provider supporti l'identità proposta. Usa il inventario del mittente per connettersi un record accesso ad un vero e proprio servizio.
Confronta il significato, non solo gli elenchi di indirizzi
Sotto RFC 7208 §5.2, un'inclusione è una valutazione di un'altra politica, non un file di testo delle reti da copiare. Qualificatori, ordine, include nidificate, reindirizzamento e macro possono influenzarne il risultato. Un convertitore deve preservare l'autorizzazione prevista per gli input supportati o dichiarare esplicitamente ciò che non può rappresentare. Rifiuta una conversione che raccoglie semplicemente ogni valore dall'aspetto IP da un albero.
Per ciascuna sostituzione proposta, chiedere quale politica upstream rappresenta, quali input sono stati testati, se è coperto IPv6 e come vengono rilevate le modifiche. Conserva la dipendenza originale e la documentazione del provider accanto all'output generato. Evitare di ampliare le reti adiacenti in un intervallo più ampio semplicemente per abbreviare il testo, a meno che l'intero intervallo non sia autorizzato in modo indipendente.
Rendi visibili i costi di manutenzione
Si tratta di una decisione illustrativa, non di una distribuzione testata. Un mittente della fatturazione fa riferimento a una policy del fornitore che attualmente autorizza due intervalli. Una copia appiattita contiene tali intervalli. Domani il provider ne aggiungerà un terzo. La dipendenza originaria può esporre la nuova autorizzazione tramite DNS ; la copia non lo conterrà finché un aggiornamento riuscito non pubblicherà un aggiornamento. Il problema inverso si verifica quando il provider ritira un intervallo ma la copia lo conserva.
Assegnare a qualcuno la gestione dell'aggiornamento, degli aggiornamenti non riusciti, delle modifiche di grandi dimensioni impreviste e del ripristino di emergenza. Richiedi un avviso quando il processo di generazione si interrompe, anziché solo quando il record pubblicato è sintatticamente valido. Un record obsoleto valido può ancora essere il record sbagliato.
Testare un candidato prima della sostituzione
Conserva il record precedente e produci un'esplicita differenza prima e dopo. Testa i mittenti conosciuti, un indirizzo non autorizzato, ciascuna famiglia IP rilevante e il risultato finale di non corrispondenza. Esamina la risposta TXT effettiva, comprese le dimensioni e i limiti della stringa. RFC 7208 §3.3 E RFC 7208 §3.4 spiegare perché la suddivisione di un valore TXT in stringhe di caratteri non elimina la necessità di gestire la risposta DNS complessiva.
Utilizzare un test di invio controllato dopo la pubblicazione approvata. Registra il risultato dell'autenticazione del sistema ricevente e l'identità della busta valutata. Non equiparare an SPF miglioramento con DMARC allineamento o posizionamento garantito nella casella di posta.
Scegli un modello operativo che puoi sostenere
Mantenere la politica basata sulla dipendenza quando la sua valutazione è accettabile e la sua proprietà continua è più chiara. Prendi in considerazione l'appiattimento solo con una copertura semantica dimostrata, un meccanismo di aggiornamento affidabile, avvisi e un piano di uscita. Un numero inferiore di ricerche costituisce una prova utile, ma non costituisce l'intera decisione di accettazione. Per la manutenzione dopo l'adozione, continuare con SPF appiattito e stantio.
Registra la decisione successiva
Per una conversione ipotetica, elencare i costrutti upstream supportati, l'ora dell'istantanea di origine, le identità/IP testati, i risultati del terminale previsti e chi rileva gli intervalli aggiunti o ritirati. Se un'autorizzazione macro-dipendente non può essere rappresentata per gli input previsti, il candidato non è pronto semplicemente perché il numero di ricerche è inferiore. Per questo articolo non è stata eseguita alcuna conversione, modifica DNS o test di invio.