Un analizzatore di intestazione può non essere d'accordo con il ricevitore originale senza che nessuna delle due osservazioni venga fabbricata. Potrebbero aver valutato byte di messaggio diversi, stato della chiave DNS diverso o policy di verifica diverse in momenti diversi. Conservare le prove originali e confrontare le condizioni prima di decidere cosa significhi il disaccordo.
Un risultato storico visualizzato e una nuova verifica crittografica sono operazioni diverse. Alcuni strumenti riassumono Authentication-Results già presente nel campione. Altri recuperano le chiavi e verificano il campione attuale. Stabilire quale operazione esegue l'analizzatore prima di confrontare il suo output con il risultato del sistema ricevente.
Conservare l'originale e identificarne il confine
Esporta il messaggio non elaborato utilizzando un metodo che preservi la rappresentazione del messaggio. Conserva un originale non modificato e calcola un hash del file per un confronto successivo. Registra il metodo di raccolta, i tempi di consegna e la casella di posta di origine. Un hash di file può mostrare che due file esportati differiscono; non spiega di per sé a quale differenza importi DKIM.
Identificare i Authentication-Results generati dal destinatario e il relativo ID authserv attendibile. Le intestazioni fornite da un mittente non attendibile non costituiscono una prova autorevole del destinatario. RFC 8601 §7.1 descrive questo confine di fiducia. Determina inoltre se il destinatario ha valutato il messaggio prima che un gateway successivo o un processo di esportazione lo modificassero.
Confrontare gli input effettivi dell'analizzatore
Per una normale firma completa del corpo, un blocco di intestazione copiato omette il corpo necessario per ricalcolare il suo DKIM hash del corpo. Il caso speciale l=0 esegue l'hashing di zero ottetti body e non fornisce alcuna protezione dell'integrità del corpo; non rinuncia a controlli di intestazione, chiave o altri controlli di verifica. Vedere RFC 6376 §3.5, §3.7 E §5.4.1. Incollare il testo può anche modificare la piegatura o la fine della riga. Se all'analizzatore manca il messaggio completo, potrebbe interpretare i risultati riportati anziché verificare in modo indipendente l'intera firma. La sua etichetta di interfaccia da sola non risolve questa domanda.
Confronta i campioni completi quando disponibili. DKIM canonicalizzazione In RFC 6376 §3.4 tollera trasformazioni specificate, non equivalenze arbitrarie del contenuto visualizzato. Un hash di file diverso non significa automaticamente un errore DKIM , poiché alcune modifiche ai byte potrebbero normalizzarsi; un hash di file identico stabilisce solo byte forniti identici, non DNS o contesto di policy identici.
Controlla cosa è cambiato nel DNS e nell'ora
Leggi d e s per ciascuna firma e registra le risposte chiave osservate durante il controllo successivo. La chiave originale potrebbe essere stata ritirata, revocata o sostituita dal momento della consegna. RFC 6376 §6.1.2 la verifica si basa sul recupero di materiale di verifica appropriato, quindi un passaggio storico può coesistere con un risultato successivo senza chiave.
Ispeziona anche eventuali valori x di scadenza della firma e la gestione del tempo da parte del verificatore. Uno strumento successivo potrebbe valutare dopo la scadenza della firma. RFC 6376 §6.1.1 consente ai verificatori di ignorare le firme scadute; il comportamento di uno strumento specifico deve essere verificato anziché ipotizzato. Non etichettare tale risultato come prova che la firma era scaduta nel momento in cui il destinatario l'ha originariamente elaborata. Laddove la vecchia risposta DNS non sia disponibile, dichiarare che il calcolo crittografico storico non può essere completamente riprodotto dalle prove attuali.
Analizza due esempi contrastanti
Esempio illustrativo uno: il destinatario riferisce di passare selettore old1 lunedì e il mittente ritira old1 venerdì. Un ricontrollo effettuato sabato non riporta alcuna chiave. Quel risultato successivo non cancella l'osservazione attendibile di lunedì, sebbene la riproduzione indipendente della verifica di lunedì richieda input storici rilevanti.
Esempio illustrativo due: il file originale ricevuto viene verificato, mentre una copia incollata fallisce dopo la modifica di un piè di pagina o della serializzazione MIME . Confronta la rappresentazione coperta e il punto in cui è avvenuta la modifica. Il problema potrebbe risiedere nella gestione del campione piuttosto che nella firma originale del mittente. Questi sono strumenti di confronto, non affermazioni su un vero analizzatore o inquilino.
Segnala il disaccordo in modo preciso
Crea un record di confronto contenente hash campione, metodi di raccolta, tempi di osservazione, d e s, risposte chiave, versioni del verificatore, risultati riportati e differenze di policy note. Esamina più firme separatamente, poiché gli strumenti potrebbero evidenziarne di diverse. Mantieni la validità DKIM distinta da DMARC allineamento e consegna finale.
Concludi solo ciò che le prove supportano: byte diversi, DNS modificato, validità scaduta, firma selezionata diversa o contesto irrisolto. Preservare l’incertezza quando mancano gli input originali. Un analizzatore successivo costituisce un'utile prova diagnostica, ma non è una macchina del tempo e non dovrebbe sovrascrivere silenziosamente il risultato attendibile del ricevitore originale.
Prove necessarie per la prossima decisione
Utilizzare una riga di confronto per ciascuna firma: hash/ora del campione originale, hash/ora del campione successivo, d/s, chiave osservata, x se presente, strumento/versione, operazione (analisi o verifica del report), risultato e gap rimanente. Byte campione identici con DNS storico non disponibile lasciano un divario nello stato chiave, non la prova che uno degli strumenti sia sbagliato. Se i campioni differiscono, confrontare la rappresentazione canonica coperta prima di assegnare la causalità.