Valutare le prove prima di assegnare la gravità
Una valutazione dello stato del dominio dovrebbe spiegare quali dipendenze di autenticazione sono state controllate, cosa supportano le osservazioni e cosa rimane sconosciuto. Un singolo punteggio può nascondere la differenza tra un mittente di produzione rotto e uno non testato selettore e un problema del sito Web non correlato. Questa è una guida diagnostica e un progetto di valutazione proposto, non uno scanner EmailAuth funzionante. Nessun dominio del cliente è stato interrogato e non viene presentato alcun risultato in tempo reale.
Inizia con l'uso previsto di ciascun dominio: posta attiva dei dipendenti, posta per candidature, marketing, di sola ricezione o deliberatamente non invio. Identificare il titolare dell'attività e i mittenti conosciuti. Lo stesso record mancante può avere conseguenze diverse in contesti diversi e una configurazione che sembra restrittiva può interrompere la posta indiretta legittima. Dai la priorità a un rischio aziendale evidente, non al numero di avvisi colorati che una pagina può visualizzare.
Conservare un'osservazione riproducibile
Per ogni controllo proposto, registra l'esatto nome del dominio o del proprietario, il tipo di query, il tempo di osservazione, il risolutore o il server autorevole, lo stato della risposta e i relativi dati di risposta. Distinguere un'osservazione autorevole da una risposta ricorsiva memorizzata nella cache. RFC 1034 descrive questi ruoli; il pannello di controllo in cui un amministratore modifica un record non è di per sé una prova della risposta ottenuta dal destinatario.
Classificare attentamente i dati mancanti. NXDOMAIN , un nome esistente senza il tipo richiesto, un riferimento, una catena di alias e SERVFAIL non sono intercambiabili. RFC 2308 distingue le risposte negative e il contesto necessario per interpretarle. Una sezione di risposta vuota da sola non dimostra NODATA . Mantieni visibili il timeout e l'errore di risoluzione anziché convertirli in un risultato di configurazione permanente.
Limiti di memorizzazione nella cache e raccolta dei record senza promettere che un particolare ritardo dimostri una convergenza mondiale. Un nuovo tentativo da un risolutore può chiarire un problema temporaneo ma non ricostruisce la visione del ricevitore originale. La valutazione deve preservare l’incertezza quando l’osservazione sottostante è incompleta.
Controlla SPF come politica di autorizzazione valutata
Individuare il SPF politica per l'effettiva identità SPF , non automaticamente il dominio Da visibile. RFC 7208 richiede la selezione dei record e non distingue alcun record da più record corrispondenti. Diverse stringhe all'interno di una registrazione TXT non sono automaticamente diversi Registri SPF. Preservare la struttura del record di risorse quando si spiega una scoperta di sintassi.
Per una valutazione specifica del messaggio, registrare l'IP di connessione e l'identità della busta pertinente, incluso il HELO caso quando applicabile. Controlla i meccanismi valutati e le loro dipendenze DNS . Il limite di dieci ricerche riguarda i termini di query DNS specificati durante la valutazione, inclusa l'elaborazione ricorsiva; non si tratta semplicemente del conteggio di ogni pacchetto DNS o di ogni parola nella policy. Sezione 4.6.4 definisce inoltre ulteriori limiti. Spiegare il percorso fallimentare piuttosto che suggerire un appiattimento indiscriminato dei record.
Distinguere gli errori di policy permanenti dai problemi DNS temporanei e da una policy valida che non autorizza una particolare fonte. Un record sintatticamente valido può comunque omettere un mittente legittimo o autorizzare troppe cose. La proprietà aziendale è necessaria per decidere se una fonte debba essere presente.
Richiedi selettore ed evidenza del messaggio per DKIM
Un nome di dominio da solo non enumera tutti i selettori DKIM in uso. Ottieni i valori del selettore e del dominio di firma dall'evidenza del messaggio autorizzato o da un inventario di mittenti verificati. RFC 6376 spiega l'uso del selettore. Un tentativo fallito di individuare un selettore comune non è la prova che l'intero dominio sia carente DKIM.
Controlla la chiave pubblica e l'algoritmo selezionati negli aggiornamenti applicabili, inclusi RFC 8301. Una chiave pubblicata stabilisce una dipendenza DNS , non che un mittente possieda la chiave privata, firmi il traffico previsto o produca firme che sopravvivono al transito. Ispezionare le effettive prove di verifica lato destinatario quando autorizzate. Proteggi il contenuto dei messaggi e le chiavi private; nessuno dei due appartiene a un rapporto diagnostico pubblico semplicemente per far sembrare un esempio completo.
Valutare DMARC e impatto operativo separatamente
DMARC attuale necessita di un meccanismo di passaggio idoneo allineato con il dominio dell'autore. Il successo SPF e DKIM grezzi può coesistere DMARC fallimento quando i loro domini non si allineano. Registrare la scoperta delle policy e le ipotesi sugli identificatori, in particolare se attuali Passeggiata sull'albero DNS il comportamento e le implementazioni legacy potrebbero differire. Non considerare una stringa di policy come prova che ogni destinatario segue la stessa implementazione.
Dare priorità all’interruzione confermata del traffico legittimo critico, poi alle dipendenze irrisolte con esposizione materiale, quindi al lavoro di igiene a basso impatto. Mantenere visibile la motivazione di gravità proposta. UN p=reject Il record da solo non completa un programma di autenticazione e applicarlo indiscriminatamente può danneggiare i domini generici con flussi di posta indiretta. La gestione del destinatario, la proprietà del mittente e il monitoraggio della continuità necessitano di una revisione separata.
In una valutazione fittizia, receipts.example ha un mittente documentato dell'e-mail di pagamento la cui verifica DKIM osservata fallisce, mentre anche un selezionato selettore inutilizzato non restituisce alcun record. Il primo rilievo merita di essere approfondito perché riguarda un flusso aziendale noto; il secondo rimane inconcludente. Nessuna delle due osservazioni è avvenuta qui. L'esempio illustra come il contesto cambi priorità senza inventare una vera e propria trascrizione diagnostica.
Verificare la correzione e la valutazione stessa
Per ciascun risultato, specificare l'azione proposta, l'approvatore, l'osservazione prevista e la condizione di recupero sicuro. Ripetere il controllo rilevante dopo una correzione autorizzata e confrontare le prove invece di confrontare solo i punteggi. RFC 8601 richiede attenzione al limite di attendibilità delle intestazioni dei risultati dell'autenticazione. Inoltre, l'accettazione SMTP finale non stabilisce il posizionamento della casella di posta, poiché le responsabilità di trasporto sono incluse RFC 5321 chiarire.
Una valutazione operativa necessita di test per input validi, record non validi, alias, risposte negative, fallimenti temporanei, selettori mancanti e casi non supportati, con risultati attesi ed errori spiegati. L'esatto requisito per la messa in servizio rimane aperto: uno strumento funzionante con dispositivi con risultati attesi, input originali, tempo di osservazione ed errori spiegati. Questa guida e la mappa proposta non soddisfano tale tool gate. La pubblicazione come risorsa operativa richiede l'implementazione, osservazioni originali autorizzate e test riproducibili, seguiti dall'approvazione tecnica e del proprietario.