Rett GSMMO-migreringsdatoer i Gmail

GSMMO (Google Workspace Migration for Microsoft Outlook) laster opp e-poster fra PST-filer eller Outlook-profiler direkte til Gmail via Gmail API. Under opplastingen registrerer Gmail opplastingstidsstempelet som INTERNALDATE for hver melding. Den opprinnelige Date-headeren fra e-postteksten bevares - men datometadataene på servernivå overskrives med migreringsdatoen.

Dette skaper en misvisende situasjon. Gmails nettgrensesnitt leser Date-headeren fra e-postteksten for visning, så de fleste e-poster ser ut til å ha riktig dato i nettleseren. Alt ser fint ut. Men under overflaten er IMAP INTERNALDATE lagret på Googles servere feil. Når spiller dette noen rolle? I det øyeblikket noen bruker postboksen gjennom en IMAP-klient - Outlook, Thunderbird, Apple Mail - eller når et sikkerhetskopiverktøy, samsvarssystem eller arkiveringsløsning spør mot postboksen via IMAP.

GSMMO brukes typisk av sluttbrukere som går over fra Microsoft Outlook til Google Workspace, ofte etter Googles egen migreringsdokumentasjon. Disse brukerne kan gå uker eller måneder uten å legge merke til problemet fordi de primært bruker Gmails nettgrensesnitt. Så en dag kjører samsvarsteamet et datobasert søk gjennom Google Vault, eller IT-avdelingen setter opp MailStore for arkivering, eller brukeren installerer Outlook koblet til Gmail via IMAP. Plutselig viser 40 000 e-poster den samme datoen fra seks måneder siden. På det tidspunktet føles migreringen som gammel historie, og å diagnostisere grunnårsaken blir et puslespill.

For Gmail-nettbrukere er den visuelle påvirkningen villedende minimal. Datoer ser riktige ut i nettleseren. Men den ødelagte INTERNALDATE er en tikkende bombe under overflaten. Gmails IMAP SEARCH DATE-kommando bruker INTERNALDATE, så ethvert IMAP-basert verktøy som utfører datosøk mot postboksen får feil resultater. Sikkerhetskopiverktøy som MailStore, Veeam eller egendefinerte Python-skript som arkiverer Gmail via IMAP registrerer feil datoer. De sikkerhetskopiene? Permanent unøyaktige.

Har du noen gang prøvd å sortere 50 000 e-poster som alle deler den samme mottaksdatoen? Det er hva enhver IMAP-klient koblet til en GSMMO-migrert postboks opplever. Outlook, Apple Mail, Thunderbird - alle leser INTERNALDATE for sortering og visning. Google Takeout-eksporter kan referere til INTERNALDATE for filnavngiving og metadata, noe som skaper forvirrende arkivstrukturer. Til og med Google Vault-samsvarssøk kan gi misvisende resultater når INTERNALDATE ikke samsvarer med den faktiske e-postdatoen.

Redate.io løser dette gjennom en flertrinns headeranalysepipeline som identifiserer GSMMO-migreringssignaturer og utfører rekonstruksjon av datometadata på servernivå. Prosessen bevarer alt meldingsinnhold, etiketter og vedlegg mens bare datometadataene korrigeres. Hver melding verifiseres individuelt etter behandling.