Migrazione Google Workspace verso GWS: date rotte

Lo scenario che nessuno sospetta

Ha appena completato la migrazione di un tenant Google Workspace verso un altro. Acquisizione di una società, cambio di dominio, fusione di due entità che coesistevano su account G Suite separati da anni. L'operazione è andata bene, le caselle sono al loro posto, gli utenti si connettono. Lunedì mattina, primo ticket: "Tutte le mie email hanno la stessa data." Poi un secondo. Poi dieci.

Istintivamente si pensa: dev'essere un problema IMAP, uno strumento mal configurato, qualcosa di strano. Non una migrazione Google verso Google. Eppure è esattamente lì che succede.

Questo scenario è probabilmente il meno documentato del settore. La maggior parte degli amministratori IT che lo incontra perde diverse ore a cercare una spiegazione lato client di posta, lato Outlook, lato impostazioni account, prima di rendersi conto che il problema è negli header delle email stesse.

Perché una migrazione Google verso Google rompe le date

Per capire cosa succede, bisogna tornare alla meccanica degli header email. Ogni messaggio RFC 2822 contiene un campo Date: originale, inserito dal client o dal server mittente al momento dell'invio. È la data "vera" dell'email, quella che corrisponde a quando il messaggio è stato scritto e spedito.

Ma esiste un altro meccanismo: l'INTERNALDATE IMAP. È un metadato memorizzato lato server che indica quando il messaggio è stato depositato nella casella. Ed è qui che le cose si fanno interessanti.

Quando uno strumento di migrazione trasferisce un'email da un tenant Google Workspace a un altro, passa attraverso il protocollo IMAP (anche se entrambi i server sono da Google). Il messaggio viene letto dalla sorgente, poi reinserito nella destinazione. Al momento di questo reinserimento, il server di destinazione aggiunge automaticamente un header Received: con il timestamp dell'operazione, ovvero la data di migrazione.

Ora, client di posta come Outlook usano il primo Received: della catena per visualizzare la data di un messaggio, non necessariamente il campo Date: originale. Risultato: tutte le email mostrano la data del giorno della migrazione.

Quali strumenti provocano il problema

Praticamente tutti gli strumenti usati per migrazioni inter-tenant Google Workspace sono coinvolti. Nessuna eccezione degna di nota:

• GSMMO (Google Workspace Migration for Microsoft Outlook): progettato originalmente per migrare da Exchange, ma usato in certi flussi GWS verso GWS.
• CloudM Migrate: molto diffuso tra gli MSP per le migrazioni inter-Google, aggiunge sistematicamente un Received: di migrazione. Vedi l'analisi dettagliata di CloudM.
• BitTitan MigrationWiz: stesso comportamento, documentato in questo articolo su BitTitan.
• imapsync: lo strumento open source per script di migrazioni IMAP, incluse quelle tra due tenant Google.
• Export/import manuali via Takeout + reimport IMAP: meno comuni, ma producono esattamente lo stesso effetto.

Il motivo è semplice: tutti questi strumenti funzionano come normali client IMAP. Non hanno accesso a una via "nativa" Google che preserverebbe i metadati. Anche se entrambi i tenant sono da Google, il trasferimento passa per il livello IMAP, e quel livello non sa di star parlando con se stesso.

La meccanica degli header Received nel dettaglio

(Tra l'altro, se ha mai provato a leggere gli header grezzi di un'email da Gmail o Outlook, sa che raramente è una lettura piacevole. Ma è lì che si nasconde tutta la verità.)

Un'email che ha viaggiato normalmente contiene una catena di header Received: in ordine inverso rispetto al percorso: l'ultimo server che ha toccato il messaggio è in cima. Dopo una migrazione, l'header di migrazione si trova quindi tutto in cima alla pila.

Ecco come appare in un messaggio migrato tramite CloudM da un tenant GWS a un altro:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <utente@nuovo-dominio.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Il campo Date: dice 2019. Il primo Received: dice ottobre 2024. Outlook legge il primo Received:. L'utente vede ottobre 2024 per un'email del 2019.

Il campo Date: originale è intatto. Non si è mosso. Questa è la buona notizia: il dato c'è, aspetta solo di essere usato correttamente.

Outlook e Gmail non si comportano allo stesso modo

È una precisazione importante. Gli utenti che accedono alle loro email tramite l'interfaccia web di Gmail vedono spesso le date corrette, perché Gmail usa in via prioritaria il campo Date: RFC 2822 per visualizzare i messaggi. Il problema è meno visibile lato web.

Al contrario, gli utenti che configurano la loro casella Google Workspace in Outlook tramite IMAP (o tramite la sincronizzazione Exchange ActiveSync) subiscono in pieno la data errata, perché Outlook si fida dell'INTERNALDATE IMAP, che riflette la data del primo Received: aggiunto durante la migrazione.

Correzione: per essere precisi, il comportamento di Outlook varia in base alla versione e alla modalità di connessione. Outlook 2019 e Microsoft 365 (le versioni recenti) usano l'INTERNALDATE quando si connettono in IMAP. Le versioni più vecchie possono avere comportamenti leggermente diversi. Ma in tutti i casi osservati in produzione, la migrazione GWS verso GWS tramite IMAP produce date errate in Outlook.

Di conseguenza, nelle organizzazioni che hanno migrato verso un nuovo tenant e mantengono utenti ibridi (alcuni su Gmail web, altri su Outlook), le segnalazioni dei ticket sono incoerenti. I team IT perdono tempo a capire perché "alcuni sono affetti e altri no", mentre la risposta è semplicemente: è il client di posta a fare la differenza.

Acquisizioni, fusioni, cambi di dominio: i casi più frequenti

Questo tipo di migrazione non è affatto raro. Ecco gli scenari che generano più ticket:

Acquisizione aziendale

Una società acquisita aveva il proprio tenant Google Workspace (dominio @vecchiazienda.com). Dopo l'acquisizione, tutto deve migrare verso il tenant della capogruppo (@gruppo.com). Le 250 caselle, gli archivi, gli 8 anni di storico email. BitTitan o CloudM vengono incaricati dell'operazione. Risultato: 2,4 milioni di email con la data del weekend di migrazione.

Cambio di dominio

Un'azienda rebranding passa da @vecchionome.it a @nuovonome.it. Stesso tenant Google, ma creazione di un nuovo tenant per ripartire da zero (scelta comune per evitare artefatti di configurazione). Migrazione delle caselle tramite imapsync o GSMMO. Le date si rompono esattamente allo stesso modo.

Consolidamento di filiali

Un gruppo con 4 filiali, ognuna sul proprio tenant G Suite storico, che decide di riunire tutto su un tenant unico. Quattro migrazioni in parallelo, quattro lotti di email con date corrotte da gestire.

In questi tre scenari il problema è identico e la soluzione è la stessa. La checklist di migrazione email consente di anticipare questo tipo di problema prima di avviare la migrazione.

Perché uno script fatto in casa non è la risposta

Capire il problema è una cosa. Decidere "scrivo uno script Python che ripulisce gli header" e applicarlo su 30.000 email di produzione è tutta un'altra storia.

I casi limite abbondano. Uno script che funziona su 50 email di test in un ambiente pulito incontrerà inevitabilmente, su una casella di produzione di dimensioni reali:

• Messaggi con firme S/MIME o contenuto cifrato PGP, dove qualsiasi modifica alla struttura del messaggio invalida la firma crittografica.
• Email con strutture MIME annidate complesse (multipart/alternative dentro un multipart/mixed con allegati da decine di megabyte).
• Header codificati in RFC 2047 (caratteri non-ASCII), che i parser mal configurati consumano silenziosamente.
• Errori 429 Too Many Requests dell'API Google alle 2 di notte, nel mezzo di un batch di correzione, che lasciano il processo in uno stato indeterminato.
• Email in cui la catena dei Received: è ambigua: più strumenti di migrazione successivi hanno ciascuno aggiunto il proprio header, e non è affatto semplice determinare quale rimuovere.

E la domanda più importante: come verificare, email per email, che ogni messaggio corretto sia integro e che nulla sia andato perso o corrotto? Uno script fatto in casa di solito non esegue questa verifica. Redate.io la esegue automaticamente, conservando gli originali in una cartella di backup visibile per 30 giorni.

Cosa fa Redate.io su questo tipo di migrazione

Redate.io si connette al tenant Google Workspace di destinazione (tramite delegazione di dominio, senza intervento manuale casella per casella) e scansiona le email per identificare quelle i cui metadati di data sono incoerenti con il contenuto del messaggio. Questa fase di scansione è gratuita e fornisce un quadro preciso dell'entità del problema prima di qualsiasi correzione.

Il motore di correzione proprietario analizza poi la catena di header di ogni messaggio, applica un sistema di riconoscimento dei pattern sulle firme note degli strumenti di migrazione (BitTitan, CloudM, imapsync, GSMMO, e altri meno diffusi), ed esegue una correzione mirata dei metadati senza alterare il contenuto del messaggio. Ogni email corretta viene verificata individualmente. Gli originali sono conservati.

Per le migrazioni inter-tenant Google Workspace nello specifico, il pipeline gestisce i casi in cui si sono verificate più passate di migrazione (ad esempio, una casella migrata una prima volta nel 2021 e poi di nuovo nel 2024), con più livelli di header parassiti da districare.

Le guide di correzione specifiche per CloudM verso Google Workspace e BitTitan verso Google Workspace illustrano i passaggi di connessione per questo tipo di configurazione.

Rilevare il problema prima che gli utenti si lamentino

Il momento migliore per rilevare date corrotte è subito dopo la migrazione, prima del go-live. Una verifica rapida su alcune caselle pilota tramite un client IMAP come Thunderbird consente di confrontare la visualizzazione delle date con quanto ci si aspetterebbe. Se tutte le email importate sembrano avere la stessa data recente, è il segnale caratteristico del problema.

Ma in pratica, la scoperta del problema avviene spesso settimane dopo la migrazione, quando un utente cerca un vecchio contratto e si rende conto che la sua casella Gmail è perfettamente ordinata... per data di migrazione. Migliaia di email ammassate allo stesso timestamp. La ricerca per data non funziona più. I thread sono in disordine. La cronologia sembra essere scomparsa.

Per gli MSP che gestiscono regolarmente migrazioni inter-tenant Google Workspace, integrare una scansione Redate.io nella checklist post-migrazione (prima della validazione del cliente) evita questo tipo di sorpresa.

Ha appena migrato tra due tenant Google Workspace e le date delle Sue email sono errate? Avvii una scansione gratuita su Redate.io per misurare l'impatto prima di qualsiasi correzione.