[ Inoltro e ARC ]

DKIM e inoltro: identifica le modifiche ai messaggi

Individua la trasformazione che invalida DKIM , separando la canonicalizzazione, la copertura del corpo e il posizionamento del firmatario.

A cura del team di ricerca EmailAuth · 4 minuti di lettura

[ Punti chiave ]

  • Confronta i byte firmati grezzi e i parametri della firma prima di incolpare una trasformazione.
  • La canonicalizzazione rilassata non consente modifiche arbitrarie ai contenuti.
  • Preferire l'ordine di firma corretto rispetto a una copertura della firma indebolita.
In questa pagina

Un messaggio che viene verificato prima dell'inoltro e successivamente fallisce richiede un confronto tra i byte firmati e il contesto della firma. Non dare per scontato che ogni intestazione aggiunta si rompa DKIM o quello rilassato canonicalizzazione consente modifiche arbitrarie. La firma identifica i campi di intestazione protetti, la canonicalizzazione e hash del corpo. Ricostruire quelle scelte prima di decidere quale trasformazione conta.

Conservare artefatti comparabili

Riferimenti: RFC 6376 §3.5, RFC 6376 §3.7.

Conserva il messaggio originale e finale non elaborato senza aprirlo e salvarlo nuovamente tramite un client che può normalizzare le terminazioni di riga o ricodificare MIME . Registra il dominio del firmatario, selettore, algoritmo, elenco di intestazioni firmate, canonicalizzazione ed eventuali limiti di lunghezza del corpo. Mantieni l'output del verificatore e l'osservazione della chiave DNS con il timestamp. Un messaggio visivamente identico può avere byte codificati diversi.

Trova il firmatario nella catena di elaborazione. Un piè di pagina aggiunto prima della firma finale fa parte del contenuto firmato; lo stesso piè di pagina aggiunto dopo la firma può invalidare l'hash del corpo. Elenco di inventario software, gateway, motori di esclusione della responsabilità, riscrittori antivirus e percorsi di archiviazione come possibili punti di trasformazione. Solo le prove del percorso reale possono identificare chi ha agito.

Comprendere cosa consente la canonicalizzazione

Riferimenti: RFC 6376 §3.4, RFC 6376 §5.4, RFC 6376 §8.2.

RFC 6376, sezione 3.4, definisce una canonicalizzazione semplice e rilassata. L'elaborazione rilassata del corpo normalizza gli spazi bianchi specificati e le righe vuote finali. Non fa scomparire un paragrafo aggiunto o un importo modificato. La canonicalizzazione dell'intestazione ha le proprie regole e non dovrebbe essere sostituita da regole del corpo.

Un prefisso Oggetto influisce su una firma che copre il campo Oggetto pertinente. La semplice aggiunta di un'intestazione senza segno non correlata è un caso diverso. I campi firmati duplicati e la selezione dell'intestazione richiedono le regole del verificatore, non una differenza visiva casuale. Laddove una firma includa un limite di lunghezza del corpo, comprendere il rischio di contenuto scoperto; non introdurre questa opzione come un modo conveniente per rendere sicuri i piè di pagina arbitrari.

Esegui un confronto tra l'hash del corpo reale

Riferimenti: RFC 6376 §3.4.4.

L'apparecchio locale applica la canonicalizzazione del corpo rilassato a tre corpi sintetici. Calcola SHA-256 e base64 per l'originale, una variazione con soli spazi bianchi e una versione aggiunta al piè di pagina. I casi originali e quelli degli spazi bianchi corrispondono; il caso del piè di pagina è diverso. I file .eml originali e modificati generati conservano i byte del corpo illustrativo per l'ispezione.

Questa è una trasformazione dell'hash osservata, non un Firma DKIM verifica. Non sono coinvolte chiavi di firma private, ricerche di chiavi DNS , firme di intestazioni o servizi di ricezione attendibili. L'effetto previsto su una firma completa rimane condizionato dalla firma effettiva che copre i byte modificati. Le prove conservate di seguito registrano la firma locale storica e la verifica prima e dopo; le prove del percorso di produzione rimangono non raccolte.

Correggere l'ordine prima di indebolire la copertura

Riferimenti: RFC 9989 §4.4.1, RFC 9989 §5.3.5.

Ove possibile, applica le trasformazioni richieste prima della fase finale di firma del dominio legittimo. Per un intermediario che non può firmare per l'autore originale, la conservazione del contenuto originale firmato può mantenere un passaggio allineato. Una firma sostitutiva dell'intermediario autentica il proprio dominio e non viene automaticamente allineata all'indirizzo del mittente originale. RFC 9989 fornisce quel confronto separato.

Testare nuovamente la stessa trasformazione con il verificatore completo e il contenuto MIME rappresentativo. Include allegati, alternative in più parti e messaggi non ASCII se rientrano nell'ambito. Conservare i controlli negativi in ​​modo che un test non possa avere successo semplicemente perché la firma è scomparsa. La chiusura dovrebbe indicare quale trasformazione è cambiata, quale firma ora convalida e se tale firma fornisce un'autenticazione allineata al destinatario finale.

Conservazione delle prove di laboratorio

Riferimenti: RFC 6376 §6.

Nella cattura del 7 novembre 2026, una cattura temporanea 2048 bit La chiave RSA ha firmato i byte originali con dkimpy prima dell'inoltro. Il record DNS pubblico della chiave viene conservato e la chiave privata viene eliminata dopo l'esecuzione. dkimpy verifica i messaggi originali e conservati, inoltrandoli e rifiutando il corpo aggiunto al piè di pagina. Il caso dell'elenco applica le modifiche all'attribuzione e al piè di pagina prima di creare la firma del dominio dell'elenco, che verifica. Si tratta di test di firma DKIM completi e autentici, non di risultati booleani forniti. L'aiutante del corpo rilassato ora gestisce anche l'input vuoto come zero ottetti.

Sono stati ispezionati il ​​corridore trattenuto e la cattura del 7 novembre 2026; nessun esperimento di rete è stato eseguito nuovamente per questa revisione. L'esperimento originale utilizzava solo il loopback e non inviava posta Internet. Il suo ricevitore crea Authentication-Results dai propri controlli, attribuendo a tali campi la nota provenienza di laboratorio. Il risultato e la disposizione dell'autenticazione rimangono separati: tutti e sei i campioni SMTP ne ricevono 250 in base a una politica di acquisizione esplicita, inclusi i campioni non riusciti. Il confine di fiducia è questo laboratorio controllato, non un fornitore di cassette postali di produzione. L'adattatore DNS fornisce risposte fisse conservate anziché interrogare DNS pubblico e il DMARC il valutatore utilizza solo la rigorosa uguaglianza del dominio. L'individuazione completa del dominio organizzativo, l'analisi delle policy di produzione e i risultati della distribuzione in tempo reale non sono ancora stati testati.

[ Porta via ]

Preferire l'ordine di firma corretto rispetto a una copertura della firma indebolita.

[Per ruolo]

Cosa significa questo per te

Scegli il tuo ruolo per i prossimi passi pratici.

Amministratore IT/Posta

Confronta i dati firmati

La somiglianza visiva è insufficiente.

Prossimi passi

  1. Conserva i byte grezzi.
  2. Ispezionare h= e c=.
  3. Esegui la verifica completa dopo la riparazione.

CISO/SecOps

Evitare una copertura indebolita

L'autenticazione dovrebbe proteggere i contenuti significativi.

Prossimi passi

  1. Esamina le eccezioni relative alla lunghezza del corpo.
  2. Conservare i test negativi.
  3. Verificare l'autorità del firmatario allineato.

Fondatore / Non tecnico

Finanzia la riparazione corretta

L'ordine di elaborazione spesso supera i confini del team.

Prossimi passi

  1. Identificare i proprietari della trasformazione.
  2. Dai la priorità ai tipi di messaggi critici.
  3. Richiedere un nuovo test comparabile.

[ Domande frequenti ]

Domande frequenti

Ogni intestazione aggiunta interrompe DKIM ?

No. I campi protetti e le regole di selezione delle intestazioni sono importanti.

RFC 6376 §5.4

La modalità rilassata può tollerare un piè di pagina?

Non generalmente. Normalizza la formattazione specificata, non nuovi contenuti arbitrari.

RFC 6376 §3.4.4

Perché preservare i byte grezzi?

La riserializzazione del client può alterare gli stessi dati analizzati.

RFC 6376 §3.4

Il posizionamento dei firmatari è importante?

SÌ. Una modifica prima della firma differisce dalla stessa modifica successiva.

RFC 6376 §3.7

L'apparecchiatura verifica DKIM ?

La correzione dell'hash del corpo originale non verifica DKIM . Il laboratorio SMTP del 7 novembre 2026 mantenuto ha eseguito una vera verifica della firma dkimpy; questa revisione ricontrolla le firme conservate offline senza ripetere la consegna SMTP .

Dovrebbe l= essere usato come soluzione rapida?

Non di riflesso. Il contenuto aggiunto scoperto introduce considerazioni sulla sicurezza.

RFC 6376 §8.2

La firma dello spedizioniere ripristina l'allineamento dell'autore?

Solo se il suo dominio autenticato è effettivamente allineato; un dominio di inoltro diverso no.

RFC 9989 §4.4.1

Qual è un controllo negativo utile?

Una modifica nota del contenuto firmato che il verificatore completo rifiuta correttamente.

[ Fonti ]

Fonti

  1. RFC 6376

    Sezioni §3.4 · §3.4.4 · §3.5 · §3.7 · §5.4 · §6 · §8.2

  2. RFC 9989

    Sezioni §4.4.1 · §5.3.5

[ Glossario ]

Glossario

Canonicalizzazione
Normalizzazione specifica applicata prima della firma o della verifica.
Hashish corporeo
Digest del corpo del messaggio coperto canonizzato.
Posizionamento del firmatario
Il punto nell'elaborazione del messaggio in cui viene creata una firma.

Provenienza aziendale

Perché le principali istituzioni finanziarie e i governi hanno ritirato le dashboard di sicurezza della posta elettronica.

Le tradizionali piattaforme di autenticazione e-mail ti vendono una dashboard e chiedono ai tuoi ingegneri di fare il lavoro. Negli ambienti ad alto rischio, la supervisione manuale comporta un’applicazione ritardata, deviazioni della configurazione e domini ombra non monitorati.

EmailAuth è la piattaforma di provenienza della posta elettronica degli agenti. I nostri agenti applicano p=reject, mantieni allineati i mittenti di terze parti e sposta i tuoi domini al massimo RFC 9989 conformità, il nuovo standard DMARC , con verificabilità human-in-the-loop.

Governi Grandi imprese Istituti finanziari di primo livello

SaaS · Locazione dedicata · Air-gapped on-premise · Crittografia BYOK

Base di conoscenza