Hosting condiviso verso Microsoft 365: il problema nascosto delle date

Il problema che nessuno Le ha segnalato

Ha appena completato la migrazione della posta elettronica da OVH, Infomaniak, Ionos o o2switch verso Microsoft 365. L'assistente di migrazione dell'EAC (Exchange Admin Center) ha lavorato tutta la notte, tutto è verde, le caselle sono piene. Lunedì mattina, primo ticket: "Tutte le mie email vecchie hanno la data di oggi." Poi un secondo. Poi dieci.

Non è un bug di Microsoft 365. Non è nemmeno un caso. È il risultato meccanico di una migrazione IMAP, e nel caso di un hosting condiviso il problema è spesso due volte più grave rispetto a una migrazione classica. Ecco perché.

Come IMAP gestisce le date (e dove si rompe tutto)

Ogni email archiviata su un server IMAP ha due tipi distinti di datazione. Da un lato, l'intestazione Date: (definita dalla RFC 2822), presente nel corpo del messaggio stesso, che indica quando il messaggio è stato inviato o ricevuto. Dall'altro, l'INTERNALDATE, un metadato a livello di server che indica la data in cui quel messaggio è stato depositato nella casella. È questo valore che client come Outlook usano di default per ordinare e visualizzare le email.

(A dire il vero, se ha mai provato a leggere le intestazioni grezze di un'email nell'EAC, sa che non è esattamente una lettura rilassante. Ci sono facilmente venti o trenta righe di intestazioni prima di arrivare al contenuto.)

Quando uno strumento di migrazione IMAP trasferisce un messaggio da una casella a un'altra, deve ricreare questo INTERNALDATE sulla destinazione. Alcuni strumenti lo fanno correttamente. Molti no, o lo fanno con limitazioni. E i server di ricezione hanno voce in capitolo: Exchange Online, per esempio, mantiene ciò che le viene fornito: quando una copia porta con sé la sua data originale, Exchange Online la conserva. Quindi, quando le date risultano sbagliate, è lo strumento di migrazione a doversi verificare, non Microsoft 365.

Risultato: ogni email migrata sembra essere stata "ricevuta" il giorno della migrazione. Poco importa che risalga al 2019.

Lo scenario in due fasi: perché gli hosting condivisi peggiorano tutto

Qui la situazione diventa davvero problematica per le migrazioni da hosting condivisi come OVH, Infomaniak, Gandi, Ionos o o2switch.

Questi provider utilizzano in genere server condivisi Postfix, Dovecot o cPanel con configurazioni IMAP standard. Molte PMI vi hanno accumulato anni di email, a volte dal 2010 o 2012. Quando decidono di passare a Microsoft 365, la migrazione avviene spesso in due tempi.

Fase 1: la prima corruzione (prima ancora di Microsoft 365)

In molti casi, le email hanno già subito una prima migrazione. L'azienda ha cambiato hosting condiviso una o due volte nel corso degli anni: da Gandi verso OVH nel 2018, poi da OVH verso Infomaniak nel 2022, per esempio. Ogni trasferimento IMAP ha potuto azzerare l'INTERNALDATE originale riportandola al giorno del trasferimento (quando lo strumento non ha trasmesso la data originale), e alcuni strumenti lasciano anche proprie intestazioni di migrazione, datate quel giorno.

Quando le email arrivano su Microsoft 365, portano quindi già delle cicatrici. L'intestazione Date: originale è intatta (fa parte del corpo del messaggio, nessuno la tocca), ma i metadati di data sono già stati corrotti una prima volta.

Fase 2: la seconda corruzione durante il passaggio a Exchange Online

Lo strumento di migrazione IMAP dell'EAC, o un tool di terze parti come BitTitan MigrationWiz configurato in modalità IMAP, acquisisce allora queste email già danneggiate. Se anche questo strumento non trasmette la data originale di ciascuna email, Exchange Online la registra con la data del trasferimento, e questa diventa la "data di ricezione" mostrata da Outlook.

Un'email inviata nel marzo 2017 può quindi portare due livelli di date sbagliate: le intestazioni di migrazione lasciate dal trasferimento del 2022, e la data di ricezione della migrazione verso Microsoft 365 del 2024. Outlook mostra 2024. L'utente vede 2024. È sbagliato su due livelli.

Per essere precisi, non è sistematicamente l'intestazione Received: più recente a essere usata. Outlook determina la data visualizzata combinando l'INTERNALDATE registrato da Exchange Online e le intestazioni presenti. Ma ogni volta che lo strumento di migrazione non trasmette le date originali, il passaggio a Exchange Online aggiunge un nuovo livello di errori sopra quello precedente.

Strumenti di migrazione e provider: le combinazioni a rischio

Alcune combinazioni ricorrono spesso nelle migrazioni da hosting condivisi:

• OVH / Infomaniak / Ionos + strumento IMAP dell'EAC: lo strumento nativo Microsoft è comodo ma noto per non preservare correttamente le date durante migrazioni IMAP voluminose.
• cPanel (o2switch, LWS, ecc.) + BitTitan MigrationWiz in modalità IMAP: MigrationWiz in modalità IMAP aggiunge le proprie intestazioni di migrazione. Il risultato è documentato, tra l'altro, nella pagina correggere le date di migrazione BitTitan in Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync è uno strumento potente ma la sua gestione dell'INTERNALDATE dipende dalla configurazione. Senza l'opzione appropriata, le date non vengono preservate. Vedere anche imapsync: date non conservate.
• Qualsiasi migrazione manuale tramite trascinamento in Outlook: se qualcuno ha copiato intere cartelle facendo drag-and-drop tra due account configurati in Outlook, l'INTERNALDATE di ogni email viene riscritto alla data della copia. Senza eccezioni.

Il denominatore comune: tutti questi metodi producono email in Exchange Online la cui data visualizzata in Outlook non corrisponde più a nulla di reale.

Perché "correggere da soli" è una cattiva idea su larga scala

Capire il problema è una cosa. Correggere 8.000 email distribuite in 40 caselle Exchange Online, su account con strutture di cartelle complesse, email firmate S/MIME, allegati voluminosi e thread annidati, è un'altra cosa.

Uno script PowerShell che sembra funzionare su dieci email di test può fallire silenziosamente al messaggio numero 4237 a causa di un boundary MIME corrotto o di un'intestazione codificata in RFC 2047 (quel formato =?UTF-8?B?...?= per i caratteri non-ASCII nei nomi dei mittenti). Senza un meccanismo di verifica individuale, non lo si saprà. Si avrà solo un'email persa.

I rischi concreti del fai-da-te su questo tipo di migrazione:

• Messaggi duplicati se la logica di inserimento fallisce a metà processo
• Allegati mancanti se la struttura multipart viene ricostruita male
• Thread spezzati in Outlook (le conversazioni si basano su intestazioni References: e In-Reply-To: che possono essere modificate)
• Errori 429 (Too Many Requests) dell'API Microsoft Graph alle 3 di notte, che interrompono l'elaborazione senza rollback
• Nessun modo semplice per verificare che tutte le 8.000 correzioni siano state applicate correttamente

E nel caso specifico delle migrazioni da hosting condivisi, c'è una difficoltà aggiuntiva: le email portano più livelli di intestazioni Received: spurie, non solo uno. Uno script semplice che rimuove "l'ultimo Received:" non basta. Occorre analizzare la catena completa per identificare quale intestazione corrisponde a quale migrazione, e quale rappresenta davvero la data di ricezione originale.

Cosa fa Redate.io in modo diverso

Ogni utente accede con il proprio account Microsoft, e Redate.io apre così la sua casella con l'accesso che quel login concede. La scansione iniziale è gratuita: Redate.io identifica tutte le email la cui data visualizzata non corrisponde alla data reale, e fornisce una stima precisa per casella.

La correzione si basa su un motore proprietario che analizza la catena completa di intestazioni di ogni messaggio, indipendentemente dallo strumento di migrazione usato, e ricostruisce i metadati di data correttamente, anche quando più livelli di corruzione si sovrappongono. Ogni email corretta è verificata individualmente. Gli originali restano in una cartella di backup visibile della casella, finché non è l'utente stesso a eliminarli.

Per le migrazioni da hosting condivisi, il pipeline di analisi multi-fase di Redate.io gestisce esplicitamente gli scenari di doppia corruzione: non si limita a guardare l'ultima intestazione Received:, risale la cronologia completa per ritrovare la data di ricezione reale. Vedere anche come correggere le date dopo migrazione Microsoft 365 in generale, e la guida specifica sugli INTERNALDATE rotti in IMAP per comprendere la meccanica sottostante.

Prima di migrare o dopo: due momenti per agire

Due situazioni, due approcci.

Non ha ancora migrato. La buona notizia: è possibile limitare i danni. Alcuni strumenti di migrazione (MigrationWiz in modalità Exchange, CloudM con le opzioni giuste) preservano meglio le date di altri. Ma anche nel migliore dei casi, una migrazione da un hosting condiviso senza uno storico pulito lascerà probabilmente delle tracce. Si preveda un passaggio da Redate.io dopo la migrazione, prima di consegnare le caselle agli utenti.

Ha già migrato e i ticket arrivano. Redate.io corregge le caselle esistenti in Microsoft 365, indipendentemente da quando è avvenuta la migrazione. La scansione fornirà un'immagine precisa dello stato reale di ogni casella prima di qualsiasi intervento. Consulti anche la checklist migrazione email per evitare gli stessi problemi in futuro.

Ha migrato da OVH, Infomaniak, Ionos o o2switch verso Microsoft 365 e le date sono sbagliate? Crei un account Redate.io per scansionare le caselle gratuitamente e vedere esattamente l'entità del problema prima di decidere qualsiasi cosa.