eM Client: date sbagliate dopo import PST o Thunderbird

Il sintomo: tutte le email hanno la stessa data

Ha appena terminato un import PST in eM Client, oppure ha migrato da Thunderbird verso la nuova casella. L'import è andato a buon fine, nessun errore apparente. Ma aprendo la casella di posta qualcosa non va: centinaia, a volte migliaia di email mostrano tutte la stessa data, quella del giorno dell'import. Un'email del 2019 sembra ricevuta ieri. Un contratto firmato tre anni fa appare come se fosse appena arrivato.

La prima reazione naturale è incolpare eM Client. Un parametro sbagliato, una colonna di ordinamento errata, un bug di visualizzazione... Si va a cercare nelle preferenze. Si passa da "Data di ricezione" a "Data di invio". Niente cambia. O meglio, qualcosa cambia, ma non risolve il problema di fondo.

Perché il problema non è in eM Client. È nei metadati del server.

La vera causa: l'INTERNALDATE IMAP sovrascritto durante l'import

Per capire cosa succede, bisogna scendere di un livello e guardare come il protocollo IMAP memorizza le email.

Ogni messaggio su un server IMAP ha due tipi di date distinte:

• L'intestazione Date: (definita dalla RFC 2822): è la data che il mittente ha inserito nel messaggio al momento dell'invio. È incapsulata nel corpo del messaggio, in teoria intoccabile.
• L'INTERNALDATE: un metadato del server, esterno al messaggio, che rappresenta la data in cui il messaggio è stato depositato nella casella. È questo valore che i client di posta usano in via prioritaria per ordinare e visualizzare le email.

Durante un import PST o una migrazione da Thunderbird, lo strumento di import (che si tratti del modulo nativo di eM Client, di uno strumento di terze parti, o di una copia IMAP manuale) deposita i messaggi sul server IMAP di destinazione. E se lo strumento non preserva esplicitamente l'INTERNALDATE originale al momento del deposito, il server assegna automaticamente l'INTERNALDATE corrente, cioè la data e l'ora dell'import.

Risultato: 8.000 email archiviate dal 2017, tutte marcate come "ricevute" al momento della migrazione.

(Tra l'altro, se ha già provato a leggere le intestazioni grezze di un'email con Visualizza sorgente in eM Client, avrà potuto constatare che l'intestazione Date: originale è sempre lì, intatta. È il segnale che il problema viene dall'INTERNALDATE del server, non dal messaggio in sé.)

Perché cambiare la colonna di ordinamento non serve a niente

La confusione nasce da una distinzione che pochi conoscono. In eM Client, come in Outlook o Thunderbird, esistono generalmente due colonne di data:

• "Data di ricezione" (o "Data di arrivo"): basata sull'INTERNALDATE del server.
• "Data" o "Data di invio": basata sull'intestazione Date: del messaggio.

Molti amministratori lo scoprono e pensano di aver trovato la soluzione: passare a "Data di invio", e il problema sparisce visivamente in eM Client. Ma non è proprio così.

A dire il vero, anche ordinando per data di invio in eM Client, il problema persiste per tutti gli altri client e tutte le altre interfacce che accedono alla stessa casella. Se gli utenti consultano le email da OWA, da Outlook in ufficio, dall'app Gmail su mobile, o da qualsiasi client configurato in IMAP, vedranno le date di import. L'impostazione di ordinamento di eM Client si applica solo a eM Client, e non agisce sui metadati archiviati lato server.

Inoltre, su Microsoft 365 e Google Workspace, la vista web nativa ordina per INTERNALDATE. Non è possibile cambiare questo comportamento dal client.

L'ordinamento per data di invio non è una soluzione. È un cerotto che maschera un problema reale senza correggerlo.

Il caso particolare dell'import PST

L'import di file PST merita un paragrafo a parte. Un file PST (Personal Storage Table) è un formato proprietario Microsoft che archivia email, contatti e calendari in locale. Quando si importa un PST in eM Client, sono possibili due scenari:

• Import locale verso un account IMAP: eM Client legge il PST e carica i messaggi sul server IMAP di destinazione. Se la data di deposito non viene preservata, l'INTERNALDATE viene sovrascritto. È il caso più frequente, ed è qui che le date risultano corrotte.
• Import verso una cartella locale: i messaggi rimangono sulla macchina, fuori dal server. L'INTERNALDATE non esiste in questo contesto, e eM Client può visualizzare la data Date: del messaggio. Meno problemi di data qui, ma anche meno utilità pratica.

Per Thunderbird la situazione è analoga. Che si utilizzi la funzione di import integrata di eM Client (che legge i profili Thunderbird), o che si siano copiati dossier mbox via IMAP, i messaggi vengono ridepositati sul server senza garanzia di preservazione dell'INTERNALDATE. E un server che riceve un messaggio senza istruzioni esplicite sulla data dell'INTERNALDATE apporrà sistematicamente il timbro orario al momento della ricezione.

Quale piattaforma è interessata?

Il problema è identico indipendentemente dalla piattaforma di destinazione, perché si tratta di un comportamento standard del protocollo IMAP:

• Microsoft 365 / Exchange Online: l'INTERNALDATE viene sovrascritto durante qualsiasi import che non utilizzi il comando IMAP APPEND con un parametro di data esplicito. Lo stesso vale per una migrazione da Exchange on-premise.
• Google Workspace: stesso comportamento. Le email importate tramite eM Client o strumenti di terze parti mostrano la data di import in Gmail e nell'interfaccia di amministrazione.
• Provider IMAP classici (OVH, Infomaniak, Ionos, o2switch, ecc.): nessun trattamento speciale della data alla ricezione di un messaggio in APPEND. L'INTERNALDATE sarà la data del deposito.

Un cliente ci ha contattato dopo aver migrato un centinaio di caselle da Exchange 2013 verso Microsoft 365, usando eM Client come strumento di transizione per alcuni account VIP. Risultato: le caselle migrate correttamente tramite MigrationWiz erano a posto, ma quelle passate per eM Client avevano tutte le date di import. Inutile dire che gli utenti coinvolti non l'hanno presa bene.

Perché uno script fatto in casa non risolverà facilmente il problema

In teoria, chi conosce il protocollo IMAP potrebbe pensare di scrivere uno script per correggere gli INTERNALDATE. L'intestazione Date: originale è lì, intatta in ogni messaggio. Basterebbe leggerla e ricostruire i metadati del server di conseguenza, no?

In teoria, sì. In pratica, è un campo minato.

Prima di tutto, i casi limite si accumulano rapidamente su una casella di produzione. I messaggi firmati digitalmente con S/MIME sono particolarmente sensibili a qualsiasi manipolazione della struttura. Lo stesso vale per i messaggi cifrati con PGP. Le email con allegati voluminosi, confini MIME non standard, o codifiche Content-Transfer-Encoding inusuali possono corrompersi silenziosamente se il trattamento non è rigoroso. Uno script che funziona su 50 email di test non funzionerà in modo affidabile su una casella di 20.000 messaggi con 6 anni di storico.

Poi c'è la gestione delle quote API. Su Microsoft 365, i limiti di frequenza sull'API Graph o su EWS alle 3 di notte su un batch di correzione di 8.000 messaggi si gestiscono. Ma non si gestiscono da soli. Uno script non supervisionato che incontra un errore 429 Too Many Requests sul messaggio n. 3741 potrebbe andare avanti, oppure no. E non si saprà necessariamente quali messaggi sono stati elaborati.

E soprattutto: come verificare che ogni email corretta sia intatta dopo l'elaborazione? Uno script fatto in casa non ha generalmente un meccanismo di verifica individuale. Redate.io lo fa automaticamente, per ogni singolo messaggio.

Correggere le date alla radice con Redate.io

Redate.io affronta il problema dove si trova: a livello dei metadati del server, non a livello del client di posta.

Il processo inizia con una fase di scansione gratuita. Redate.io si connette alla casella interessata (Microsoft 365 tramite Azure AD, Google Workspace tramite delega di dominio, o IMAP diretto per i provider classici) e identifica le email i cui metadati di data sono incoerenti con il contenuto del messaggio. Il risultato è visibile prima di qualsiasi pagamento.

La correzione utilizza un motore proprietario che analizza la catena completa delle intestazioni di ogni messaggio, applica un pattern matching su centinaia di firme di strumenti di import noti (inclusi i comportamenti specifici di eM Client, Thunderbird e degli import PST), e ricostruisce i metadati di data in modo mirato senza alterare il contenuto del messaggio, i suoi allegati, né la sua struttura MIME.

Ogni email corretta viene verificata individualmente. Gli originali sono conservati in una cartella di backup visibile per 30 giorni, cosa che uno script fatto in casa non farà mai per impostazione predefinita.

La tariffazione è semplice: pagamento unico per casella, basato sul volume di email da correggere. Nessun abbonamento, nessun costo ricorrente. Consulti la pagina di avvio per vedere i dettagli.

Per la prossima migrazione: cosa verificare

Se sta pianificando una migrazione e vuole evitare questo problema a monte, il punto di controllo è semplice: lo strumento che utilizza preserva esplicitamente l'INTERNALDATE al momento del deposito dei messaggi sul server di destinazione?

Per gli import PST verso Microsoft 365, gli strumenti certificati Microsoft (come MigrationWiz nelle sue modalità native, o lo strumento di migrazione Exchange Online) gestiscono generalmente questa preservazione. Per gli import manuali tramite eM Client o Thunderbird, raramente è il caso. Verifichi la documentazione del suo strumento prima di lanciare un import su caselle di produzione.

Una buona checklist di migrazione email include sempre una verifica post-migrazione delle date su un campione di caselle. Per approfondire, la checklist migrazione email copre questo punto in dettaglio.

Per gli amministratori che gestiscono regolarmente migrazioni per i propri clienti, l'articolo su la correzione delle date email lato MSP e quello su il funzionamento dell'INTERNALDATE IMAP offrono una visione più completa del problema.

Le date delle sue email sono corrotte dopo un import eM Client? Lanci una scansione gratuita su Redate.io per misurare l'entità del problema prima di decidere come procedere.