Antidatare un'email: cosa è possibile e cosa è rilevabile

Antidatare un'email: di cosa si parla esattamente?

La domanda torna spesso nei forum di amministrazione di sistema e nei gruppi Slack degli MSP: è possibile modificare la data di un'email dopo l'invio? La risposta breve è sì, tecnicamente. Ma la risposta completa è molto meno rassicurante per chi volesse farlo a fini dubbi.

Un'email non è un file monolitico. È una raccolta di header testuali seguiti da un corpo del messaggio. Tra questi header, diversi contengono informazioni di data. E alcuni sono più facili da modificare di altri.

Tre livelli di datazione coesistono in ogni email:

• L'header Date: (RFC 2822), scritto dal client di posta al momento dell'invio
• Gli header Received:, aggiunti da ogni server che instrada il messaggio
• L'INTERNALDATE IMAP, un metadato memorizzato lato server, indipendente dal contenuto del messaggio

Ognuno di questi livelli è modificabile. Nessuno lo è senza lasciare tracce.

Modificare l'header Date:: la manipolazione più evidente

L'header Date: è testo semplice nel file .eml. Tecnicamente, qualsiasi editor esadecimale o script Python può riscriverlo in pochi secondi. Se ha mai aperto gli header grezzi di un'email in Gmail (il piccolo menu "Mostra originale"), sa che è leggibile da chiunque.

Il problema? Dal 2004, la grande maggioranza dei server di posta firma le email in uscita con DKIM (DomainKeys Identified Mail). Questa firma crittografica copre esplicitamente diversi header, tra cui Date:, From:, Subject:, e il corpo del messaggio. La firma è memorizzata nell'header DKIM-Signature:.

Modificare il Date: dopo la firma invalida meccanicamente la verifica DKIM. Qualsiasi server ricevente può verificare la firma recuperando la chiave pubblica dal DNS del dominio mittente. Se la firma non corrisponde più, il messaggio viene contrassegnato come alterato. Gmail, Outlook.com e tutti i grandi provider eseguono questa verifica automaticamente.

(Tra l'altro, se vuole vedere concretamente una firma DKIM, apra gli header grezzi di un'email ricevuta da Gmail o Office 365: troverà una riga DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... che sembra rumore ma è in realtà un hash crittografico dell'intero messaggio.)

Risultato: modificare il Date: su un'email firmata DKIM significa rompere il sigillo. La modifica è visibile da qualsiasi amministratore che sappia dove cercare.

Riscrivere gli header Received:: una catena difficile da falsificare

Gli header Received: tracciano il percorso di un'email tra mittente e destinatario. Ogni server SMTP che tocca il messaggio ne aggiunge uno, con il suo nome, il suo indirizzo IP e un timestamp. Un'email che passa attraverso due o tre relay contiene quindi due o tre header Received: impilati.

Si possono modificare? Tecnicamente sì, sulla propria copia del messaggio. Ma ecco la trappola: anche il destinatario ha una copia. E il suo server ha aggiunto il proprio header Received: per ultimo. Questo header è sotto il controllo del destinatario, non del mittente. È impossibile falsificarlo dall'esterno.

La coerenza della catena è verificabile. Se i timestamp dei successivi Received: sono incoerenti (un relay intermedio avrebbe ricevuto il messaggio prima che il mittente lo avesse inviato, per esempio), è immediatamente sospetto. Gli strumenti di analisi forense email come MXToolbox o gli strumenti interni dei team di sicurezza verificano esattamente questo.

A dire il vero, non è del tutto corretto affermare che gli header Received: sono impossibili da falsificare integralmente: un attaccante che controlla la propria infrastruttura mail può costruire header credibili per i relay che padroneggia. Ma non controlla mai l'ultimo anello: il server del destinatario.

L'INTERNALDATE IMAP: il caso più tecnico

L'INTERNALDATE è un metadato IMAP memorizzato lato server. Non è un header nel messaggio stesso: è un valore che il server associa al messaggio nel suo database interno. È questo valore che la maggior parte dei client di posta usa per ordinare i messaggi nella casella di posta in arrivo.

Il comando IMAP APPEND consente di depositare un messaggio su un server specificando esplicitamente un INTERNALDATE. È una funzionalità legittima del protocollo, documentata nella RFC 3501. Gli strumenti di migrazione la usano costantemente: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... tutti depositano email sul server di destinazione con un INTERNALDATE specificato.

Teoricamente, qualcuno con accesso IMAP alla propria casella potrebbe depositare un'email con qualsiasi INTERNALDATE. Ma questa manipolazione non modifica gli header del messaggio. Il Date: originale rimane intatto, gli header Received: rimangono intatti, la firma DKIM rimane intatta. Cambia solo il metadato di ordinamento lato server.

Per un esperto che esamina il messaggio grezzo, la discrepanza tra l'INTERNALDATE e il Date: è immediatamente visibile. E se il messaggio è firmato DKIM, la data originale è attestata crittograficamente.

Il Message-ID: un'impronta difficilmente falsificabile

Ogni email genera un identificatore unico, l'header Message-ID:. Questo identificatore viene costruito dal server SMTP mittente al momento dell'invio, combinando generalmente un timestamp, un identificatore casuale e il nome di dominio del server.

Un Message-ID tipico assomiglia a questo: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Il timestamp è spesso codificato direttamente nell'identificatore. Modificare la data del messaggio lasciando un Message-ID con un timestamp incompatibile crea un'incoerenza immediatamente individuabile.

Inoltre, i Message-ID vengono indicizzati dai grandi sistemi di messaggistica. Google, Microsoft e altri operatori mantengono log che consentono di risalire a quando un messaggio ha effettivamente circolato sulle loro infrastrutture. In un contesto legale o forense, questi log sono accessibili tramite procedure giudiziarie.

In pratica: chi può rilevare un tentativo di manipolazione?

Poniamo la domanda concretamente. Riceve un'email di cui sospetta che la data sia stata modificata. Cosa può fare un amministratore IT o un avvocato con un minimo di background tecnico?

• Verifica DKIM: in Gmail, il menu "Mostra originale" visualizza direttamente il risultato della verifica DKIM in cima alla pagina. Un "PASS" conferma l'integrità del messaggio dall'invio. Un "FAIL" o "SOFTFAIL" segnala un'alterazione.
• Analisi degli header: strumenti come MXToolbox Header Analyzer o il Google Admin Toolbox analizzano automaticamente la catena dei Received: e segnalano le incoerenze temporali.
• Coerenza Message-ID / Date: un analista può confrontare il timestamp codificato nel Message-ID con il valore del Date: dichiarato.
• Log del server: se l'email è transitata per un server di cui Lei è amministratore, i log SMTP contengono la data e l'ora reali di accettazione del messaggio, indipendentemente da qualsiasi header.

Insomma, gli strumenti di rilevamento sono accessibili, gratuiti e non richiedono competenze forensi avanzate. Un amministratore IT un po' curioso può verificare l'integrità di un'email in meno di due minuti.

L'unico caso legittimo di modifica massiva delle date: la migrazione IMAP

Esiste uno scenario in cui centinaia di migliaia di email si ritrovano con date errate senza alcuna intenzione malevola: la migrazione IMAP.

Ha appena terminato una migrazione di 150 caselle Exchange verso Google Workspace. Lunedì mattina, i ticket iniziano ad arrivare. Gli utenti segnalano che tutte le email vecchie mostrano la stessa data, quella del weekend di migrazione. Le caselle di posta sono illeggibili.

Quello che è successo è documentato e prevedibile: lo strumento di migrazione (BitTitan, CloudM, imapsync, poco importa) ha depositato le email su Google Workspace tramite IMAP APPEND. Ha specificato un INTERNALDATE corrispondente alla data di migrazione, non alla data originale dell'email. Risultato: Outlook, che ordina per INTERNALDATE di default, mostra la data di migrazione per tutti i messaggi. Perché le email hanno la data sbagliata dopo migrazione spiega questo meccanismo in dettaglio.

L'header Date: originale è intatto in ogni messaggio. Le firme DKIM sono intatte. Il contenuto non è cambiato. È solo l'INTERNALDATE lato server a essere errato.

Questo problema riguarda BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO e tutti gli strumenti che usano IMAP APPEND senza preservare correttamente l'INTERNALDATE. L'articolo dedicato a BitTitan MigrationWiz copre le particolarità di questo strumento. La checklist migrazione email elenca i punti da verificare prima e dopo una migrazione per evitare questo tipo di problema.

La differenza tra correggere e falsificare

La correzione che Redate.io esegue è all'opposto di un tentativo di falsificazione. Il motore di correzione proprietario analizza la catena di header di ogni messaggio, identifica la data originale codificata nell'header Date: (RFC 2822) che non è mai cambiata, e corregge i metadati di data per allinearli a questa informazione autentica già presente nel messaggio.

L'header Date: è la fonte di verità. È stato scritto dal client di posta del mittente al momento dell'invio. È coperto dalla firma DKIM. Non viene modificato da Redate.io. Quello che viene corretto è la discrepanza introdotta dallo strumento di migrazione, non la data originale.

Correggere 47.000 email dopo una migrazione andata male senza perderne una sola, senza rompere i thread di conversazione, senza corrompere gli allegati, senza innescare errori 429 alle 3 di notte sull'API Google: si tratta di un pipeline di analisi multi-fase con gestione dei casi limite (S/MIME, PGP, codifiche non-ASCII secondo RFC 2047, strutture multipart complesse). Uno script Python di cinque righe non sopravviverebbe alla prima casella di produzione. Si possono correggere le date email dopo la migrazione spiega perché il fai-da-te è rischioso su volumi reali.

Redate.io scansiona le caselle di posta gratuitamente, identifica le email con date errate e corregge tramite un pipeline di validazione che verifica ogni messaggio individualmente. Gli originali vengono conservati in una cartella di backup visibile per 30 giorni. Se qualcosa va storto, il rollback è possibile.

La Sua migrazione ha spostato le date delle email? Avvii una scansione gratuita su Redate.io per misurare l'entità del problema prima di decidere cosa fare.