GSMMO sugadino el. laiškų datas? Kaip jas pataisyti

GSMMO ir datų problema, apie kurią niekas neįspėja

Google Workspace Migration for Microsoft Outlook (GSMMO) yra darbalaukio įrankis, kurį Google teikia PST failų, Outlook profilių ir vietinių el. pašto archyvų perkėlimui į Gmail. Jis nemokamas, oficialiai palaikomas, ir tai yra perkėlimo kelias, kurį Google rekomenduoja, kai perkeliama nedidelė komanda ar kelios atskiros pašto dėžutės iš Outlook į Google Workspace.

Įrankis veikia. El. laiškai pasiekia Gmail, aplankų struktūra susiejama su žymėmis, kontaktai perkeliami. Bet atidarykite Gmail po to ir surūšiuokite pagal datą. Kiekvienas el. laiškas rodo šiandienos datą. Tas pasiūlymas, kurį išsiuntėte 2021 m. sausį? 2026 m. balandis. Sąskaita nuo buhalterio iš 2023 m. kovo? Taip pat 2026 m. balandis.

GSMMO neįspėja, kad taip atsitiks. Perkėlimo žurnalas rodo sėkmę kiekvienam pranešimui. Paties Google dokumentacija to nemini kaip žinomo trūkumo. Sužinote tai tik tada, kai kas nors ieško seno el. laiško pagal datų intervalą ir negauna jokių rezultatų.

Kaip GSMMO iš tikrųjų įkelia jūsų el. paštą

GSMMO nuskaito pranešimus iš PST failo (arba tiesiogiai iš Outlook profilio) ir įkelia juos į Gmail per Gmail API (tai patvirtinta paties Google įrankio versijų pastabose). Čia ir kyla datų problema, ir verta suprasti veikimo mechaniką, kodėl taisymas nėra tiesiog "importuokite iš naujo".

Kai GSMMO įkelia pranešimą per Gmail API, Gmail uždeda naują Received: antraštę su įkėlimo momento data. Ir kai pradinė data nėra perduodama su pranešimu, INTERNALDATE, laiko žyma, kurią Gmail viduje naudoja rūšiavimui ir rodymui, nustatoma į įkėlimo momentą, o ne į pradinę siuntimo datą.

Taip atrodo antraščių grandinė po GSMMO migracijos:

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

Matote tą pradinę Date: antraštę iš 2019 m. rugsėjo? Ji vis dar ten, nepaliesta. GSMMO nekeičia pranešimo turinio ar pradinių antraščių. Bet Gmail ją ignoruoja rodymo tikslais ir vietoj to naudoja INTERNALDATE, kuris dabar rodo 2026 m. balandį.

GSMMO prieš administratoriaus pusės perkėlimo įrankius

Čia dažnai prasideda painiava. Google turi kelis perkėlimo įrankius, ir jie ne visi elgiasi vienodai.

GSMMO (darbalaukio programa) veikia vartotojo kompiuteryje. Ji nuskaito iš Outlook arba PST failo ir įkelia el. laiškus per Gmail API. Vartotojui reikia Google Workspace paskyros ir Outlook programoje įdiegto GSMMO papildinio. Tai kliento pusės įrankis.

Google Workspace Migration Service (administratoriaus konsolės įrankis) yra serverio pusės. Administratorius jį sukonfigūruoja Google Admin Console, nukreipia į Exchange serverį ar kitą Google Workspace nuomininką, ir migracija vyksta Google infrastruktūroje. Kai kuriose konfigūracijose šis įrankis šiek tiek geriau tvarko datas, nes gali nustatyti INTERNALDATE pagal pradinius metaduomenis. Bet "šiek tiek geriau" nereiškia "patikimai", ir daugelis administratorių praneša apie tą pačią datų problemą ir su šiuo įrankiu.

Pagrindinis skirtumas? Su GSMMO nėra serverio pusės intelekto, kuris priimtų sprendimus apie datų išsaugojimą. Kiekvienas jo įkeltas pranešimas gauna tokį pat apdorojimą, nesvarbu, ar tai šviežias el. laiškas, ar 10 metų senumo archyvinis pranešimas: Received: antraštę su įkėlimo dienos data. Ir viskas.

Kodėl GSMMO datų išsaugojimas neveikia

Jei peržvelgėte GSMMO nustatymus, galbūt pastebėjote, kad iš tikrųjų nėra parinkties "išsaugoti datas". Tai nėra praleidimas. GSMMO remiasi tuo, kaip Gmail tvarko per savo API įkeltus pranešimus, ir negali to pakeisti.

Čia yra techninė įvykių grandinė:

1. GSMMO nuskaito pranešimą iš PST failo, įskaitant jo pradines laiko žymas
2. GSMMO įkelia pranešimo duomenis per Gmail API
3. Gmail priima įkėlimą ir saugo pranešimą pašto dėžutėje
4. Gmail uždeda naują Received: antraštę su įkėlimo momento data (aukščiau esančiame pavyzdyje eilutė gmailapi.google.com)
5. Kai pradinė data nėra perduodama, Gmail nustato INTERNALDATE į įkėlimo laiko žymą
6. Pranešimas atsiduria Gmail su šiandienos data

4 ir 5 žingsniai yra svarbiausi. Gmail tą antraštę uždeda kiekvienam per savo API įkeltam pranešimui, kad ir ką siųstų įrankis, o GSMMO neturi nustatymo, kuris perduotų ar išsaugotų pradinę datą. Rezultatas toks, kad visi jūsų senesni el. laiškai atrodo, kaip atėję šiandien.

Kai kurie administratoriai bandė paleisti GSMMO su konkrečiais Google Workspace nustatymais arba koreguoti GSMMO profilio parametrus. Nė vienas iš jų nepaveikia datų elgsenos. Received: antraštė pridedama Google pusėje, ir jokia kliento pusės konfigūracija tai nepakeičia.

Konkretūs GSMMO scenarijai, kurie sugadina datas

Ne kiekviena GSMMO migracija baigiasi datų sumaištimi, tačiau dauguma jų baigiasi. Čia svarbiausi atvejai:

• PST failas į Gmail: datos sugenda. Tai dažniausias GSMMO naudojimo atvejis ir labiausiai paveiktas.
• Outlook profilis į Gmail: datos sugenda. Toks pats įkėlimas per Gmail API, kaip ir PST importe.
• Exchange Online (Microsoft 365) į Gmail per GSMMO: datos sugenda. GSMMO nuskaito iš Exchange serverio ir įkelia per Gmail API.
• Vietinis Exchange į Gmail per GSMMO: datos sugenda. Tas pats mechanizmas.
• Gmail į Gmail (pakartotinis PST eksporto importas): datos sugenda. Net jei pradiniai el. laiškai PST faile turėjo teisingas datas, pakartotinis importas jas pažymi iš naujo.

Modelis aiškus. Kiekvienas per Gmail API įkeltas pranešimas gauna Received: antraštę su įkėlimo dienos data. GSMMO visada naudoja šį kelią.

Ypač varginantis dalykas yra tas, kad GSMMO migracijos ataskaita rodo, jog viskas pavyko. Nėra įspėjimų apie datas, nėra klaidų, nėra pažymėjimų. Reikėtų rankomis palyginti laiko žymas prieš ir po migracijos, kad tai pastebėtumėte, ir dauguma administratorių to nedaro, kol vartotojas nepasiskundžia.

Poveikis, viršijantis rūšiavimą

Neteisingos datos po GSMMO migracijos sukuria realias problemas, kurios viršija netvarkingą pašto dėžutę.

Įsivaizduokite, kad esate buhalteris, kuris ką tik perėjo prie Google Workspace. Jums reikia rasti visą klientų korespondenciją iš 2024 m. trečio ketvirčio mokesčių deklaracijai. Ieškote Gmail pagal datų intervalą: liepa-rugsėjis 2024. Nulinis rezultatas. Kiekvienas el. laiškas iš to laikotarpio dabar rodo migracijos datą, tad Gmail datos filtras jų neranda. Jūs įstrigote, slinkdami per tūkstančius pranešimų arba ieškodami raktažodžiais ir tikėdamiesi prisiminti tinkamus terminus.

Reguliuojamoms pramonės šakoms tai yra daugiau nei nepatogumas. El. laiškų laiko žymos yra teisinis įrodymas. Finansų konsultantas, kuriam reikia įrodyti, kad jis atsiuntė atskleidimo dokumentą prieš sandorio datą, to negali padaryti, kai el. laiškas rodo 2026 m. balandį, o ne 2023 m. vasarį. SOX ar HIPAA atitikties auditai remiasi tiksliomis komunikacijos laiko žymomis, ir neteisingos datos reiškia nesėkmingus auditus.

Ir tada yra gijų klausimas. Gmail grupuoja pokalbius pagal datą ir temą. Kai kiekvienas pranešimas gijoje rodo tą pačią datą, pokalbio rodinys tampa sumaišytas. Atsakymai atrodo anksčiau nei pradinis pranešimas. Visa gijos struktūra suskyla į krūvą vienodai datuotų el. laiškų.

GSMMO datų taisymas su Redate.io

Gera žinia: ta pradinė Date: antraštė vis dar nepaliesta kiekviename perkeltame el. laiške. GSMMO nekeičia pranešimo turinio. Teisinga data ten yra, tiesiog Gmail rodymo logika ją ignoruoja, nes INTERNALDATE ir viršutinė Received antraštė nurodo migracijos datą.

Redate.io prisijungia prie Google Workspace pašto dėžutės, nuskaito el. laiškus, paveiktus GSMMO migracijos, ir pataiso datos metaduomenis, naudodamas nuosavą antraščių grandinės analizės ir datos rekonstrukcijos variklį. Redate neturi žinoti, kuris įrankis atliko migraciją: jis suranda el. laiškus, kurių rodoma data nesutampa su pradine data, ir pataiso juos, nepakeisdamas pranešimo turinio, priedų ar gijų.

Kiekvienas pataisytas el. laiškas praeina atskirą patikrą: tikrinamas pranešimo vientisumas, priedų išsaugojimas, žymų susiejimas ir gijos vientisumas. Pradiniai laiškai saugomi matomame Redate.io - Originals atsarginių kopijų aplanke jūsų pačių pašto dėžutėje, kol juos patys pašalinsite.

Ar galėtumėte tai pataisyti patys, naudodami skriptą? Supratimas apie problemą yra vienas dalykas. Pataisyti 12 000 el. laiškų, nesugadinant S/MIME parašų, nesuardant įdėtų MIME dalių ar nesugadinant RFC 2047 koduotų antraščių visoje veikiančioje pašto dėžutėje, yra visai kas kita. Kaip tvarkytumėte el. laišką su 38 MB priedu ir sugadinta MIME riba, kurią GSMMO importavo, tačiau kuri vos laikėsi kartu? Kaip patikrintumėte, ar kiekvienas pranešimas atkeliavo nepažeistas? Skriptas, kuris veikia su 20 testinių pranešimų laboratorijoje, neišlaikys realios pašto dėžutės su 8 metų korespondencija.

Konkrečių platformų vadovai GSMMO taisymui

Kadangi GSMMO migruoja specifiškai į Google Workspace, taisymas vyksta Gmail lygmenyje. Bet paveikti el. laiškai matomi kiekviename kliente, prijungtame prie tos Gmail paskyros:

• Pataisykite GSMMO migracijos datas Gmail
• Pataisykite GSMMO migracijos datas Outlook programoje (prijungtoje prie Google Workspace)
• Pataisykite GSMMO migracijos datas Apple Mail

Jau perkėlėte prieš kelis mėnesius? Pradinė Date: antraštė laikui bėgant nepablogėja. Redate.io gali pataisyti GSMMO paveiktus el. laiškus, nesvarbu, ar migracija vyko praėjusią savaitę, ar prieš trejus metus.

GSMMO migracija paliko jūsų el. laiškus su neteisingomis datomis? Atlikite nemokamą nuskaitymą, kad pamatytumėte tikslų paveiktų el. laiškų skaičių ir taisymo kainą, prieš įsipareigodami.