Nuovo Outlook: date sbagliate dopo migrazione, cause reali

Due Outlook, due comportamenti di fronte agli stessi messaggi

Se ha migrato delle caselle verso Microsoft 365 di recente e alcuni utenti si lamentano che tutte le email vecchie mostrano la stessa data (quella della migrazione), avrà forse notato qualcosa di strano: gli utenti sull'Outlook classico vedono a volte la data corretta nel riquadro di lettura, mentre quelli sul nuovo Outlook per Windows vedono sistematicamente la data di migrazione. Stessa casella. Stesse email. Risultati diversi.

Non è un bug in senso stretto. È una scelta architetturale che ha conseguenze dirette sul modo in cui le date vengono mostrate dopo una migrazione IMAP. Per capire cosa succede, bisogna entrare nei dettagli degli header email e del protocollo IMAP (non esattamente lettura da spiaggia, ma utile per capire perché nessuna modifica lato client basta a risolvere il problema).

L'INTERNALDATE IMAP: il vero responsabile

Quando un'email viene archiviata su un server IMAP, possiede due tipi di date che coesistono senza confondersi.

Il primo è l'header Date:, definito dalla RFC 2822. È la data scritta nel messaggio stesso, quella che il mittente ha impostato al momento dell'invio. Fa parte del corpo del messaggio e non cambia mai, qualunque percorso l'email faccia in seguito.

Il secondo è l'INTERNALDATE, un metadato gestito dal server IMAP, esterno al messaggio. È la data in cui il server ha registrato il messaggio. Durante una migrazione normale, gli strumenti seri preservano l'INTERNALDATE originale. Ma con una migrazione mal configurata, o con certi strumenti che non gestiscono correttamente questo metadato, l'INTERNALDATE viene azzerata alla data del giorno della migrazione. Il risultato: tutte le email migrate portano la stessa data di ricezione agli occhi del server.

(A dire il vero, se ha mai letto i log di imapsync o di MigrationWiz, saprà che esistono opzioni specifiche per tentare di preservare l'INTERNALDATE. Queste opzioni non funzionano sempre, e certi server di destinazione si rifiutano di rispettarle.)

Outlook classico: come legge le date

L'Outlook classico, cioè le versioni COM installate localmente (Outlook 2016, 2019, 2021 e il client desktop Microsoft 365 Apps), usa un meccanismo un po' più complesso per determinare quale data mostrare nell'elenco messaggi.

Per le email nella cartella Posta inviata si affida all'header Date:. Per le email ricevute, usa come priorità l'INTERNALDATE del server, ma in certi contesti (in particolare quando è coinvolta la cache OST o al primo caricamento nel riquadro di lettura) può anche leggere la catena degli header Received: per ricostruire una data d'origine approssimativa.

È per questa ragione che si osserva quel comportamento incoerente: l'Outlook classico può a volte mostrare la data corretta nel riquadro di lettura, perché legge l'header Date: originale del messaggio per l'anteprima dettagliata, anche se l'elenco messaggi usa l'INTERNALDATE corrotta. Ma attenzione, non è affidabile e non corregge nulla. L'ordinamento rimane rotto, le ricerche per data restano falsate.

Il nuovo Outlook: un'architettura radicalmente diversa

Il nuovo Outlook per Windows, distribuito progressivamente dalla fine del 2023, non è più un'applicazione COM. È sostanzialmente una Progressive Web App (PWA) basata sulla stessa base di codice di Outlook sul web (OWA). Questa riscrittura ha implicazioni profonde.

Il nuovo Outlook delega interamente la visualizzazione delle date all'API Microsoft 365. Non legge gli header Received:, non scava nella catena degli header per trovare una data d'origine, e non tenta alcuna ricostruzione lato client. Mostra semplicemente quello che il server restituisce: l'INTERNALDATE.

Risultato: se l'INTERNALDATE è stata corrotta durante la migrazione, il nuovo Outlook non ha esitazioni. Mostra la data di migrazione per ogni email interessata, senza eccezioni, senza sfumature. È un comportamento più coerente e prevedibile rispetto all'Outlook classico, ma rende il problema di migrazione immediatamente visibile e impossibile da ignorare.

Un admin che migra 300 caselle un venerdì sera scoprirà il lunedì mattina che tutti gli utenti sul nuovo Outlook vedono i loro archivi interi datati al week-end scorso. I ticket arrivano in fretta.

Perché nessun workaround lato client funziona

Molti admin provano soluzioni lato client prima di capire che il problema è nei dati del server. Ecco i tentativi classici, e perché falliscono.

Ordinare per "Data di invio" invece di "Data di ricezione"

L'ordinamento per data di invio in Outlook si basa sull'header Date: del messaggio, che è intatto. Quindi sì, questo ordinamento può funzionare. Ma è un cerotto, non una soluzione. Le ricerche per data restano rotte. Le regole basate sulla data restano inutilizzabili. E soprattutto, l'utente deve riconfigurare manualmente ogni cartella, ogni casella. Su 300 caselle, è irrealistico. Ordinare per data di invio non è una soluzione, e gli utenti finali non capiscono perché si chiede loro di cambiare le proprie abitudini.

Svuotare la cache Outlook o ricreare il profilo

Non tocca l'INTERNALDATE lato server. Dopo la ricreazione del profilo, Outlook risincronizza le email dal server e recupera esattamente gli stessi metadati corrotti. La cache non è il problema.

Usare OWA al posto del client

OWA e il nuovo Outlook condividono la stessa base dati. Se l'INTERNALDATE è corrotta sul server Exchange Online, OWA mostra esattamente la stessa data sbagliata. Cambiare client non cambia i dati.

Il problema è sul server, nei metadati di ogni messaggio. Nessuna azione lato client può correggere dati archiviati lato server.

La trappola degli header Received: perché complicano tutto

Quando uno strumento di migrazione copia un'email da un server all'altro via IMAP, il server di destinazione aggiunge automaticamente un header Received: in cima alla catena, con la data e l'ora dell'inserimento. È il comportamento normale dei server SMTP e IMAP conformi alle RFC.

Questi header si accumulano in ordine inverso rispetto al percorso dell'email. Il più recente è in cima. Alcuni client di posta leggono il primo Received: per stimare la data di ricezione, il che dà la data di migrazione invece della data originale.

Insomma, questo comportamento non è specifico di un singolo strumento. BitTitan MigrationWiz, CloudM, imapsync, GSMMO e persino una copia manuale IMAP tra due client Thunderbird producono tutti questo risultato. L'header Date: originale resta intatto nel messaggio. È precisamente questo che rende la correzione tecnicamente possibile. Ma l'INTERNALDATE è un metadato distinto gestito dal server e non può essere corretta semplicemente manipolando gli header del messaggio lato client.

Per approfondire questo meccanismo, l'articolo su IMAP INTERNALDATE e le date rotte dettaglia come questo metadato viene gestito a seconda dei server.

Quali strumenti di migrazione causano questo problema su Microsoft 365

La domanda torna spesso: tutti gli strumenti di migrazione provocano questo problema?

La risposta breve è che dipende dalla configurazione e dalla piattaforma di destinazione. Su Exchange Online / Microsoft 365, il server è particolarmente rigido nella gestione dell'INTERNALDATE. Anche gli strumenti che tentano di preservarla falliscono a volte, perché l'API Graph e EWS (Exchange Web Services) hanno comportamenti diversi a seconda del percorso di inserimento utilizzato.

BitTitan MigrationWiz è uno degli strumenti più diffusi per le migrazioni verso Microsoft 365, ed è anche uno di quelli i cui problemi di date sono meglio documentati. La pagina dedicata correggere le date BitTitan in Microsoft 365 copre le configurazioni specifiche da monitorare. CloudM e imapsync hanno le loro particolarità, documentate rispettivamente su correggere le date CloudM in Microsoft 365 e correggere le date imapsync in Microsoft 365.

Quello che accomuna tutti questi strumenti: l'header Date: originale sopravvive alla migrazione. È la base su cui una correzione è possibile.

Perché uno script fatto in casa è una cattiva idea

Capire il problema dà a volte l'illusione che la soluzione sia semplice. Non lo è, non alla scala di un ambiente di produzione.

Modificare i metadati di email archiviate su Exchange Online non è banale. L'API Graph di Microsoft impone limiti di frequenza rigidi (l'errore 429 Too Many Requests su un batch notturno arriva in fretta). La gestione delle email firmate S/MIME o cifrate PGP richiede attenzione particolare per non invalidare le firme. Le strutture multipart con allegati voluminosi aggiungono vincoli sui timeout di rete. E soprattutto: come verificare, email per email, che la correzione abbia funzionato senza alterare il contenuto o gli allegati?

Uno script che gira bene su 50 email di test non si comporterà allo stesso modo su una casella di 40.000 messaggi con 8 anni di cronologia. La probabilità che un caso limite rompa qualcosa aumenta con ogni migliaio di messaggi in più. E senza un meccanismo di rollback, un errore a metà percorso lascia la casella in uno stato incoerente.

Per un'analisi completa delle opzioni disponibili, si consulti anche correggere le date email dopo migrazione Microsoft 365.

Cosa fa concretamente Redate.io

Redate.io apre la casella Microsoft 365 quando l'utente accede con il proprio account Microsoft, senza portale né app da registrare, scansiona gratuitamente le email con date errate, poi applica un motore di correzione proprietario sui messaggi identificati. Il pipeline di analisi multi-stadio esegue una corrispondenza su centinaia di firme di strumenti di migrazione noti, una validazione di conformità RFC e un'analisi della catena di header per ricostruire i metadati di data corretti.

Ogni email corretta viene verificata singolarmente. Redate.io non elimina mai gli originali: restano in una cartella visibile della casella finché non vengono eliminati. Il modello tariffario è un pagamento unico per casella, senza abbonamento.

Il nuovo Outlook mostra poi le date corrette, perché i dati del server sono corretti, non mascherati.

Ha caselle interessate sul nuovo Outlook? Avvii una scansione gratuita su Redate.io per identificare esattamente quante email sono coinvolte prima di decidere come procedere.