Modificare la data di un'email ricevuta: vero o falso?

La domanda che tutti si fanno (e perché nasconde due situazioni molto diverse)

Digitate "modificare la data di un'email ricevuta" su Google. Compaiono decine di thread su Microsoft Q&A, discussioni Reddit, domande su Quora. La richiesta è chiara, ma le ragioni dietro sono radicalmente diverse a seconda di chi pone la domanda.

Ci sono quelli che vogliono falsificare una data retroattivamente, per ragioni che è meglio non immaginare. E ci sono gli amministratori IT che, dopo una migrazione IMAP, vedono tutte le email mostrare lo stesso giorno (quello della migrazione) e vogliono semplicemente recuperare le date originali. Le due situazioni non hanno nulla in comune, ma condividono la stessa ricerca.

Questo articolo risponde a entrambe. Spoiler: nel primo caso, la modifica non è davvero possibile in modo non rilevabile. Nel secondo, è del tutto legittima ed è esattamente ciò che fa Redate.io.

Prima di tutto: cos'è la "data" di un'email?

Un'email non contiene una sola data. Ne contiene diverse, memorizzate in posti diversi, controllate da entità diverse.

L'intestazione Date: (RFC 2822)

È la data che il client del mittente inserisce nel messaggio al momento dell'invio. È visibile nelle intestazioni grezze in questa forma:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Questa intestazione fa parte del corpo del messaggio. Tecnicamente può essere modificata se si accede al file grezzo. Ma "tecnicamente" è la parola chiave.

Le intestazioni Received:

Ogni server di posta attraverso cui passa un'email aggiunge la propria intestazione Received: con un timestamp. Queste intestazioni formano una catena cronologica, dal server del mittente fino alla casella del destinatario. (Se avete mai provato a leggere le intestazioni grezze di un'email, sapete che non è esattamente una lettura rilassante. Decine di righe di metadati tecnici, in un ordine che va dal più recente al più vecchio.)

L'INTERNALDATE IMAP

È il metadato più importante per capire perché certe modifiche non hanno alcun effetto visibile. L'INTERNALDATE è un attributo memorizzato lato server IMAP, indipendentemente dal contenuto del messaggio. È quello che la maggior parte dei client di posta usa per ordinare le email nelle cartelle. Outlook lo usa. Gmail anche. Apple Mail, nella maggior parte dei casi, pure.

L'INTERNALDATE non è nel messaggio. È nel database del server. Non è possibile modificarlo modificando un file .eml sul proprio disco.

Cosa succede davvero quando si modifica localmente

Modificare un file .eml

Tecnicamente, un file .eml è un file di testo. Lo si può aprire in un editor, cambiare la riga Date:, salvare. Se si reimporta questo file in un client di posta locale, la data visualizzata può cambiare, a seconda del client.

Ma ecco cosa non cambia:

• L'INTERNALDATE sul server IMAP (sempre intatto)
• Le intestazioni Received: aggiunte dai server intermedi
• I log di consegna di Google, Microsoft, o del proprio fornitore
• La firma DKIM, se il messaggio ne aveva una

Risultato: sulla propria macchina locale si vede forse una data diversa. Da Outlook connesso a Exchange Online, o da Gmail in un browser, non è cambiato nulla.

Cambiare l'orologio di sistema

Alcuni forum suggeriscono di modificare l'orologio del computer per "ingannare" il client di posta. Non funziona. Outlook e Gmail non leggono l'ora di sistema per mostrare le date delle email ricevute. Leggono l'INTERNALDATE dal server, o le intestazioni del messaggio. L'orologio locale non entra in gioco da nessuna parte in questo processo.

La manipolazione tramite Thunderbird

Thunderbird offre più flessibilità della maggior parte dei client. Con estensioni o manipolando direttamente il profilo (file mbox, file .msf), alcuni tentano di modificare la visualizzazione delle date. Può funzionare in Thunderbird stesso, per le email archiviate localmente in modalità POP3. Ma appena Thunderbird è connesso in IMAP, risincronizza con il server. La "correzione" scompare alla sincronizzazione successiva.

DKIM: la barriera invisibile che nessuno menziona

La maggior parte delle email inviate dal 2018 in poi è firmata con DKIM (DomainKeys Identified Mail). Una firma DKIM nelle intestazioni assomiglia a questo:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Il campo h= elenca le intestazioni coperte dalla firma. Nell'esempio sopra, Date è firmato. Se si modifica l'intestazione Date: del messaggio, la verifica DKIM fallisce. Qualsiasi server di posta, qualsiasi strumento di analisi forense, può rilevare la modifica ricalcolando la firma.

Non è una protezione perfetta (un mittente malintenzionato controlla la propria chiave DKIM e può firmare quello che vuole al momento dell'invio). Ma per un'email già ricevuta e firmata, modificare l'intestazione Date: lascia una traccia rilevabile.

I log del server: la vera fonte di verità

Anche se si riuscisse a modificare tutti i metadati visibili di un'email (intestazioni, INTERNALDATE, tutto), i fornitori conservano i propri log.

Google Workspace registra ogni messaggio nei log di controllo della Admin Console. Microsoft 365 fa lo stesso nel Centro conformità (Purview). Questi log includono i timestamp di consegna, indipendentemente da ciò che viene mostrato nei client. Un avvocato, un ufficio legale, o un team di sicurezza informatica può recuperare questi dati. La data visibile in Outlook non ha valore probatorio davanti a un tribunale o durante un audit di sicurezza.

Per essere precisi: anche un amministratore con accesso alla casella tramite delega di dominio non può riscrivere retroattivamente questi log. Sono fuori dalla portata degli utenti, anche di quelli con privilegi elevati.

Il caso legittimo: la correzione post-migrazione

Avete appena terminato una migrazione di 150 caselle da un Exchange on-premise verso Microsoft 365. Il lunedi successivo arrivano i ticket: "tutte le mie vecchie email sono datate venerdì scorso". La data della migrazione.

È un problema ben documentato, completamente diverso da quello appena descritto. Qui nessuno vuole falsificare nulla. Le vere date originali esistono ancora, intatte, nell'intestazione Date: di ogni messaggio. Il problema viene da altrove: lo strumento di migrazione (BitTitan MigrationWiz, CloudM, imapsync, o un altro) ha inserito un'intestazione Received: con la data di migrazione in cima alla catena. Outlook, che in certi contesti si affida alle intestazioni Received: più recenti piuttosto che all'INTERNALDATE, mostra questa data al posto di quella originale.

In questo caso, la "correzione" consiste nel ristabilire la coerenza tra ciò che il messaggio dice (l'intestazione Date: originale, ancora lì) e ciò che il server pensa (l'INTERNALDATE, fissato al momento della migrazione). Non è falsificazione. È ripristino.

È esattamente il tipo di problema che una migrazione mal configurata impone a migliaia di caselle. Ed è ciò che Redate.io risolve.

Perché il "fai da te" fallisce su larga scala

Capire il problema è una cosa. Correggerlo su 40.000 email distribuite su 150 caselle senza perderne una sola è un'altra.

Gli script che si trovano su GitHub o Stack Overflow funzionano su 20 email di test. In produzione incontrano problemi che l'autore dello script non aveva previsto:

• Le email firmate S/MIME o cifrate PGP hanno strutture che non si manipolano come messaggi ordinari
• I messaggi multipart con boundary MIME non standard generano errori di parsing
• Le intestazioni codificate in RFC 2047 (caratteri non ASCII nei campi From: o Subject:) mandano in crash i parser più semplici
• Le API di Google e Microsoft impongono limiti di frequenza: alle 3 di notte durante un batch di 30.000 email, l'errore 429 Too Many Requests non viene gestito, lo script si blocca, e nessuno sa dove si è fermato
• Nessun meccanismo di rollback: se un messaggio viene corrotto durante l'elaborazione, non c'è modo di tornare indietro

Redate.io conserva una copia di ogni email originale in una cartella di backup visibile per 30 giorni. Ogni correzione viene verificata individualmente. Il pipeline di analisi gestisce centinaia di firme di strumenti di migrazione noti, inclusi tutti i casi limite che uno script fatto in casa non tratterebbe.

Per approfondire le specifiche in base allo strumento utilizzato: BitTitan MigrationWiz e le date delle email, o CloudM Migrate: correggere le date sbagliate.

Cosa cambia, cosa non cambia mai

La distinzione è netta. Le prime tre righe della tabella descrivono modifiche superficiali o rilevabili. L'ultima descrive una correzione legittima dei metadati, allineata con il contenuto originale del messaggio, dopo una migrazione che ha introdotto un'incoerenza.

Se vi trovate nella situazione descritta nell'ultima riga, dopo una migrazione con imapsync, BitTitan, CloudM o un altro strumento, Redate.io è fatto per questo.

Le vostre email mostrano la data di migrazione al posto delle date reali? Scansionate gratuitamente le vostre caselle con Redate.io e scoprite esattamente quante email sono interessate prima di decidere.