Date email sbagliate dopo migrazione Exchange Online

Lo scenario classico del lunedi mattina

Ha appena completato la migrazione IMAP verso Exchange Online. Il batch si è concluso senza errori nel centro di amministrazione Exchange, le caselle sono sincronizzate, gli utenti riescono ad accedere. Venerdì sera chiude il computer con la sensazione del lavoro ben fatto.

Lunedì mattina, i ticket iniziano ad arrivare. "Tutte le mie email sono datate venerdì." "La cronologia della casella è inutilizzabile." "Mancano email vecchie." Non manca niente, in realtà: le email ci sono, ma Outlook le mostra tutte con la data di migrazione invece della data di invio originale. Un'email del 2019 appare datata venerdì scorso. Risultato: l'intera casella sembra contenere solo messaggi recenti.

È uno dei problemi più frustranti delle migrazioni IMAP verso Exchange Online, e Microsoft lo documenta in modo sistematicamente carente.

Perché la migrazione via EAC rompe le date

Quando si usa il centro di amministrazione Exchange (EAC) per configurare una migrazione IMAP da un server locale (Dovecot, Courier, Cyrus, UW-IMAP, poco importa), Exchange Online si connette al server sorgente via IMAP, recupera i messaggi e li inserisce nelle caselle di destinazione tramite il proprio pipeline di trasporto interno.

È qui che nasce il problema.

Ogni email che transita attraverso il pipeline di trasporto di Exchange riceve automaticamente un header Received: con timestamp. È un comportamento standard dei server SMTP e IMAP da decenni: ogni server che tocca un messaggio vi appone la propria firma temporale. Il problema è che Outlook (e in particolare Outlook per Windows, nelle versioni recenti) usa l'header Received: più recente come riferimento per la visualizzazione quando altri metadati sono ambigui.

L'header Date: originale (quello che indica quando l'email è stata davvero inviata, ai sensi della RFC 2822) è sempre presente nel messaggio. Non è stato eliminato. Ma si trova "oscurato" da questo nuovo header Received: aggiunto da Exchange durante l'iniezione.

Parallelamente, l'INTERNALDATE IMAP (il metadato che i server IMAP usano per datare i messaggi internamente e che pilota l'ordinamento nella maggior parte dei client) viene impostato alla data di iniezione, non alla data originale dell'email. Exchange Online non ha alcun modo nativo di preservare l'INTERNALDATE del server sorgente durante una migrazione batch via EAC.

EAC vs. strumenti di terze parti: una differenza importante

Bisogna distinguere due situazioni. Con strumenti come BitTitan MigrationWiz o CloudM Migrate, il problema esiste anche lì, ma questi strumenti hanno a volte opzioni di configurazione (parzialmente documentate, spesso nascoste nelle impostazioni avanzate) che tentano di preservare certi metadati di data.

La migrazione nativa via EAC, invece, non offre nessuna opzione di questo tipo. Microsoft non espone alcun parametro per controllare la preservazione dell'INTERNALDATE nel pipeline di batch migration. È una scatola nera: si configura il batch, lo si avvia, Exchange fa quello che vuole internamente. E quello che fa, sistematicamente, è datare i messaggi alla data della loro iniezione.

(Tra l'altro, se ha mai provato a leggere gli header grezzi di un'email migrata via EAC, sa che il campo Received: aggiunto da Exchange è riconoscibile tra mille: contiene riferimenti ai server interni Microsoft come *.protection.outlook.com o *.prod.exchangelabs.com, con un timestamp che corrisponde esattamente alla finestra di migrazione.)

Perché ricreare il batch non risolve niente

La reazione istintiva di molti amministratori IT di fronte a questo problema è pensare: "Se elimino le caselle migrate e rilancio il batch da zero, forse questa volta le date saranno corrette."

È comprensibile. Ma non funziona.

Il problema non sta nella configurazione del batch. Non sta in un parametro dimenticato. Sta nell'architettura stessa del pipeline di trasporto Exchange, che è identica ad ogni migrazione. Rilanciare il batch produrrà esattamente lo stesso risultato: gli stessi header Received: con la nuova data di migrazione, e gli stessi INTERNALDATE errati. Si sarà perso tempo e gli utenti saranno stati disturbati una seconda volta per niente.

Alcuni amministratori tentano anche di modificare i parametri di ordinamento in Outlook ("ordina per data di invio" invece di "data di ricezione"). L'ordinamento per data di invio non è una soluzione. È un cerotto. L'header Date: e l'INTERNALDATE restano errati per i client che non permettono questa impostazione, per OWA, per Outlook Mobile, e per qualsiasi applicazione di terze parti che accede alla casella via IMAP o EWS.

Cosa succede davvero negli header

Ecco un esempio semplificato di ciò che contiene un'email dopo migrazione via EAC. L'header originale:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@vecchiodominio.it
Subject: Report Q1 2019

Dopo la migrazione, il messaggio riceve in testa alla catena qualcosa come:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook vede questo header Received: per primo (viene aggiunto in cima al blocco di header), lo interpreta come la data più recente di trattamento del messaggio, e lo visualizza come data di ricezione. L'header Date: originale del 2019 è ancora lì, intatto, qualche riga più in basso. Ma Outlook non lo usa per la visualizzazione nella lista dei messaggi.

Per essere precisi: il comportamento varia leggermente a seconda delle versioni di Outlook. Le versioni post-2021 (e soprattutto il nuovo Outlook per Windows distribuito dalla fine del 2023) sono particolarmente sensibili a questo problema perché si affidano maggiormente ai metadati Exchange Graph che all'header Date: grezzo. Il che significa che migrazioni che non causavano problemi visibili con Outlook 2016 possono ora creare difficoltà con il nuovo Outlook.

Chi è davvero colpito

I server IMAP sorgente più comuni in questo tipo di migrazione sono Dovecot (molto diffuso in ambiente Linux/cPanel) e Courier. Entrambi espongono INTERNALDATE via IMAP che l'EAC non preserva. Se si migra da un server Exchange on-premises verso Exchange Online (migrazione ibrida o cutover), il comportamento è diverso perché Microsoft usa un protocollo di trasporto interno (MAPI/EWS) che preserva meglio i metadati. È la migrazione IMAP generica via EAC a creare il problema.

Gli utenti più colpiti sono quelli con caselle di posta con una storia lunga (5 anni e oltre) e un volume elevato di messaggi. Un utente con 300 email nella casella se ne rimette in fretta. Un direttore commerciale con 12.000 email ordinate per data, da cui dipende ogni giorno per ritrovare scambi con i clienti, è invece paralizzato.

Perché uno script artigianale è una cattiva idea qui

Alcuni amministratori IT che comprendono il problema tecnico sono tentati di scrivere uno script PowerShell o Python per correggere gli header manualmente. Il concetto di base può sembrare semplice una volta identificato il meccanismo. Ma la realtà di una correzione in produzione è un'altra storia.

Prima di tutto, i casi limite. Le email firmate S/MIME e i messaggi cifrati PGP hanno una struttura che non tollera la modifica degli header senza invalidare la firma. I messaggi multipart/alternative con boundary MIME mal formati (frequenti sui vecchi server Courier) possono essere corrotti da uno script che modifica il messaggio senza ricostruire correttamente la struttura. Gli header non-ASCII codificati secondo la RFC 2047 (nomi di mittenti con caratteri accentuati o giapponesi, per esempio) sono una fonte classica di errori.

Poi, il volume. Uno script che funziona su 50 email di test in ambiente di sviluppo non gestisce i limiti di frequenza dell'API Exchange Online in produzione. L'errore 429 Too Many Requests alle 2 di notte durante un batch di 8.000 messaggi, senza meccanismo di ripresa, significa una notte in bianco e potenzialmente messaggi duplicati o persi.

E soprattutto: come verificare che ogni email corretta sia intatta? Che nessun allegato sia stato troncato, che nessun thread di discussione sia rotto, che le etichette e le cartelle siano preservate? Senza un meccanismo di validazione individuale, ci si affida alla speranza che tutto sia andato bene.

La correzione delle date dopo migrazione è un problema che sembra uno script di 50 righe ma che ne richiede migliaia per essere affidabile in produzione.

Cosa fa Redate.io in modo diverso

Redate.io si connette a Exchange Online tramite le API Microsoft 365 (Azure Active Directory, permessi di delega a livello di tenant) e scansiona le caselle interessate per identificare le email i cui metadati di data sono stati corrotti dalla migrazione. Questa fase di scansione è gratuita e fornisce una visione precisa dell'entità del problema: numero di messaggi coinvolti, caselle interessate, intervallo di date corrotte.

Il motore di correzione proprietario di Redate.io elabora poi ogni email individualmente tramite un pipeline di analisi multi-stadio che include una corrispondenza di pattern su firme di strumenti di migrazione noti (incluso il pipeline di trasporto di Exchange Online), una validazione di conformità RFC, e una verifica dell'integrità strutturale del messaggio prima e dopo la correzione. Le email firmate S/MIME, le strutture MIME complesse, le codifiche non standard: tutte gestite da percorsi di elaborazione specifici.

Ogni messaggio corretto viene verificato individualmente. Gli originali sono conservati in una cartella di backup visibile per 30 giorni. Se qualcosa non va con un messaggio particolare, non viene modificato: Redate.io segnala l'anomalia invece di rischiare una corruzione.

La tarificazione è basata sul volume, con pagamento unico per casella. Nessun abbonamento, nessun costo ricorrente. Si corregge il problema una volta, e il gioco è fatto.

Per le migrazioni Exchange Online in particolare, Redate.io supporta la connessione tramite permessi applicazione Azure AD (senza dover creare credenziali individuali per ogni casella), il che rende il trattamento di grandi flotte di caselle molto più semplice da orchestrare per un amministratore IT o un MSP.

Se gestisce più clienti che hanno subito questo tipo di migrazione, consulti anche la guida completa sulla correzione delle date dopo migrazione Microsoft 365 per una panoramica dei diversi scenari coperti.

Le email ci sono, e anche le date originali. Avvii una scansione gratuita su Redate.io per vedere esattamente quanti messaggi sono interessati nelle Sue caselle Exchange Online, prima di decidere come procedere.