Date errate dopo migrazione da Zoho a Microsoft 365

Cosa è successo alla tua casella email

Ha appena completato la migrazione del dominio da Zoho Mail a Microsoft 365. L'infrastruttura Exchange Online è operativa, le caselle sono state provisionate, i record MX aggiornati. E poi, lunedì mattina, un utente apre Outlook e si accorge che tutte le email del 2021 mostrano la data di oggi. Un altro nota che i messaggi dell'anno scorso appaiono in cima alla posta in arrivo, come se fossero appena arrivati. I ticket di assistenza iniziano ad accumularsi.

Non è un bug di Outlook. Non è nemmeno un problema specifico di Zoho. È quello che succede quando lo strumento di migrazione non trasmette la data originale di ogni email. Capire esattamente perché succede è il primo passo per correggerlo in modo definitivo.

La causa tecnica: INTERNALDATE e intestazioni Received

Un'email archiviata su un server IMAP è composta da due elementi distinti: il contenuto grezzo del messaggio (le intestazioni RFC 2822, il corpo, gli allegati) e i metadati di archiviazione gestiti dal server IMAP, tra cui l'INTERNALDATE. È questo metadato che i client email usano per visualizzare e ordinare i messaggi.

L'intestazione Date: definita nel messaggio grezzo (RFC 2822) rappresenta la data in cui il messaggio è stato composto o inviato dal mittente. L'INTERNALDATE, invece, è la data in cui il server IMAP ha ricevuto o archiviato il messaggio. Normalmente, su un server sano, questi due valori sono vicini. Dopo una migrazione, è tutta un'altra storia.

Come una migrazione IMAP può corrompere le date

Quando uno strumento di migrazione (il Zoho Migration Wizard, imapsync, BitTitan, o qualsiasi altro) trasferisce un messaggio da Zoho Mail a Exchange Online, lo fa tramite il protocollo IMAP. Lo strumento si connette a Zoho, recupera il messaggio, poi lo inserisce in Exchange Online. Ed è qui che le cose si complicano.

Exchange Online conserva la data che riceve: quando lo strumento trasmette l'INTERNALDATE originale di ogni messaggio con il comando APPEND, la copia la conserva. Alcuni strumenti di migrazione lo fanno. Altri non lo fanno, o lo fanno in modo errato, e in quel caso Exchange Online assegna come INTERNALDATE il momento dell'inserimento, ovvero la data della migrazione.

Risultato: che si tratti di un'email inviata nel 2019 o nel 2022, il suo INTERNALDATE punta ora alla settimana della migrazione. Outlook legge questo valore in via prioritaria. L'ordinamento collassa.

Il comportamento specifico del Zoho Migration Wizard

Zoho offre il proprio strumento per abbandonare la piattaforma: il Zoho Migration Wizard. È pratico per le migrazioni semplici, ma ha un comportamento documentato sui forum degli amministratori: non trasmette sempre correttamente l'INTERNALDATE originale durante l'inserimento nel server di destinazione.

Per essere precisi: quando il Zoho Migration Wizard trasmette effettivamente la data originale, Exchange Online la conserva e Outlook mostra la data corretta. Le email che mostrano la data della migrazione sono quelle la cui data non è stata trasmessa.

Gli amministratori che usano strumenti IMAP generici come imapsync per lasciare Zoho possono incontrare lo stesso problema: imapsync copia la data che il server di origine associa a ogni messaggio, quindi una data errata all'origine diventa una data errata a destinazione. (Tra l'altro, se ha già scorso un log di imapsync riga per riga alle 2 di notte alla ricerca di un errore di sincronizzazione, sa bene che è uno strumento potente ma poco indulgente sui casi limite.)

Perché Outlook mostra la data sbagliata

Outlook non usa solo l'intestazione Date: per visualizzare la data di un'email. Nella maggior parte delle visualizzazioni, è l'INTERNALDATE fornito dal server IMAP/Exchange a essere usato, in particolare per l'ordinamento della posta in arrivo. L'intestazione Date: originale è presente nel messaggio, intatta, ma viene ignorata a favore dell'INTERNALDATE.

Ecco perché l'opzione "Ordina per data di invio" in Outlook non risolve davvero il problema. Mostra una data diversa, certo, ma il comportamento di ordinamento rimane instabile a seconda delle versioni di Outlook e delle modalità di visualizzazione (conversazioni raggruppate o meno). Ordinare per data di invio non è una soluzione. È un cerotto che cade al primo aggiornamento del client.

L'entità reale del problema

In una migrazione Zoho verso Microsoft 365 di dimensioni medie, si parla facilmente di 50.000 fino a 500.000 messaggi interessati, a seconda dell'anzianità delle caselle e delle dimensioni dell'organizzazione. Ogni email trasferita durante la finestra di migrazione porta la stessa data corrotta, rendendo il problema immediatamente visibile agli utenti alla prima apertura di Outlook.

Le cartelle Posta inviata sono spesso le più problematiche. Un commerciale che cerca un preventivo inviato a marzo 2022 si ritrova a scorrere centinaia di email che mostrano tutte la data di migrazione. L'impatto operativo è reale, non solo estetico.

E, contrariamente a quanto si potrebbe pensare, il problema non scompare con il tempo. L'INTERNALDATE viene fissato al momento dell'inserimento. Non si corregge da solo. Senza un intervento attivo, le email manterranno la data corrotta a tempo indefinito.

Perché correggere da soli è più rischioso di quanto sembri

La tentazione è comprensibile: visto che l'intestazione Date: originale è ancora presente nel messaggio, basterebbe correggere i metadati. Sulla carta, è logico. In pratica, su una casella di produzione con 80.000 email, è un'operazione che può andare catastroficamente storta.

Ecco alcuni casi limite che uno script fatto in casa probabilmente non gestirà bene:

• Le email firmate S/MIME, la cui firma copre l'intero set di intestazioni. Modificare qualsiasi elemento nella struttura del messaggio invalida la firma crittografica.
• I messaggi cifrati con PGP, dove il contenuto è opaco e qualsiasi manipolazione degli involucri MIME può corrompere il messaggio.
• Le intestazioni non-ASCII codificate in RFC 2047 (nomi di mittenti con caratteri speciali), che si rompono se lo script non gestisce correttamente la codifica.
• Gli allegati codificati in base64 con righe mal terminate, boundary MIME non standard, o strutture multipart annidate.
• Le email senza un'intestazione Date: valida (esistono, in particolare nei vecchi export di Zoho), dove lo script deve decidere come comportarsi.

Uno script che funziona su 50 email di test non funzionerà su una casella di produzione Zoho esportata con anni di storico. E come si verifica, messaggio per messaggio, che ogni correzione sia integra e che gli allegati non siano stati troncati? La verifica è almeno tanto complessa quanto la correzione stessa.

C'è anche la questione delle quote. L'API di Exchange Online, tramite Microsoft Graph, impone limiti di frequenza severi (i famigerati errori 429 Too Many Requests). Un batch non throttlato su 100.000 messaggi può innescare blocchi temporanei o errori silenziosi difficili da diagnosticare a posteriori. Senza un meccanismo di ripresa in caso di errore, si ricomincia da capo.

Come Redate.io corregge le date dopo la migrazione da Zoho

Ogni utente accede con il proprio account Microsoft, e Redate.io apre quella singola casella con l'accesso concesso da quel login. La scansione iniziale è gratuita: Redate.io identifica le caselle interessate e stima il volume di email con date errate, confrontando l'INTERNALDATE con i valori contenuti nella catena di intestazioni del messaggio.

La correzione utilizza un motore proprietario che analizza la catena completa di intestazioni di ogni messaggio, non ha bisogno di sapere quale strumento ha eseguito la migrazione (Zoho Migration Wizard, imapsync o qualsiasi altro) e ricostruisce le date corrette. Ogni email corretta viene verificata individualmente: integrità del contenuto, preservazione degli allegati, conformità RFC. Gli originali non vengono mai eliminati: restano in una cartella visibile della casella, finché non li elimina l'utente stesso.

Nessuna ri-migrazione. Nessun downtime. Gli utenti continuano a usare Outlook mentre la correzione avviene in background.

La tariffazione prevede un pagamento unico basato sul volume, senza abbonamento. I dettagli sono disponibili direttamente sul sito.

Scenari correlati da conoscere

Se si gestiscono più migrazioni in parallelo, o se si è un MSP che amministra clienti che lasciano Zoho, è opportuno sapere che lo stesso problema si verifica durante migrazioni da altre piattaforme verso Exchange Online. La meccanica è identica: la copia riceve la data che lo strumento trasmette, indipendentemente dalla sorgente.

Per le migrazioni da Google Workspace, da Exchange on-premises, o tramite strumenti come BitTitan MigrationWiz o CloudM, gli articoli dedicati sul blog di Redate.io descrivono i comportamenti specifici di ciascuno strumento. L'articolo Date email sbagliate dopo migrazione Exchange Online offre una panoramica di tutti gli scenari che riguardano questo tenant.

Se la migrazione include caselle condivise o risorse Exchange (sale, attrezzature), il problema è identico e gli stessi strumenti di correzione si applicano. Le guide di correzione IMAP verso Exchange sul sito Redate.io descrivono in dettaglio i passaggi per connettersi al proprio tenant.

Per i team che usano imapsync specificamente per lasciare Zoho, l'articolo imapsync: date non conservate documenta le opzioni di configurazione di imapsync e da dove vengono davvero le date sbagliate.

Le date della migrazione da Zoho sono ancora visualizzate in modo errato in Outlook? Esegua una scansione gratuita delle caselle su Redate.io per misurare l'entità esatta del problema prima di decidere come intervenire.