Un piè di pagina può trasformare un messaggio in uscita firmato correttamente in un file DKIM fallimento. La riparazione inizia con la sequenza di elaborazione: identificare quale sistema ha firmato il messaggio, quale sistema ha inserito il piè di pagina e quale firma ha valutato il destinatario. La pubblicazione di un'altra chiave DNS non può comportare l'aggiunta di un testo di copertina della firma dopo la sua creazione.
Dimostrare quali byte sono cambiati
Salva un messaggio controllato immediatamente dopo la firma e un altro dopo il gateway, utilizzando l'esportazione del messaggio non elaborato anziché il testo copiato da un client di posta. Conserva i file originali. Registra i tag d, s, c, h e qualsiasi l di ciascuna firma. Un messaggio può avere più firme con copertura e risultati diversi.
DKIM calcola un hash del corpo canonicalizzato. Sotto la normale copertura completa, un nuovo piè di pagina aggiunge contenuto sostanziale e modifica l'hash. Corpo rilassato canonicalizzazione rimuove alcune differenze di spazi bianchi; non rimuove una dichiarazione di non responsabilità, un blocco HTML o una nuova parte MIME . Una mancata corrispondenza dell'hash del corpo riguarda gli input e i valori dell'hash del corpo confrontati: la rappresentazione del corpo, le impostazioni c/l e il valore bh. Anche un bh danneggiato o generato in modo errato o un errore di implementazione del firmatario/verificatore possono spiegare una mancata corrispondenza. Il confronto dentro RFC 6376 sezione 6.1.3 di per sé non prova che una porta abbia cambiato il corpo. Un errore generale della firma può invece coinvolgere un'intestazione firmata, una ricerca della chiave o la sintassi della firma. RFC 6376 §3.4, RFC 6376 §3.7 E RFC 6376 §6.1 descrivere questi controlli separati.
Confronta i campioni al confine in cui è applicato il piè di pagina. Ispeziona sia le parti text/plain che text/html, i confini MIME e la codifica di trasferimento. Un piè di pagina visibile apparentemente identico può essere serializzato in modo diverso. Se anche il gateway cambia Oggetto, controlla se l'Oggetto è elencato in h: riparare solo il corpo non ripristinerà una firma su un'intestazione modificata.
Prova l'ordine piuttosto che indovinare
Scenario illustrativo: un'applicazione crea una fattura, il server in uscita la firma e un gateway aggiunge quindi un avviso legale. Il destinatario segnala una mancata corrispondenza dell'hash del corpo per la firma dell'applicazione. In un'alternativa controllata, il gateway aggiunge prima l'avviso e un firmatario autorizzato firma il messaggio serializzato finale. Un risultato positivo su quel secondo percorso supporta la diagnosi dell'ordine. Queste sono osservazioni di test proposte, non risultati di un vero inquilino.
Utilizza le stesse varianti del messaggio in entrambi i percorsi, inclusi HTML, testo normale e un allegato. L'autenticazione del destinatario del record risulta da un confine attendibile, dal dominio della firma e dal dominio Da visibile. Il solo passaggio DKIM non è sufficiente per DMARC se la firma passata non è allineata con il dominio dell'autore. Una firma del gateway non correlata può essere verificata correttamente senza fornire il percorso allineato.
Scegli un confine di firma di proprietà
La consueta progettazione durevole consiste nell'eseguire le modifiche necessarie al contenuto prima dell'operazione di firma finale autorizzata. Ciò potrebbe significare spostare il firmatario in un secondo momento, spostare l'inserimento del piè di pagina in anticipo o configurare il gateway per firmare il messaggio finale utilizzando un dominio controllato dall'organizzazione. Conferma il comportamento supportato e la proprietà della chiave prima di selezionare un progetto. Non dare per scontato che ogni gateway supporti la firma del dominio personalizzato.
Se una firma esistente è danneggiata, l'aggiunta di una nuova firma valida non ripara quella precedente. Valutare la nuova firma in base ai suoi meriti e verificare allineamento separatamente. Non abilitare il tag body-length l solo per far scomparire i piè di pagina dal calcolo dell'hash: lascia un suffisso senza segno e crea il compromesso di sicurezza descritto in RFC 6376 §8.2.
Concludere con un controllo di regressione
Conserva un diagramma del percorso che mostri l'ultimo componente che cambia corpo e il firmatario immediatamente successivo. Eseguire nuovamente il test in caso di modifiche alle regole di esclusione della responsabilità, alla riscrittura dell'antivirus o al routing in uscita. Il successo significa che il piè di pagina richiesto è presente, la firma prevista viene verificata, il suo dominio soddisfa la politica di allineamento prevista e i messaggi critici arrivano comunque attraverso il percorso previsto. Mantenere un piano di rollback per la modifica della configurazione senza considerare la rimozione di una notifica legale richiesta come un rimedio automatico.
Utilizzare un record di accettazione della regressione
Per ogni variante sintetica in testo semplice, HTML e allegati, registrare: footer presente; ultimo salto che cambia corpo; d/s firmatario finale; selezionato c/h/l; risultato del ricevitore attendibile; Dominio Autore e allineamento; e il risultato della rotta commerciale. Se manca il piè di pagina, il requisito dell'avviso non è soddisfatto anche quando viene superato DKIM . Se il piè di pagina è presente ma passa solo un dominio gateway non correlato, il requisito di allineamento DKIM previsto non viene soddisfatto. Questi sono criteri di accettazione, non controlli completati.