Migrazione iCloud verso Office 365: date email sbagliate

9 min

Una migrazione che rompe sistematicamente le date

Ha appena finito di trasferire la posta iCloud verso Office 365. Le email ci sono, le cartelle sono al loro posto, tutto sembra perfetto. Il lunedi mattina arriva il primo reclamo: "Tutte le mie email vecchie mostrano la data di oggi." Poi un secondo. Poi dieci.

Non è un bug isolato. La migrazione da iCloud Mail verso Office 365 è uno degli scenari piu documentati di corruzione delle date email, per ragioni tecniche molto precise legate al comportamento di Apple Mail, al protocollo IMAP e al modo in cui Microsoft 365 gestisce i messaggi in ingresso.

Perché iCloud verso Office 365 rompe le date

Per capire il problema, bisogna distinguere tre cose che molte persone (inclusi amministratori IT esperti) tendono a confondere: l'intestazione Date:, l'INTERNALDATE IMAP e la data di creazione del file.

L'intestazione Date: (RFC 2822)

Ogni email contiene un'intestazione Date: che indica quando il messaggio è stato inviato. Questa intestazione è incorporata nel corpo grezzo del messaggio e in teoria non cambia mai. È la data "originale" nel senso stretto del termine.

L'INTERNALDATE IMAP

Il protocollo IMAP (definito nella RFC 3501) associa a ogni messaggio un metadato distinto chiamato INTERNALDATE. È questo valore che la maggior parte dei client email usa per ordinare e visualizzare i messaggi nella casella di posta, non l'intestazione Date:. Outlook in particolare si affida molto all'INTERNALDATE per la visualizzazione e l'ordinamento.

Il problema? Quando uno strumento di migrazione copia un'email da un server IMAP a un altro, dovrebbe idealmente preservare questo INTERNALDATE. In pratica, non è sempre cosi che va.

Il comportamento particolare di Apple Mail

Apple Mail, quando sincronizza i messaggi da iCloud, a volte usa la data di creazione del file lato server come riferimento per l'INTERNALDATE. Non è un bug in senso stretto, è un'interpretazione della specifica IMAP che diverge da quanto fanno altri client. (Tra l'altro, se ha mai provato a fare debug di un problema di INTERNALDATE leggendo le RFC IMAP grezze, sa bene che la specifica lascia un margine di interpretazione piuttosto ampio su questo punto.)

Risultato: quando si esporta o si migra da iCloud tramite Apple Mail, gli INTERNALDATE dei messaggi possono già essere errati prima ancora di arrivare in Office 365.

I tre metodi di migrazione da iCloud e le loro insidie

Migrazione IMAP diretta

Il metodo piu comune consiste nel configurare iCloud come sorgente IMAP e Office 365 come destinazione, poi usare uno strumento di migrazione (imapsync, MigrationWiz, o uno strumento sviluppato internamente). Lo strumento si connette ai due server e copia i messaggi.

Il problema qui è duplice. Prima di tutto, i server IMAP di Apple hanno limiti di velocità che costringono gli strumenti a fare pause, creando finestre temporali in cui le connessioni si chiudono e riaprono, il che può generare INTERNALDATE indesiderati. Inoltre, ogni messaggio copiato via IMAP APPEND verso Exchange Online riceve per impostazione predefinita una data di deposito corrispondente al momento della migrazione, a meno che lo strumento non passi esplicitamente l'INTERNALDATE originale nel comando di inserimento.

Alcuni strumenti lo fanno correttamente. Altri, non in modo sistematico. E su una casella di 40.000 messaggi, anche un tasso di errore del 2% rappresenta 800 email con la data sbagliata.

Per le migrazioni tramite imapsync, si veda anche: correggere le date di migrazione imapsync in Microsoft 365.

Esportazione .mbox o .eml e successivo import

Alcuni utenti esportano le email iCloud tramite Apple Mail nel formato .mbox, poi cercano di importarle in Outlook. È un metodo artigianale che produce risultati variabili.

Il formato .mbox codifica le email come una sequenza di messaggi testuali. Le date sono presenti nelle intestazioni Date: individuali, ma la riga di separazione tra i messaggi ("From ") include una data che può essere interpretata come data di creazione da alcuni importatori. Outlook, quando importa un .mbox convertito in .pst, a volte usa questa data di separazione invece dell'intestazione Date: del messaggio stesso.

Il trascinamento tramite Outlook

Ecco il metodo che causa piu danni. Un utente configura entrambi gli account in Outlook (iCloud e Office 365), poi trascina i messaggi da una cartella all'altra. Sembra semplice. È un disastro per le date.

Quando Outlook sposta un messaggio tramite trascinamento tra due account IMAP, in realtà genera un nuovo file .EML, lo inserisce nell'account di destinazione e cancella l'originale. Questo nuovo file eredita la data di creazione del file Windows, ovvero il momento esatto del trascinamento. L'intestazione Date: originale è ancora presente nel corpo del messaggio, ma l'INTERNALDATE registrato sul server Exchange Online corrisponde alla data dell'operazione. Outlook mostra quindi questa data di migrazione per tutti i messaggi spostati.

Per essere precisi, questo comportamento varia a seconda della versione di Outlook. Dal aggiornamento di Outlook dell'autunno 2023, il comportamento è leggermente migliorato per alcuni scenari, ma il trascinamento tra account rimane una fonte documentata di corruzione delle date.

Cosa visualizzano Office 365 e Outlook

Exchange Online archivia le email con il loro INTERNALDATE. Outlook Desktop legge questo INTERNALDATE per visualizzare la data nella colonna "Ricevuto" e per ordinare la casella di posta. Se l'INTERNALDATE è stato sovrascritto durante la migrazione, Outlook mostra la data di migrazione, punto.

Outlook Web App (OWA) fa lo stesso. Non esiste una "vista alternativa" che mostri la data originale dell'intestazione Date:. Quello che si vede nella colonna della data è l'INTERNALDATE.

L'intestazione Date: originale è ancora lì, intatta, leggibile se si visualizzano le intestazioni grezze di un messaggio. Ma nessuna visualizzazione normale la mostra. È questa la frustrazione centrale del problema: l'informazione corretta esiste, ma è inaccessibile senza una correzione tecnica.

Quello che il supporto Microsoft non risolve

Se si apre un ticket con il supporto Microsoft per questo problema, ecco quello che si ottiene probabilmente: una conferma che le date visualizzate corrispondono agli INTERNALDATE archiviati, un suggerimento di verificare le impostazioni di ordinamento in Outlook e, eventualmente, un rimando allo strumento di migrazione usato.

Non è malafede. Microsoft semplicemente non dispone di uno strumento nativo per correggere retroattivamente gli INTERNALDATE di migliaia di messaggi già acquisiti in Exchange Online. La correzione richiede di accedere ai messaggi individualmente, analizzare le loro intestazioni e ricostruire i metadati di data, il che va oltre il perimetro del supporto standard.

Il supporto iCloud, da parte sua, considera che i messaggi siano stati esportati correttamente e che il problema sia lato destinazione. I due supporti si rimandano la palla, e l'utente si ritrova con 12.000 email datate al giorno della migrazione.

Il problema di scala

Capire perché le date sono rotte è una cosa. Correggerle manualmente su una casella di produzione è un'altra.

Alcuni amministratori IT tentano di scrivere script per la correzione. L'idea di base non è difficile da concettualizzare, ma l'esecuzione su volumi reali pone problemi che gli script fatti in casa non gestiscono bene:

  • Le email firmate con S/MIME o cifrate con PGP non possono essere modificate senza invalidare la firma crittografica
  • I messaggi con strutture multipart/alternative complesse (HTML + testo semplice + allegati annidati) sono fragili da manipolare
  • Le intestazioni codificate in non-ASCII (RFC 2047, in particolare per caratteri giapponesi, arabi o cirillici) possono essere corrotti da strumenti che non gestiscono correttamente questi encoding
  • Le quote API di Microsoft Graph e i limiti di velocità di Exchange Online (errore 429 Too Many Requests) bloccano gli script non progettati per la gestione del backoff esponenziale
  • Uno script che funziona correttamente su 500 email di test si interrompe alle 3 di notte all'ottomillesimo messaggio di una vera casella, senza meccanismo di ripresa

E la domanda che mette tutto in discussione: come si verifica che ogni email corretta sia intatta dopo la correzione? Che l'allegato sia ancora presente? Che il filo di discussione non sia rotto? Uno script fatto in casa generalmente non esegue questa verifica.

Come Redate.io gestisce le migrazioni da iCloud verso Office 365

Redate.io si connette direttamente a Office 365 tramite le autorizzazioni Microsoft 365 (Azure AD), senza richiedere accesso ai server iCloud. Le email sono già in Exchange Online nel momento in cui Redate interviene.

Il motore di correzione di Redate analizza la catena di intestazioni di ogni messaggio per identificare la data originale, distinguendo le intestazioni Received: aggiunte durante la migrazione dai metadati di data legittimi. Questa analisi include un pattern matching su firme di strumenti di migrazione noti, il che consente di identificare le intestazioni spurie anche quando non sono immediatamente evidenti.

Ogni email corretta viene verificata individualmente dopo l'elaborazione. Gli originali sono conservati in una cartella di backup visibile per 30 giorni, cosa che nessuno script fatto in casa fa di default. La scansione iniziale è gratuita e consente di quantificare esattamente il numero di email interessate prima di decidere se procedere alla correzione.

Redate supporta anche le migrazioni da Google Workspace verso Office 365 e le correzioni dopo migrazione cPanel. Si veda ad esempio: correggere le date email dopo migrazione Microsoft 365 o date email sbagliate dopo migrazione Exchange Online.

Prima la scansione, poi la correzione

Il punto di partenza consigliato per qualsiasi migrazione da iCloud verso Office 365 che ha prodotto date errate: avviare la scansione gratuita di Redate.io sulle caselle interessate. La scansione identifica con precisione quante email hanno un INTERNALDATE sospetto e in quali cartelle si trovano.

Richiede tra 12 e 45 minuti a seconda del volume, e fornisce un quadro chiaro dell'entità del problema prima di qualsiasi intervento. Per gli MSP che gestiscono piu caselle contemporaneamente dopo una migrazione, questa scansione per gruppi evita di correggere caselle che non ne hanno bisogno.

Se le date delle email sono errate dopo una migrazione da iCloud, iniziare con la scansione gratuita su Redate.io per misurare l'ampiezza del problema sulle caselle Office 365.

Articoli correlati