Rett CloudM-migreringsdatoer i Gmail

CloudM Migrate (tidligere Cloud Migrator) laster opp e-poster til Google Workspace gjennom Gmail API. Under opplastingen registrerer Gmail innsettingstidsstempelet som meldingens INTERNALDATE. Den opprinnelige Date-headeren inne i e-postteksten overlever migreringen. Men INTERNALDATE - feltet som IMAP-klienter leser for å bestemme når en melding ble mottatt - blir permanent overskrevet med migreringsdatoen.

Det som gjør CloudM-migreringer spesielt forvirrende, er den delte oppførselen i Gmail. Gmails nettgrensesnitt leser Date-headeren for visning, så e-poster ser helt fine ut i nettleseren. Åpne den samme postboksen i Outlook via IMAP, og hver e-post viser migreringsdatoen. Apple Mail, Thunderbird, mobile IMAP-klienter - samme historie. Problemet er usynlig for alle som bare bruker Gmail på nett, noe som gjør det vanskeligere å diagnostisere og lettere å avfeie.

"Migreringen gikk bra, datoene ser riktige ut." Det er hva CloudM-konsollen forteller deg. Det er hva Gmail forteller deg. Men 60 % av brukerne dine kobler seg til gjennom Outlook, og for dem har 14 måneder med e-posthistorikk kollapset til en enkelt dag.

CloudM-administrasjonskonsollen i Google Admin-panelet (Admin > Apper > Google Workspace Marketplace-apper > CloudM Migrate) flagger ikke dette som et problem. Det er ingen feil, ingen advarsel, ingen ettermigrerings-rapport som nevner INTERNALDATE-korrupsjon. Det er et stille datakvalitetsproblem som bare dukker opp når brukere klager.

Konsekvensene avhenger helt av hvordan brukerne bruker postboksen sin. Gmail på nett? Ser normalt ut. Outlook, Apple Mail, Thunderbird via IMAP? Hver e-post viser migreringsdatoen i mottakskolonnen. Denne inkonsekvensen skaper forvirrende henvendelser til brukerstøtte og gjør problemet vanskelig å forklare til ikke-tekniske brukere.

Utover visningsproblemer strekker INTERNALDATE-korrupsjonen seg inn i samsvars- og sikkerhetskopiinfrastruktur. Google Vault refererer til INTERNALDATE for enkelte oppbevarings- og juridisk hold-operasjoner, noe som kan svekke nøyaktigheten av datobaserte eDiscovery-søk. Tredjeparts sikkerhetskopiverktøy som kobler seg til via IMAP (Veeam, Spanning, Backupify) arkiverer migreringsdatoen som meldingsdatoen, noe som skaper permanente unøyaktigheter i sikkerhetskopier som kanskje ikke oppdages før en gjenoppretting er nødvendig.

Redate.io korrigerer dette gjennom headerkjedeanalyse og rekonstruksjon av datometadata, og behandler bare CloudM-injiserte migreringsartefakter. Gmail-opplevelsen på nett (som allerede viste riktig) forblir uendret. IMAP-klienter, Google Vault og sikkerhetskopiverktøy begynner alle å lese den opprinnelige datoen. Hver melding verifiseres individuelt før og etter korreksjon for å sikre null datatap.