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. È il comportamento atteso, ma mal documentato, di qualsiasi migrazione IMAP verso Exchange Online. 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 la migrazione IMAP corrompe 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, alla ricezione di ogni messaggio, genera una nuova intestazione Received: che aggiunge in testa al messaggio. Questa intestazione riporta la data e l'ora esatta dell'inserimento, ovvero la data della migrazione. Alcuni strumenti tentano di preservare l'INTERNALDATE originale passandolo come parametro durante l'inserimento. Altri non lo fanno, o lo fanno in modo errato, e in quel caso Exchange Online assegna automaticamente la data di ricezione come INTERNALDATE.

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, il problema riguarda principalmente le migrazioni verso server che aggiungono sistematicamente un'intestazione Received: a ogni messaggio in entrata, che è esattamente il comportamento di Exchange Online. Anche se il Zoho Migration Wizard passa la data originale, l'intestazione Received: generata da Exchange Online finisce in prima posizione nella catena, e Outlook la usa per determinare "quando è arrivata l'email".

Gli amministratori che usano strumenti IMAP generici come imapsync per lasciare Zoho incontrano esattamente lo stesso problema, a volte anche peggio, perché la configurazione predefinita di imapsync non è ottimizzata per Exchange Online. (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

Redate.io si connette al tenant Microsoft 365 tramite le autorizzazioni Azure AD standard, senza accesso admin globale. 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, identifica le firme specifiche degli strumenti di migrazione Zoho (che si tratti del Zoho Migration Wizard o di imapsync configurato per un'uscita da Zoho), e ricostruisce i metadati di data tramite un pipeline di validazione multi-fase. Ogni email corretta viene verificata individualmente: integrità del contenuto, preservazione degli allegati, conformità RFC. Gli originali vengono conservati in una cartella di backup accessibile per 30 giorni.

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: l'intestazione Received: generata da Exchange sovrascrive l'INTERNALDATE 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 perché non bastano a evitare il problema su Exchange Online.

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.