CloudM Migrate: correggere le date email sbagliate

Il problema di date CloudM Migrate di cui nessuno avvisa

CloudM Migrate ha finito il lavoro. La dashboard mostra 100 % completato, tutti gli utenti migrati, zero errori. Il ticket del progetto viene chiuso e si passa al prossimo cliente.

Una settimana dopo, il responsabile IT chiama. "Perche ogni email nella mia casella mostra il 2 aprile?"

Non alcune email. Tutte. Cinque anni di corrispondenza con i clienti, documenti legali, registri HR, ordini d'acquisto del 2020, tutto con la data in cui CloudM ha eseguito la migrazione. I messaggi ci sono, il contenuto e intatto, gli allegati sono a posto. Ma le date sono sbagliate su ognuno.

Non e 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 entrata. Ma saperlo non aiuta il cliente la cui casella di posta e diventata impossibile da ordinare cronologicamente.

Come CloudM trasferisce effettivamente i messaggi email

CloudM Migrate si connette alle piattaforme di origine e 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 o l'API Microsoft Graph, a seconda del percorso di migrazione.

Quando CloudM legge un messaggio dall'origine, ottiene il contenuto completo RFC 2822, 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 e stata inviata per la prima volta) arriva intatto. Cosi come tutti gli header Received: originali che tracciano il percorso di consegna del messaggio.

Il problema si verifica alla destinazione. Quando CloudM scrive quel messaggio nella casella di posta di destinazione, il server di destinazione lo tratta come una nuova consegna. Appone un header Received: fresco con la data e l'ora correnti, e imposta l'INTERNALDATE (il timestamp che IMAP usa per l'ordinamento) al momento dell'inserimento.

Ecco come appare la catena di header dopo una migrazione CloudM verso Microsoft 365:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

L'header del 2019 e ancora li. L'header Date: originale dice ancora 23 settembre 2019. Ma Outlook legge l'header Received: piu recente per determinare l'ordine di visualizzazione, e quello dice 2 aprile 2026.

L'impostazione "Strip Received Headers" di CloudM

CloudM offre un'impostazione per affrontare questo problema. Nelle Impostazioni Avanzate della piattaforma di destinazione, sotto Message Options, c'e un interruttore "Strip Received Headers". Quando attivato, CloudM rimuove gli header Received prima di inserire il messaggio e li sostituisce con un singolo header che corrisponde all'header Date: dell'email.

Sembra risolvere tutto, vero? Non proprio.

Innanzitutto, bisogna conoscere questa opzione prima di eseguire la migrazione. La maggior parte degli amministratori scopre il problema delle date dopo che la migrazione e completa. A quel punto, i messaggi sono gia nella destinazione con date sbagliate. Rieseguire CloudM con l'impostazione attivata crea solo duplicati, non corregge cio che c'e gia.

In secondo luogo, questa impostazione ha una limitazione rigida quando Google Workspace e la destinazione. La documentazione di Google stessa lo conferma: Gmail riscrive sempre gli header Received: sui messaggi inseriti tramite API, timbrandoli con il timestamp di inserimento. Si tratta di una restrizione a livello di piattaforma che CloudM non puo aggirare. Anche con "Strip Received Headers" attivato, Google Workspace aggiunge il proprio header Received: con la data di migrazione.

Per le destinazioni Microsoft 365, l'impostazione funziona meglio in teoria, ma la pipeline di trasporto di M365 ha un comportamento proprio. Exchange Online puo comunque impostare l'INTERNALDATE in base alla propria elaborazione di consegna, a seconda di come il messaggio entra nel sistema.

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. CloudM legge tramite l'API Gmail e scrive su Exchange. Il livello di trasporto di M365 appone nuovi header Received.
• Microsoft 365 verso Google Workspace: Le date si rompono. Anche con Strip Received Headers, l'API di Google riscrive l'header Received con la data di 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, il tenant Google di destinazione timbra sempre la data di migrazione sui messaggi in entrata.
• Exchange on-premises verso Microsoft 365: Di solito si rompe tramite il percorso IMAP. Se CloudM usa EWS su entrambi i lati, la conservazione delle date e piu affidabile ma non garantita.
• Origine IMAP (generica) verso qualsiasi destinazione: Le date si rompono. Quando CloudM si connette a un server IMAP generico come origine, la destinazione aggiunge comunque i propri header di consegna.

La parte delicata? La dashboard di migrazione di CloudM non segnala nulla di tutto cio. 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 e riuscita. E tecnicamente e cosi. I messaggi sono stati trasferiti. Le date, in effetti, non hanno superato il viaggio.

CloudM Managed vs. Self-Service: 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 consente di distribuire server di migrazione primari e secondari nella propria rete, Google Cloud, Azure o AWS.

Alcuni MSP presumono che l'opzione self-hosted offra maggiore controllo sulla gestione delle date, dato che si amministrano direttamente i server di migrazione. Non e cosi. Il problema delle date si verifica al server di destinazione, non sui nodi di elaborazione di CloudM. Che la farm di migrazione funzioni nel cloud di CloudM o nella propria VM Azure, il server di posta di destinazione timbra comunque la data di migrazione su ogni messaggio che riceve.

CloudM offre anche una "Serviced Migration" completamente gestita, dove il loro team gestisce il progetto dall'inizio alla fine. Stesso risultato per le date. L'ingegneria e identica, a dire il vero cambiano solo le mani sulla tastiera. Ha mai pagato per un servizio premium e ottenuto la stessa limitazione del piano gratuito? E esattamente quella sensazione.

La complicazione degli header Date non validi

C'e un altro comportamento specifico di CloudM che peggiora le cose. Quando CloudM incontra un'email di origine con un header Date: 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 persino 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 sotto "Possible Changes to Migrated Items" ma non specifica quale 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 da server di posta piu vecchi, sistemi automatizzati o mittenti internazionali con particolarita nella formattazione del fuso orario). Dopo la modifica di CloudM piu la riscrittura dell'header Received da parte del server di destinazione, questi messaggi finiscono con date che non hanno alcuna somiglianza con la realta.

Perche le correzioni manuali non scalano dopo CloudM

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

Ecco la realta di questo approccio. Si parla 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: ha aggiunto CloudM o il server di destinazione, gestire i casi limite (messaggi firmati S/MIME dove la modifica degli header rompe la firma, contenuti crittografati PGP, strutture MIME multipart con boundary annidati, header non-ASCII codificati RFC 2047 da mittenti giapponesi o coreani), e fare tutto questo senza perdere un singolo allegato o rompere il threading delle email.

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

E la vera domanda che la maggior parte degli amministratori non pone fino a quando non e troppo tardi: come si verifica che ogni messaggio corretto e 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 scansiona alla ricerca di email che portano la firma della data di migrazione CloudM. La scansione e 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 che identifica pattern di migrazione specifici di CloudM attraverso la catena Received. 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'integrita del messaggio rispetto all'originale prima che il processo prosegua.

Le email originali sono conservate in una cartella di backup visibile Redate.io - Originals per 30 giorni. Se qualcosa deve essere annullato, gli originali sono li 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 che si tratti di correggere 1 casella o 500. Il problema di date che CloudM ha lasciato non deve diventare una caratteristica permanente dell'ambiente di posta del cliente.

Guide di correzione per piattaforma per migrazioni CloudM

Il processo di correzione si adatta alla piattaforma di destinazione. Redate.io gestisce le specificita di ogni piattaforma automaticamente, ma per i dettagli sulla 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 approfondita del perche questo accade con tutti gli strumenti di migrazione (non solo CloudM), consulti perche le email mostrano date sbagliate dopo la migrazione.

Migrato con CloudM e bloccato con date sbagliate su ogni email? Esegua una scansione gratuita per vedere esattamente quanti messaggi sono interessati e quanto costa correggerli.