Crea da mittenti approvati, non da un elenco di fornitori indovinato
UN SPF Il builder dovrebbe preservare le decisioni esplicite dell'organizzazione su quali sistemi possono utilizzare una particolare identità SMTP . Un elenco conveniente di fornitori popolari non può stabilire che tali servizi siano autorizzati per il dominio, che il meccanismo consigliato sia aggiornato o che il record risultante rispetti i limiti di ricerca. L'output dovrebbe essere una proposta commentata legata alla proprietà del mittente, non un'ampia autorizzazione raccolta dal riconoscimento del marchio.
RFC 7208 definisce la pubblicazione e la valutazione SPF . Questo articolo propone i requisiti per un costruttore e il suo processo di revisione. Non afferma che EmailAuth offra alcuna particolare funzionalità di creazione, generi un record di produzione o modifichi DNS . Nessun account fornitore, credenziale privata o record del dominio utente è stato ispezionato. L'output originale e le prove del test rimangono aperti.
Inventariare l'identità e il proprietario effettivi SMTP
Per ciascun flusso di lavoro, registrare lo scopo commerciale, il proprietario del servizio approvato, il servizio di invio e la pertinenza MAIL DA O Identità HELO e la fonte dell'autorizzazione proposta. SPF non autentica direttamente il nome visualizzato Da visibile. Un fornitore utilizzato da un team non deve essere aggiunto automaticamente a tutti dominio organizzativo. L'identità prevista e il rapporto di servizio necessitano di una conferma esplicita da parte del proprietario responsabile.
RFC 9989 definisce il allineamento relazione necessaria affinché SPF possa contribuire DMARC. Un costruttore dovrebbe spiegare che l'autorizzazione SPF e l'allineamento DMARC sono decisioni correlate ma separate. Aggiunta di un provider a un file Registro SPF non garantisce che il fornitore utilizzi tale identità nella posta reale. Il proprietario dell'integrazione deve fornire la configurazione corrente e la prova del messaggio autorizzato durante la verifica del flusso di lavoro.
Utilizza le istruzioni attuali del fornitore senza espandere l'ambito
L'esatto target di inclusione o intervallo di indirizzi dovrebbe provenire dalla documentazione ufficiale corrente o dalla configurazione autorizzata per il servizio effettivo. Non dedurlo dal record di un altro cliente, da un vecchio tutorial o da un prodotto con un nome simile. Registrare la data di prova e il proprietario responsabile del monitoraggio delle modifiche del fornitore. Questo manoscritto non inventa valori di inclusione del provider perché nessuna configurazione specifica del mittente è stata approvata per la costruzione.
I meccanismi di IP diretto e le dipendenze delegate comportano obblighi di manutenzione diversi. Gli indirizzi statici possono evitare lo stesso budget per i termini di ricerca dei meccanismi che causano query DNS, ma copiando gli indirizzi attuali di un provider in un record può diventare obsoleto quando il fornitore cambia infrastruttura. Un costruttore non dovrebbe appiattire silenziosamente le dipendenze come ottimizzazione senza un modello di manutenzione approvato. Conserva il compromesso e la decisione del proprietario nell'annotazione.
Produrre una politica SPF coerente
RFC 7208 richiede un singolo record SPF per l'identità valutata; pubblicare più record SPF non è un modo valido per combinare più servizi. La modifica proposta dovrebbe pertanto descrivere il modo in cui i mittenti autorizzati esistenti vengono preservati in un’unica politica coerente. Non dovrebbe semplicemente istruire l'operatore ad aggiungere un altro record v=spf1 accanto a uno esistente. Non correlato Record TXT non deve essere rimosso come effetto collaterale.
RFC 1035 definisce la struttura dei record TXT . Più stringhe di caratteri all'interno di un record TXT sono distinte da più record TXT , quindi i dispositivi di visualizzazione e test del costruttore dovrebbero mantenere tale differenza. Un editor può formattare un valore lungo in modo diverso dalla sua rappresentazione wire. La differenza esatta approvata dovrebbe specificare il set di record previsto anziché fare affidamento su uno screenshot di un singolo campo.
Spiegare meccanismi, qualificatori e modificatori
Ogni termine generato dovrebbe avere un proprietario e una motivazione. Includere ai delegati una valutazione secondo la mappatura dei risultati dello standard; il reindirizzamento è un modificatore con semantica diversa e viene ignorato se è presente qualsiasi meccanismo. Un costruttore non dovrebbe scambiarli solo perché entrambi fanno riferimento a un altro dominio. I qualificatori influenzano il risultato associato a un meccanismo di corrispondenza e dovrebbero essere selezionati attraverso una decisione politica esplicita.
Non lasciare intendere che l'aggiunta di tutto renda sicura ogni configurazione. La questione del posizionamento e delle qualificazioni e un'autorizzazione eccessivamente ampia possono superare il confine previsto. Al contrario, una fine restrittiva può influenzare i mittenti legittimi che sono stati omessi dall'inventario. Il costruttore dovrebbe far emergere i flussi di lavoro irrisolti e richiedere l'approvazione prima della pubblicazione piuttosto che scegliere automaticamente una posizione di rischio aziendale da un modello.
Controlla i limiti di valutazione senza confondere il conteggio
La sezione 4.6.4 RFC 7208 limita i termini valutati che causano query DNS come include, a, mx, ptr, esiste e reindirizza a dieci. Questo non è un limite di dieci nomi di provider visibili o di dieci pacchetti grezzi. Le dipendenze nidificate e il percorso di corrispondenza effettivo sono importanti. Il costruttore dovrebbe fornire una revisione delle dipendenze e identificare ciò che non ha valutato, piuttosto che certificare ogni possibile input da un conteggio superficiale.
Lo standard raccomanda inoltre un limite di due ricerche di vuoto con comportamento configurabile e definisce limiti aggiuntivi per meccanismi specifici. L'output statico di un generatore non stabilisce come tutti i ricevitori valuteranno ogni percorso nel futuro stato DNS . Mantieni i test del percorso separati dai test di formattazione. Un costruttore può spiegare le probabili dipendenze senza affermare che un controllo sintattico riuscito dimostri il successo universale SPF .
Un foglio di lavoro di output che preserva la proprietà
Crea un foglio di lavoro con dominio di identità, flusso di lavoro, proprietario dell'azienda, proprietario tecnico, prova del mittente approvato, termine proposto, motivazione e responsabilità di manutenzione. Aggiungi il riferimento del record esistente, la differenza esatta prevista, i mittenti non risolti, la revisione del percorso di ricerca, il piano di verifica e i criteri di rollback. L'output dovrebbe spiegare perché esiste ciascuna autorizzazione e chi può approvarne la rimozione o l'espansione.
Il set di test dovrebbe includere una proposta valida positiva, sintassi non valida, record SPF duplicati e casi con termini non supportati. Distinguere i meccanismi sconosciuti dai modificatori sconosciuti perché RFC 7208 li tratta in modo diverso. La formulazione del catalogo richiede casi di tag non supportati; per SPF , associare esplicitamente tale requisito al meccanismo del protocollo e al vocabolario dei modificatori anziché inventare un parser di tag generico. Per questa bozza non è stato eseguito alcun test di questo tipo.
Diagnosi fittizia: un vecchio fornitore resta autorizzato
Un'organizzazione immaginaria chiede a un costruttore di aggiungere un nuovo servizio di posta. Anche il suo record attuale fa riferimento a un fornitore in pensione, ma nessuno ha documentato se un altro flusso di lavoro utilizza ancora tale dipendenza. Un costruttore semplicistico unisce il nuovo termine e preserva tutto il resto senza spiegazioni. La proposta revisione consapevole della proprietà segna invece la vecchia autorizzazione come irrisolta e chiede ai proprietari aziendali e tecnici responsabili di determinarne lo stato.
Il team non eliminerebbe il vecchio termine semplicemente per ridurre il conteggio, né aggiungerebbe il nuovo fornitore a identità non correlate. Preparerebbe una modifica approvata esatta dopo aver risolto la dipendenza e pianificato la verifica rappresentativa. Si tratta di un esercizio fittizio sul ciclo di vita, non di un record osservato, del ritiro di un fornitore o di una modifica DNS completata. Illustra perché la proprietà del mittente fa parte della costruzione del record piuttosto che della documentazione amministrativa successiva.
Verificare il flusso di lavoro previsto prima di dichiarare il completamento
Dopo una pubblicazione autorizzata, il team operativo conserverebbe le esatte osservazioni DNS e le prove rappresentative attendibili dei messaggi ricevuti per ciascun flusso di lavoro pertinente. Tali osservazioni devono mostrare l'identità e l'allineamento effettivi, non semplicemente il fatto che la stringa generata appaia in un editor. Un campione riuscito rimane limitato al mittente, all'ora e al destinatario; non stabilisce il risultato di ogni messaggio futuro.
Il catalogo richiede un record annotato e casi di test positivi, non validi, duplicati e con tag non supportati. Quei manufatti originali rimangono aperti. Rimangono aperti anche la revisione da parte di specialisti umani, l’applicabilità della fonte, i percorsi di produzione, l’accessibilità e il rilascio del proprietario. Questa bozza fornisce un foglio di lavoro proposto e una diagnosi fittizia, non una politica di produzione generata, una suite di test eseguita o una richiesta di funzionalità EmailAuth verificata.