GSMMO pokvarilo datume e-pošte? Kako jih popraviti

GSMMO in težava z datumi, o kateri vas nihče ne opozori

Google Workspace Migration for Microsoft Outlook (GSMMO) je namizno orodje, ki ga Google ponuja za migracijo datotek PST, profilov Outlook in lokalnih arhivov e-pošte v Gmail. Je brezplačno, uradno podprto in je migracijska pot, ki jo Google priporoča pri selitvi majhne ekipe ali nekaj posameznih poštnih predalov iz Outlooka v Google Workspace.

Orodje deluje. E-pošta prispe v Gmail, struktura map se preslika v oznake, stiki pridejo skozi. Toda nato odprite Gmail in razvrstite po datumu. Vsako e-poštno sporočilo prikazuje današnji datum. Tisti predlog, ki ste ga poslali januarja 2021? April 2026. Račun od računovodje iz marca 2023? Prav tako april 2026.

GSMMO vas ne opozori, da se bo to zgodilo. Dnevnik migracije prikazuje uspeh za vsako sporočilo. Googlova lastna dokumentacija tega ne omenja kot znano omejitev. To odkrijete šele, ko nekdo poišče staro e-pošto po datumskem razponu in dobi nič rezultatov.

Kako GSMMO dejansko naloži vašo e-pošto

GSMMO prebere sporočila iz datoteke PST (ali neposredno iz profila Outlook) in jih naloži v Gmail prek API-ja Gmail (tako pravijo Googlove lastne opombe ob izdaji orodja). Tu se začne težava z datumi, in vredno je razumeti mehaniko, saj pojasni, zakaj popravek ni tako preprost, kot "ponovno uvozite".

Ko GSMMO naloži sporočilo prek API-ja Gmail, Gmail doda svežo glavo Received:, datirano na trenutek nalaganja. In kadar prvotni datum ni posredovan skupaj s sporočilom, se INTERNALDATE, torej časovni žig, ki ga Gmail interno uporablja za razvrščanje in prikaz, nastavi na trenutek nalaganja namesto na prvotni datum pošiljanja.

Tako je videti veriga glav po migraciji GSMMO:

Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
    bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
    by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200

Vidite tisto prvotno glavo Date: iz septembra 2019? Še vedno je tam, nedotaknjena. GSMMO ne spreminja vsebine sporočila niti prvotnih glav. Toda Gmail jo za namene prikaza ignorira in namesto tega uporabi INTERNALDATE, ki zdaj pravi april 2026.

GSMMO v primerjavi z migracijskimi orodji na strani skrbnika

Tu se zmeda pogosto začne. Google ima več migracijskih orodij in vsa se ne obnašajo enako.

GSMMO (namizna aplikacija) teče na uporabnikovem računalniku. Bere iz Outlooka ali datoteke PST in nalaga e-pošto prek API-ja Gmail. Uporabnik potrebuje račun Google Workspace in vtičnik GSMMO, nameščen v Outlooku. Gre za orodje na strani odjemalca.

Google Workspace Migration Service (orodje v skrbniški konzoli) deluje na strani strežnika. Skrbnik ga konfigurira v Google Admin Console, ga usmeri na strežnik Exchange ali drugega najemnika Google Workspace, in migracija poteka v Googlovi infrastrukturi. To orodje ima v nekaterih konfiguracijah nekoliko boljše obravnavanje datumov, ker lahko nastavi INTERNALDATE na podlagi metapodatkov vira. Toda "nekoliko boljše" ne pomeni "zanesljivo", in tudi pri tem orodju številni skrbniki poročajo o isti težavi z datumi.

Razlika je preprosta: pri GSMMO ni nobene inteligence na strani strežnika, ki bi odločala o ohranjanju datumov. Vsako sporočilo, ki ga naloži, dobi enako obravnavo, naj gre za sveže sporočilo ali sporočilo, staro deset let: glavo Received:, datirano na dan nalaganja. Pika.

Zakaj ohranjanje datumov v GSMMO ne deluje

Če si ogledate nastavitve GSMMO, boste morda opazili, da možnost "ohrani datume" pravzaprav ne obstaja. To ni spregled. GSMMO se zanaša na to, kako Gmail obravnava sporočila, naložena prek njegovega API, in tega ne more preglasiti.

Tehnično zaporedje dogodkov je takšno:

1. GSMMO prebere sporočilo iz datoteke PST, vključno s prvotnimi časovnimi žigi
2. GSMMO naloži podatke sporočila prek API-ja Gmail
3. Gmail prejme nalaganje in shrani sporočilo v poštni predal
4. Gmail doda novo glavo Received:, datirano na trenutek nalaganja (vrstica gmailapi.google.com v zgornjem primeru)
5. Kadar prvotni datum ni posredovan, Gmail nastavi INTERNALDATE na časovni žig nalaganja
6. Sporočilo pristane v Gmailu z današnjim datumom

Koraka 4 in 5 sta odločilna. Gmail doda to glavo vsakemu sporočilu, naloženemu prek njegovega API-ja, ne glede na to, kaj orodje pošlje, GSMMO pa nima nastavitve za posredovanje ali ohranitev prvotnega datuma. Rezultat je, da vsa vaša pretekla e-pošta izgleda, kot da je prispela danes.

Nekateri skrbniki so poskusili zagnati GSMMO z določenimi nastavitvami Google Workspace ali prilagoditi nastavitve profila GSMMO. Nič od tega ne vpliva na obnašanje datumov. Glavo Received: doda Google na svoji strani, in nobena nastavitev na strani odjemalca tega ne spremeni.

Posebni scenariji GSMMO, ki pokvarijo datume

Ne vsaka migracija GSMMO se konča v kaosu datumov, čeprav se večina konča. Tu je pregled, kje je to pomembno:

• Datoteka PST v Gmail: Datumi se pokvarijo. To je najpogostejši primer uporabe GSMMO in najbolj prizadet.
• Profil Outlook v Gmail: Datumi se pokvarijo. Enako nalaganje prek Gmail API kot pri uvozu PST.
• Exchange Online (Microsoft 365) v Gmail prek GSMMO: Datumi se pokvarijo. GSMMO bere s strežnika Exchange in nalaga prek Gmail API.
• Lokalni Exchange v Gmail prek GSMMO: Datumi se pokvarijo. Enak mehanizem.
• Gmail v Gmail (ponovni uvoz izvoza PST): Datumi se pokvarijo. Tudi če je imela prvotna e-pošta v datoteki PST pravilne datume, ponovni uvoz jih na novo odtisne.

Vzorec je jasen. Vsako sporočilo, naloženo prek API-ja Gmail, dobi glavo Received:, datirano na dan nalaganja. GSMMO vedno uporablja to pot.

Kar to naredi še posebej frustrirajoče, je dejstvo, da poročilo o migraciji GSMMO vse prikazuje kot uspešno. Brez opozoril o datumih, brez napak, brez oznak. Časovne žige bi morali ročno primerjati pred in po migraciji, da bi to opazili, in večina skrbnikov tega ne stori, dokler se uporabnik ne pritoži.

Vpliv presega razvrščanje

Napačni datumi po migraciji GSMMO ustvarjajo resnične težave, ki presegajo neurejen poštni predal.

Predstavljajte si, da ste računovodja, ki je pravkar prešel na Google Workspace. Poiskati morate vso korespondenco s strankami iz tretjega četrtletja 2024 za davčno napoved. Iščete v Gmailu po datumskem razponu: julij do september 2024. Nič rezultatov. Vsako sporočilo iz tega obdobja zdaj prikazuje datum migracije, zato ga Gmailov filter za datume ne najde. Ostanete brez izbire, da drsite skozi tisoče sporočil ali iščete po ključnih besedah in upate, da se spomnite pravih izrazov.

Za regulirane panoge je to hujše kot zgolj nadloga. Časovni žigi e-pošte služijo kot pravni dokaz. Finančni svetovalec, ki mora dokazati, da je razkritje poslal pred datumom transakcije, tega ne more storiti, kadar sporočilo prikazuje april 2026 namesto februarja 2023. Revizije skladnosti po SOX ali HIPAA se zanašajo na natančne časovne žige komunikacij, napačni datumi pa pomenijo neuspele revizije.

In potem je še težava z nitmi. Gmail razvršča pogovore po datumu in temi. Ko vsako sporočilo v niti prikazuje enak datum, se pogled na pogovor zmeša. Odgovori se prikažejo pred prvotnim sporočilom. Celotna struktura niti se sesuje v kup enako datiranih sporočil.

Popravljanje datumov GSMMO z Redate.io

Dobra novica: tista prvotna glava Date: je še vedno nedotaknjena znotraj vsakega migriranega sporočila. GSMMO ne spreminja vsebine sporočila. Pravilen datum je tam, le da ga Gmailova logika prikaza ignorira, ker INTERNALDATE in zgornja glava Received: kažeta na datum migracije.

Redate.io se poveže s poštnim predalom Google Workspace, pregleda sporočila, prizadeta z migracijo, in popravi metapodatke datumov z lastniškim mehanizmom za analizo verige glav in rekonstrukcijo datumov. Redate ne potrebuje podatka, katero orodje je izvedlo migracijo: najde sporočila, katerih prikazani datum ne ustreza njihovemu prvotnemu datumu, in jih popravi brez spreminjanja vsebine sporočila, prilog ali niti.

Vsako popravljeno sporočilo gre skozi posamezno preverjanje: celovitost sporočila, ohranitev prilog, preslikavo oznak in skladnost niti. Izvirniki ostanejo v vidni mapi z varnostno kopijo Redate.io - Originals v vašem lastnem poštnem predalu, dokler jih ne izbrišete sami.

Bi to lahko popravili sami s skripto? Razumeti težavo je ena stvar. Popraviti 12.000 e-poštnih sporočil, ne da bi podrli podpise S/MIME, pokvarili vgnezdene dele MIME ali zmešali glave, kodirane po RFC 2047, v celotnem produkcijskem poštnem predalu, je nekaj popolnoma drugega. Kako bi obravnavali sporočilo s 38 MB veliko priponko in okvarjeno mejo MIME, ki jo je GSMMO uvozil in le za silo ohranil skupaj? Kako bi preverili, da je vsako posamezno sporočilo prišlo skozi v celoti? Skripta, ki deluje na 20 testnih sporočilih v laboratoriju, ne bo prestala resničnega poštnega predala z osmimi leti korespondence.

Vodniki za posamezne platforme za GSMMO

Ker GSMMO migrira izrecno v Google Workspace, se popravek zgodi na ravni Gmaila. Toda prizadeta sporočila so vidna v vseh odjemalcih, povezanih s tem računom Gmail:

• Popravite datume migracije GSMMO v Gmailu
• Popravite datume migracije GSMMO v Outlooku (povezanem z Google Workspace)
• Popravite datume migracije GSMMO v Apple Mail

Ste migrirali že pred meseci? Prvotna glava Date: s časom ne izgine. Redate.io lahko popravi sporočila, prizadeta z GSMMO, ne glede na to, ali se je migracija zgodila prejšnji teden ali pred tremi leti.

Je migracija GSMMO pustila vaša sporočila z napačnimi datumi? Zaženite brezplačen pregled in oglejte si natančno število prizadetih sporočil in ceno popravka, preden se za kar koli zavežete.