Analizzatore di header email

Cosa può mostrare un header email: e cosa non può mostrare

La posta Internet usa campi di header con nome, seguiti da una riga vuota e dal corpo del messaggio. RFC 5322 definisce il formato, compreso il ripiegamento dei campi: una riga che inizia con uno spazio continua il campo precedente. L’analizzatore espande queste continuazioni prima di interpretare i dati. Si ferma alla prima riga vuota, quindi non analizza il corpo né gli allegati.

I mail transfer agent in genere antepongono un campo Received ogni volta che il messaggio attraversa un server. Per questo, nel sorgente grezzo i campi compaiono dal più recente al più vecchio. Il rapporto li inverte e mostra una cronologia che parte dall’origine. Una differenza temporale appare solo quando entrambi i timestamp adiacenti sono interpretabili. Una differenza negativa viene segnalata come possibile disallineamento degli orologi e impedisce di calcolare il tempo di transito totale; non viene mai trasformata silenziosamente in zero.

Come leggere la sezione di autenticazione

RFC 8601 definisce Authentication-Results, un campo aggiunto dal sistema ricevente per registrare esiti quali spf=pass, dkim=pass o dmarc=fail. L’analizzatore conserva i campi Authentication-Results duplicati perché un messaggio può attraversare più domini amministrativi. Mantiene anche proprietà associate quali smtp.mailfrom, header.d e header.from così come sono state dichiarate.

Una DKIM-Signature contiene metadati quali dominio firmatario (d=), selettore (s=), algoritmo (a=), identità (i=) e lunghi valori crittografici (b= e bh=). Il rapporto registra i tag utili e la presenza dei valori di firma, ma esclude intenzionalmente i blocchi di firma dalle esportazioni JSON. Non esegue ricerche DNS né verifiche crittografiche.

RFC 8617 definisce Authenticated Received Chain (ARC). Un’istanza ARC è strutturalmente completa quando contiene un elemento ARC-Seal, un ARC-Message-Signature e un ARC-Authentication-Results con lo stesso valore i=. In questo contesto «completa» descrive solo i tre elementi; non significa che la catena sia valida o affidabile.

Esempio pratico di percorso

Supponiamo che il sorgente grezzo contenga due campi Received. Quello inferiore indica che un’origine ha consegnato il messaggio a un relay alle 10:00:03 +0000; quello superiore indica che il relay ha raggiunto il destinatario alle 10:00:10 +0000. Il rapporto mostra prima l’evento di origine e calcola un intervallo osservato di 7 secondi. I fusi orari vengono rispettati: tra 10:00:03 +0000 e 12:00:06 +0200 passano 3 secondi, non due ore. Se il secondo timestamp normalizzato precede il primo di cinque secondi, il rapporto segnala il disallineamento degli orologi e lascia il totale non disponibile.

Confini di attendibilità ed errori comuni

RFC 5321 descrive il trasporto SMTP e le informazioni di traccia aggiunte dai server. Gli header provenienti dall’esterno di un sistema di posta affidabile possono essere inventati. Inizia a considerare attendibile un ricevitore sotto il tuo controllo e risali solo fino al punto giustificato dai suoi registri e dalle sue politiche. Una differenza tra i domini del From visibile e del Return-Path è comune con mailing list, servizi di inoltro e piattaforme transazionali: è un’osservazione, non una prova di impersonificazione.

Gli oggetti e i nomi visualizzati codificati possono utilizzare parole codificate RFC 2047. L’analizzatore decodifica i comuni formati Base64 o quoted-printable in UTF-8, ISO-8859-1 e Windows-1252; le codifiche non supportate rimangono visibili con un avviso. Le raccolte molto grandi di campi e passaggi vengono limitate per mantenere reattivo il browser. In caso di risposta a un incidente, conserva separatamente il messaggio originale: le esportazioni sono rapporti sintetici e non includono intenzionalmente l’input grezzo, il corpo, gli allegati o i blocchi di firma DKIM.

Privacy ed esportazioni

Analisi, selezione, copia e creazione delle esportazioni avvengono localmente nella scheda corrente. I passaggi del funnel usano l’archiviazione di sessione legata alla scheda, non un URL, quindi i dati grezzi dell’header non vengono inviati tramite Livewire né esposti nei parametri di navigazione. Il limite dell’input è 512 KiB. Il CSV della cronologia usa UTF-8 con byte order mark e righe CRLF; le celle che iniziano con caratteri di formula per fogli di calcolo vengono neutralizzate. Il JSON include le osservazioni estratte e l’avvertenza del rapporto, non l’header originale.