CloudM Migrate: correggere le date email sbagliate

Il problema delle date CloudM Migrate di cui nessuno avvisa

CloudM Migrate ha finito il lavoro. La dashboard mostra il 100% completato, tutti gli utenti migrati, zero errori. Lei chiude il ticket del progetto e passa al cliente successivo.

Poi, una settimana dopo, il direttore IT chiama. "Perché ogni email nella mia casella di posta dice 2 aprile?"

Non alcune email. Tutte. Cinque anni di corrispondenza con i clienti, documenti legali, registri delle risorse umane, ordini d'acquisto del 2020, tutte con la data in cui CloudM ha eseguito la migrazione. I messaggi sono lì, il contenuto è intatto, gli allegati sono a posto. Ma le date sono sbagliate su ognuno di essi.

Non è un bug di CloudM. La documentazione di supporto di CloudM lo riconosce apertamente. Il problema si trova all'intersezione tra il modo in cui gli strumenti di migrazione trasferiscono i messaggi e il modo in cui i server di posta di destinazione gestiscono i metadati delle email in arrivo. Ma saperlo non aiuta il cliente la cui casella di posta è appena diventata impossibile da ordinare.

Come CloudM trasferisce effettivamente i messaggi email

CloudM Migrate si connette alle piattaforme di origine e di destinazione tramite le loro API. Per Google Workspace, questo significa un account di servizio con delega a livello di dominio (configurato nella Console di amministrazione Google, sotto Sicurezza > Controlli API). Per Microsoft 365, utilizza Exchange Web Services oppure l'API Microsoft Graph, a seconda del percorso di migrazione.

Quando CloudM legge un messaggio dall'origine, ottiene il contenuto RFC 2822 completo, inclusi tutti gli header originali e il corpo del messaggio. L'header Date: originale (quello che il server di posta del mittente ha timbrato quando l'email è stata inviata per la prima volta) arriva intatto. Così come tutti gli header Received: originali che tracciano il percorso di consegna del messaggio.

Il problema si verifica quando la copia viene scritta. La destinazione conserva la data che le viene trasmessa: Microsoft 365 e Gmail conservano la data originale quando la copia la porta con sé. Quando non la porta, la copia riceve come data il momento dell'inserimento. E su Google Workspace, ogni messaggio scritto tramite l'API Gmail riceve anche un nuovo header Received: datato al momento dell'inserimento.

Ecco cosa portano ancora gli header di una di quelle email dopo una migrazione CloudM verso Microsoft 365:

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

L'header Date: originale del 2019 è ancora lì, così come la catena originale di header Received:. Ma in Microsoft 365, la data che Outlook mostra come data di ricezione è il record della casella di posta stesso su quando è arrivata ogni email: se CloudM non ha trasmesso la data originale, quel record indica 2 aprile 2026.

L'impostazione "Strip Received Headers" di CloudM

CloudM offre effettivamente un'impostazione per affrontare questo problema. Nelle Impostazioni avanzate della piattaforma di destinazione, sotto Opzioni messaggio, c'è un interruttore "Strip Received Headers". Quando è attivato, CloudM rimuove gli header Received: prima di inserire il messaggio e li sostituisce con un unico header corrispondente all'header Date: dell'email.

Sembra risolvere tutto, no? Non esattamente.

Innanzitutto, bisogna conoscerla prima di eseguire la migrazione. La maggior parte degli amministratori scopre il problema delle date dopo che la migrazione è completa. A quel punto, i messaggi sono già nella destinazione con date sbagliate. Rieseguire CloudM con l'impostazione attivata crea solo dei duplicati, non corregge ciò che c'è già.

In secondo luogo, questa impostazione ha un limite rigido quando Google Workspace è la destinazione. La documentazione di Google stessa lo conferma: Gmail riscrive sempre gli header Received: sui messaggi inseriti tramite API, timbrandoli con il timestamp dell'inserimento. Si tratta di una restrizione a livello di piattaforma che CloudM non può ignorare. Anche con "Strip Received Headers" attivato, Google Workspace aggiunge il proprio header Received: con la data della migrazione.

Per le destinazioni Microsoft 365, l'impostazione conta meno: Microsoft 365 conserva la data che le viene trasmessa, quindi ciò che decide la data visualizzata è se CloudM trasmette o no la data originale di ogni email.

Quali migrazioni CloudM rompono le date (e quali no)

Non tutte le migrazioni CloudM producono date sbagliate. Il risultato dipende dalla combinazione origine-destinazione e dal percorso API specifico che CloudM utilizza:

• Google Workspace verso Microsoft 365: le date si rompono quando CloudM non trasmette la data originale. CloudM legge tramite l'API Gmail e scrive su Exchange, che conserva la data che le viene trasmessa.
• Microsoft 365 verso Google Workspace: le date si rompono. Anche con Strip Received Headers attivato, l'API di Google riscrive l'header Received con la data dell'inserimento. La documentazione di supporto di CloudM la chiama una "limitazione rigida della piattaforma".
• Google Workspace verso Google Workspace: le date si rompono. Cambi di dominio, consolidamenti di tenant, fusioni per acquisizione: ogni messaggio scritto tramite l'API Gmail riceve un header Received: datato alla migrazione.
• Exchange on-premises verso Microsoft 365: tutto dipende dalla data che CloudM trasmette, che la copia passi tramite IMAP o EWS.
• Origine IMAP (generica) verso qualsiasi destinazione: stessa regola: quando CloudM si connette a un server IMAP generico come origine, la copia mostra la data della migrazione ogni volta che la data originale non viene trasmessa alla destinazione.

La parte insidiosa? La dashboard di migrazione di CloudM non segnala nulla di tutto ciò. La barra di avanzamento si riempie, la colonna di stato dice "Completed", i conteggi degli elementi corrispondono. Dal punto di vista di CloudM, la migrazione è riuscita. E tecnicamente lo è. I messaggi sono stati trasferiti. Le date, semplicemente, non hanno superato il viaggio.

CloudM Managed vs. Self-Service: lo stesso problema di date

CloudM offre due modelli di distribuzione. La versione SaaS (CloudM Migrate ospitato) funziona interamente nell'infrastruttura di CloudM. La versione self-hosted permette di distribuire server di migrazione primari e secondari sulla propria rete, su Google Cloud, Azure o AWS.

Alcuni MSP presumono che l'opzione self-hosted offra maggiore controllo sulla gestione delle date, dato che i server di migrazione vengono amministrati direttamente. Non è così. Ciò che decide la data è quello che il motore di migrazione trasmette insieme a ogni messaggio, e quel motore è lo stesso ovunque venga eseguito. Che la farm di migrazione funzioni nel cloud di CloudM o sulla propria VM Azure, il risultato per le date è lo stesso.

CloudM offre anche una "Serviced Migration" completamente gestita, in cui il loro team si occupa del progetto dall'inizio alla fine. Stesso risultato per le date. L'ingegneria è identica, cambiano solo le mani sulla tastiera. Ha mai pagato per un servizio premium e ottenuto la stessa limitazione del piano gratuito? È esattamente questa la sensazione.

La complicazione dell'header Date non valido

C'è un altro comportamento specifico di CloudM che peggiora le cose. Quando CloudM incontra un'email di origine con un header Date: che non è conforme a RFC 822 (fuso orario malformato, giorno della settimana mancante, formato non standard), modifica l'header per garantire che il messaggio possa essere migrato.

Questo significa che alcune email perdono anche il loro riferimento di data originale. L'header Date: modificato potrebbe non corrispondere affatto alla data di invio reale. La documentazione di supporto di CloudM menziona questo comportamento come noto sotto "Possible Changes to Migrated Items", ma non specifica cosa diventi la data modificata.

Per una casella di posta con 12.000 messaggi accumulati in otto anni, potrebbero esserci centinaia di email con header Date leggermente non standard (specialmente messaggi provenienti da server di posta più vecchi, sistemi automatizzati o mittenti internazionali con particolarità nella formattazione del fuso orario). Dopo la modifica di CloudM, più una copia che non porta con sé la data originale, questi messaggi finiscono con date che non hanno alcuna somiglianza con la realtà.

Perché le correzioni manuali non scalano dopo CloudM

Si potrebbe correggere da soli? Tecnicamente, l'header Date: originale è ancora incorporato nella maggior parte dei messaggi (tranne quelli che CloudM ha modificato per conformità RFC). Alcuni amministratori hanno provato a scrivere script per correggere le date dopo una migrazione CloudM.

Ecco la realtà di questo approccio. Si tratta di connettersi a potenzialmente migliaia di caselle di posta, ciascuna con migliaia di messaggi. Per ogni email, bisogna analizzare l'intera catena di header, identificare quali header Received: sono stati aggiunti da CloudM o dal server di destinazione durante la scrittura tramite l'API di destinazione, gestire i casi limite (messaggi firmati S/MIME in cui la modifica degli header rompe la firma, contenuti crittografati PGP, strutture MIME multipart con boundary annidati, header non ASCII codificati secondo RFC 2047 provenienti da mittenti giapponesi o coreani), e fare tutto questo senza perdere un solo allegato o rompere il threading delle email.

Uno script che funziona su 50 email di test da una casella pulita non sopravviverà al contatto con un ambiente di produzione di 40.000 messaggi distribuiti su un decennio. Cosa succede quando si incontra un'email da 47 MB con sei allegati annidati? E i limiti di frequenza delle API (250 unità di quota per utente al secondo per Google, il throttling di Microsoft a circa 10.000 richieste ogni 10 minuti)? Qual è il piano di rollback quando qualcosa va storto al messaggio numero 8.347?

E la vera domanda che la maggior parte degli amministratori non si pone finché non è troppo tardi: come si verifica che ogni messaggio corretto sia effettivamente intatto?

Correggere le date di migrazione CloudM con Redate.io

Redate.io si connette direttamente alle caselle di posta interessate (Google Workspace, Microsoft 365 o IMAP) e analizza le email la cui data visualizzata non corrisponde alla loro data originale. L'analisi è gratuita e richiede un paio di minuti per casella, mostrando il conteggio esatto dei messaggi interessati prima di qualsiasi impegno.

La correzione utilizza un motore proprietario di analisi della catena di header, e non ha bisogno di sapere quale strumento ha eseguito la migrazione. Redate.io esegue una correzione mirata dei metadati senza alterare il contenuto del messaggio, preservando allegati, threading, etichette, cartelle e firme digitali. Ogni messaggio corretto passa attraverso una verifica individuale, controllando l'integrità del messaggio rispetto all'originale prima che il processo prosegua.

Le email originali vengono conservate in una cartella di backup visibile Redate.io - Originals finché non la elimina Lei stesso. Se qualcosa deve essere annullato, gli originali sono lì, nella casella di posta, non sepolti in qualche archivio esterno.

Per gli MSP che hanno usato CloudM sugli ambienti dei clienti, Redate.io gestisce correzioni multi-casella su larga scala, con la stessa verifica per messaggio sia che si corregga 1 casella o 500. Il problema delle date che CloudM ha lasciato non deve diventare una caratteristica permanente dell'ambiente di posta del cliente.

Guide specifiche per piattaforma per le migrazioni CloudM

Il processo di correzione si adatta alla piattaforma di destinazione. Redate.io gestisce automaticamente le specificità di ogni piattaforma, ma per i dettagli sulla propria configurazione:

• Correggere le date di migrazione CloudM in Gmail
• Correggere le date di migrazione CloudM in Outlook
• Correggere le date di migrazione CloudM in Google Workspace
• Correggere le date di migrazione CloudM in Microsoft 365

Per una spiegazione più approfondita del perché questo accade con tutti gli strumenti di migrazione, non solo CloudM, consulti perché le email mostrano date sbagliate dopo la migrazione.

Ha migrato con CloudM ed è bloccato con date sbagliate su ogni email? Esegua un'analisi gratuita per vedere esattamente quanti messaggi sono interessati e quanto costa la correzione.