Cambiare la data di un'email: limiti tecnici

Un'email ha tre "date". Non una.

Quando si parla di "cambiare la data di ricezione di un'email", la maggior parte delle persone immagina di modificare un campo da qualche parte, come si cambierebbe la data di creazione di un file su Windows. La realtà è un po' più complicata. Un'email trasporta in realtà tre livelli di datazione distinti, ognuno con le proprie regole, i propri meccanismi di controllo, e le proprie conseguenze se ci si mette mano.

Capire questi tre livelli significa capire perché certe correzioni sono tecnicamente corrette, e altre sono semplicemente impossibili o immediatamente riconoscibili come falsificazioni.

Livello 1: l'INTERNALDATE IMAP

L'INTERNALDATE è un metadato memorizzato lato server, al di fuori del messaggio stesso. Non fa parte del contenuto dell'email. È il server IMAP a definirla, ed è quella che la maggior parte dei client di posta usa per ordinare i messaggi nell'elenco.

Outlook, per esempio, mostra di default i messaggi ordinati per INTERNALDATE. Anche Gmail, in certi contesti. Di conseguenza, se l'INTERNALDATE è sbagliata, tutte le email sembrano avere la stessa data nell'interfaccia, indipendentemente da quello che dicono le intestazioni interne del messaggio.

L'INTERNALDATE viene definita nel momento in cui il messaggio viene depositato sul server. Tramite il protocollo IMAP, l'unico modo per "modificarla" è indiretto: bisogna usare il comando APPEND per depositare una nuova copia del messaggio con la data desiderata. Non esiste un comando IMAP SETINTERNALDATE. Questo dettaglio tornerà utile tra un momento.

Livello 2: l'intestazione Date: (RFC 2822)

È il campo Date: nelle intestazioni grezze del messaggio. Viene definito dal client di posta al momento dell'invio, e viaggia con il messaggio da server a server. È la data di invio dichiarata dal mittente.

(Tra l'altro, se non ha mai letto le intestazioni grezze di un'email, è una lettura piuttosto sorprendente. Ogni messaggio si trascina una ventina di righe tecniche che il 99% delle persone non ha mai visto.)

Tecnicamente, nulla impedisce di inviare un'email con un campo Date: antidatato o postdatato. I server SMTP non validano questo campo. Ma i server destinatari annotano l'orario di arrivo reale nelle intestazioni Received:, il che crea immediatamente un'incoerenza visibile da qualsiasi client di posta o strumento di analisi.

Livello 3: le intestazioni Received: impilate

Ogni volta che un server SMTP rilancia un messaggio, aggiunge un'intestazione Received: in cima alla pila, con un timestamp. Un'email passata per tre server avrà tre intestazioni Received:. Si leggono dal basso verso l'alto: la più antica è in fondo, la più recente è in cima.

È precisamente qui che gli strumenti di migrazione creano il problema. Quando BitTitan MigrationWiz, CloudM, imapsync o GSMMO migrano un'email, la reinseriscono sul nuovo server via IMAP. Questo deposito genera un nuovo Received: con il timestamp del giorno della migrazione. Risultato: il messaggio più vecchio della casella, un'email del 2019, si ritrova con un Received: datato novembre 2024. E siccome certi client di posta (Outlook in testa) usano il Received: più recente come data di visualizzazione...

Ecco il problema. 15.000 email mostrano tutte la stessa data di migrazione.

Si possono davvero "modificare" queste date?

Tecnicamente, sì per l'INTERNALDATE (con dei vincoli). Tecnicamente possibile ma inutile per il Date:. E per i Received:, vale la pena soffermarsi.

Riscrivere un'intestazione Received: è banale. E immediatamente rilevabile.

Un'intestazione Received: non è altro che una riga di testo nel messaggio. La si può modificare come qualsiasi file di testo. È esattamente semplice come sembra.

Ma ecco cosa succede dopo.

Primo problema: DKIM. La firma DKIM (DomainKeys Identified Mail) viene calcolata su un insieme di intestazioni del messaggio, a volte inclusi i Received:. Modificare un'intestazione firmata invalida la firma. Qualsiasi server destinatario che verifica DKIM vedrà immediatamente che il messaggio è stato alterato. Non è una falsificazione sottile, è un campanello d'allarme.

Secondo problema: gli identificatori interni. I server di posta moderni (Google Workspace, Microsoft 365) assegnano a ogni messaggio un identificatore interno crescente e univoco. Questi identificatori sono legati all'INTERNALDATE e all'ordine di ricezione. Modificare un Received: senza coerenza con questi identificatori crea incongruenze che gli strumenti di audit rilevano senza alcuna difficoltà.

Terzo problema, più pratico: anche se si modifica il Received: nel contenuto del messaggio, non si è toccata l'INTERNALDATE, che rimane quella del deposito IMAP. Il client di posta continua a mostrare la data sbagliata per l'ordinamento. Si è modificato il messaggio per nulla.

In sostanza: riscrivere i Received: per falsificare la data di un'email con intento malevolo è tecnicamente banale, ma rilevabile in pochi secondi da un esperto. Non è una strada percorribile.

L'intestazione Date:: cambiare il passato sulla carta

Stesso ragionamento per il Date:. Lo si può modificare nel corpo del messaggio. Ma le intestazioni Received: autenticate dai server intermedi rimangono intatte e raccontano un'altra storia. La catena temporale è incoerente. Qualsiasi analista o tribunale che confronti questi campi lo vedrà immediatamente.

Per essere precisi, questo non impedisce ad alcuni client di posta di mostrare il Date: modificato se viene presentato direttamente il file .eml. Ma nel contesto di un server di posta attivo, con autenticazione e log, la modifica è trasparente.

La migrazione IMAP: l'unico contesto in cui correggere le date ha senso

C'è un caso, e uno solo, in cui modificare la data di ricezione di un'email è non solo possibile ma tecnicamente giustificato: correggere i danni causati da una migrazione IMAP gestita male.

Ecco la situazione concreta. Ha appena migrato 80 caselle Exchange verso Microsoft 365. La migrazione si è conclusa un venerdì sera. Lunedì mattina arrivano i primi ticket: "Tutte le mie email hanno la stessa data", "Non riesco a trovare un'email dell'anno scorso", "La mia cronologia con questo cliente è completamente rotta". 80 utenti bloccati e il responsabile che aspetta una risposta.

In questo contesto, il problema è documentato, identificabile, e la sua causa è chiara: lo strumento di migrazione ha aggiunto un Received: datato al giorno della migrazione, e certi client di posta usano questa nuova intestazione come data di visualizzazione. L'intestazione Date: originale, invece, è intatta in ogni messaggio. Non è mai stata modificata. Contiene ancora la data di invio originale, corretta.

La correzione non è quindi una falsificazione: è un ripristino. Si parte da dati veri (il Date: originale) per ricostruire metadati coerenti. Questo è fondamentalmente diverso dal tentare di far passare un'email del 2024 per un'email del 2019.

Per approfondire i meccanismi specifici di ogni strumento, questi guide dettagliano i casi concreti: correggere le date BitTitan in Microsoft 365, correggere le date CloudM in Outlook, o correggere le date imapsync in Google Workspace.

Perché scrivere uno script da soli è rischioso

La logica di base è accessibile. Qualsiasi admin IT che abbia trascorso del tempo sui forum IMAP può ricostruire l'approccio generale. Questo non è il problema.

Il problema è la distanza tra uno script che funziona su 50 email di test e uno script che gira su 40.000 messaggi in produzione senza perdere una sola email, senza corrompere un solo allegato, e senza rompere un solo filo di conversazione.

Alcuni casi concreti che gli script fatti in casa generalmente non gestiscono:

• Email firmate con S/MIME: la firma copre il contenuto e le intestazioni. Qualsiasi modifica alla struttura del messaggio invalida la firma. Un'email firmata e corretta in modo approssimativo arriva come "firma non valida" ai destinatari.
• Messaggi cifrati con PGP: stessa famiglia di problemi, con conseguenze potenzialmente peggiori a seconda dell'implementazione.
• Codifiche non-ASCII nelle intestazioni: RFC 2047 descrive la codifica dei caratteri speciali nelle intestazioni. Uno script che manipola le intestazioni senza gestire questi casi corromperà silenziosamente gli oggetti delle email contenenti accenti, caratteri giapponesi, o nomi in arabo.
• Limiti di frequenza API: Google Workspace e Microsoft 365 implementano throttling aggressivi. Alle 3 di notte, un batch di 10.000 email che incappa in un errore 429 Too Many Requests senza gestione del backoff esponenziale lascia metà delle caselle a metà della correzione.
• Confini MIME corrotti: i messaggi multipart con allegati hanno confini MIME precisi. Rigenerarli in modo errato rende gli allegati illeggibili.

E la domanda che nessuno script fatto in casa risolve: come verificare che ogni email corretta sia intatta? Uno script che modifica 40.000 messaggi senza verifica individuale è una scommessa. Una scommessa su dati che gli utenti considerano spesso insostituibili.

Un articolo sulle opzioni disponibili per correggere le date dopo la migrazione esplora i diversi approcci, inclusi i rispettivi limiti.

Cosa fa Redate.io in questo contesto

Redate.io è progettato specificamente per questo caso: correggere le date corrotte da una migrazione IMAP, su larga scala, senza rischi per l'integrità dei messaggi.

Il servizio si connette direttamente alle caselle interessate (Google Workspace tramite delega di dominio, Microsoft 365 tramite Azure AD, o IMAP diretto), scansiona gratuitamente i messaggi con date errate, poi applica un pipeline di correzione proprietario che gestisce i casi limite documentati sopra. Ogni email viene verificata individualmente dopo la correzione. Gli originali rimangono in una cartella di backup visibile per 30 giorni.

Il riconoscimento dei pattern copre centinaia di firme di strumenti di migrazione noti: BitTitan MigrationWiz, CloudM, imapsync, GSMMO e le loro varianti. Il rilevamento è preciso: Redate.io non tocca le email con date già corrette.

Il modello di prezzo è semplice: pagamento unico per casella di posta, senza abbonamento. La scansione diagnostica è gratuita, il che consente di misurare l'entità dei danni prima di decidere qualsiasi cosa.

Se gestisce caselle affette da questo problema, questo articolo sulle date sbagliate in Outlook dopo la migrazione dettaglia i sintomi più comuni e come distinguerli da altre cause.

Pronto a misurare l'entità del problema sulle Sue caselle? Avvii una scansione gratuita su Redate.io e scopra esattamente quante email sono interessate prima di qualsiasi correzione.