GSMMO sabojāja e-pastu datumus? Kā tos labot

GSMMO un datumu problēma, par kuru neviens nebrīdina

Google Workspace Migration for Microsoft Outlook (GSMMO) ir darbvirsmas rīks, ko Google nodrošina PST failu, Outlook profilu un lokālo e-pasta arhīvu migrēšanai uz Gmail. Tas ir bezmaksas, oficiāli atbalstīts, un tas ir migrācijas ceļš, ko Google iesaka, ja pārceļat nelielu komandu vai dažas individuālas pastkastes no Outlook uz Google Workspace.

Rīks darbojas. E-pasti nonāk Gmail, mapju struktūra tiek pārveidota etiķetēs, kontakti tiek pārsūtīti. Bet atveriet Gmail pēc tam un kārtojiet pēc datuma. Katrs e-pasts rāda šodienas datumu. Tas priekšlikums, ko nosūtījāt 2021. gada janvārī? 2026. gada aprīlis. Rēķins no jūsu grāmatveža 2023. gada martā? Arī 2026. gada aprīlis.

GSMMO nebrīdina, ka tas notiks. Migrācijas žurnāls rāda panākumus par katru ziņojumu. Google pašas dokumentācija to nemin kā zināmu ierobežojumu. Jūs to atklājat tikai tad, kad kāds meklē vecu e-pastu pēc datumu diapazona un nesaņem nevienu rezultātu.

Kā GSMMO patiesībā augšupielādē jūsu e-pastu

GSMMO nolasa ziņojumus no PST faila (vai tieši no Outlook profila) un augšupielādē tos Gmail, izmantojot Gmail API (tā apliecina Google pašas laidiena piezīmes šim rīkam). Tieši šeit rodas datumu problēma, un ir vērts saprast tās mehānismu, jo tas paskaidro, kāpēc labošana nav tik vienkārša kā "vienkārši importēt no jauna".

Kad GSMMO augšupielādē ziņojumu, izmantojot Gmail API, Gmail pievieno jaunu Received: galveni ar augšupielādes brīža datumu. Un, ja sākotnējais datums nav pievienots ziņojumam, INTERNALDATE, laika zīmogs, ko Gmail izmanto iekšēji kārtošanai un attēlošanai, tiek iestatīts uz augšupielādes brīdi, nevis uz sākotnējo nosūtīšanas datumu.

Lūk, kā galveņu ķēde izskatās pēc GSMMO migrācijas:

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

Redzat to sākotnējo Date: galveni no 2019. gada septembra? Tā joprojām ir tur, neskarta. GSMMO nemaina ziņojuma tekstu vai sākotnējās galvenes. Bet Gmail to ignorē attēlošanas nolūkos un tā vietā izmanto INTERNALDATE, kas tagad rāda 2026. gada aprīli.

GSMMO salīdzinājumā ar administratora puses migrācijas rīkiem

Tieši šeit bieži rodas neskaidrības. Google piedāvā vairākus migrācijas rīkus, un tie visi neuzvedas vienādi.

GSMMO (darbvirsmas lietotne) darbojas lietotāja datorā. Tas lasa no Outlook vai PST faila un augšupielādē e-pastus, izmantojot Gmail API. Lietotājam ir nepieciešams Google Workspace konts un GSMMO spraudnis, kas instalēts programmā Outlook. Tas ir klienta puses rīks.

Google Workspace Migration Service (administratora konsoles rīks) darbojas servera pusē. Administrators to konfigurē Google Admin konsolē, norāda uz Exchange serveri vai citu Google Workspace organizāciju, un migrācija notiek Google infrastruktūrā. Šim rīkam dažās konfigurācijās ir nedaudz labāka datumu apstrāde, jo tas var iestatīt INTERNALDATE, pamatojoties uz avota metadatiem. Bet "nedaudz labāka" nenozīmē "uzticama", un daudzi administratori ziņo par to pašu datumu problēmu arī ar šo rīku.

Galvenā atšķirība? Ar GSMMO nav servera puses loģikas, kas lemtu par datumu saglabāšanu. Katrs augšupielādētais ziņojums saņem tādu pašu apstrādi, neatkarīgi no tā, vai tas ir svaigs e-pasts vai 10 gadus vecs arhivēts ziņojums: Received: galvene ar augšupielādes dienas datumu. Un nekā vairāk.

Kāpēc GSMMO datumu saglabāšana nedarbojas

Ja esat aplūkojuši GSMMO iestatījumus, jūs varētu būt pamanījuši, ka opcijas "saglabāt datumus" faktiski nav. Tā nav nepilnība. GSMMO ir atkarīgs no tā, kā Gmail apstrādā ziņojumus, kas augšupielādēti caur tā API, un to nevar apiet.

Lūk, tehniskā notikumu ķēde:

1. GSMMO nolasa ziņojumu no PST faila, ieskaitot tā sākotnējos laika zīmogus
2. GSMMO augšupielādē ziņojuma datus, izmantojot Gmail API
3. Gmail saņem augšupielādi un saglabā ziņojumu pastkastē
4. Gmail pievieno jaunu Received: galveni ar augšupielādes brīža datumu (piemērā iepriekš redzamā rinda ar gmailapi.google.com)
5. Ja sākotnējais datums netiek pievienots, Gmail iestata INTERNALDATE uz augšupielādes laika zīmogu
6. Ziņojums nonāk Gmail ar šodienas datumu

4. un 5. solis ir izšķirošie. Gmail pievieno šo galveni katram ziņojumam, kas augšupielādēts, izmantojot tā API, neatkarīgi no tā, ko rīks nosūta, un GSMMO nav iestatījuma, kas nodotu vai saglabātu sākotnējo datumu. Rezultāts ir tāds, ka visi jūsu vēsturiskie e-pasti izskatās, kā tie būtu ienākuši šodien.

Daži administratori ir mēģinājuši palaist GSMMO ar konkrētiem iespējotiem Google Workspace iestatījumiem vai pielāgojot GSMMO profila iestatījumus. Neviens no šiem soļiem neietekmē datumu uzvedību. Received: galvene tiek pievienota Google pusē, un nekāda klienta puses konfigurācija to nemaina.

Konkrēti GSMMO scenāriji, kas sabojā datumus

Ne katra GSMMO migrācija noslēdzas ar datumu haosu, taču lielākā daļa noslēdzas. Lūk, kur tas ir svarīgi:

• PST fails uz Gmail: Datumi sabojājas. Šis ir visbiežāk sastopamais GSMMO lietošanas gadījums un visvairāk ietekmētais.
• Outlook profils uz Gmail: Datumi sabojājas. Tā pati Gmail API augšupielāde kā PST importam.
• Exchange Online (Microsoft 365) uz Gmail, izmantojot GSMMO: Datumi sabojājas. GSMMO nolasa no Exchange servera un augšupielādē, izmantojot Gmail API.
• Lokāls Exchange uz Gmail, izmantojot GSMMO: Datumi sabojājas. Tas pats mehānisms.
• Gmail uz Gmail (PST eksporta atkārtots imports): Datumi sabojājas. Pat ja sākotnējiem e-pastiem PST failā bija pareizi datumi, atkārtota importēšana tiem uzspiež jaunu laika zīmogu.

Modelis ir skaidrs. Katrs ziņojums, kas augšupielādēts, izmantojot Gmail API, saņem Received: galveni ar augšupielādes dienas datumu. GSMMO vienmēr izmanto šo ceļu.

Īpaši neapmierinoši ir tas, ka GSMMO migrācijas atskaite rāda visu kā veiksmīgu. Nav brīdinājumu par datumiem, nav kļūdu, nav atzīmju. Lai to pamanītu, būtu manuāli jāsalīdzina laika zīmogi pirms un pēc migrācijas, un lielākā daļa administratoru to nedara, kamēr kāds lietotājs nesūdzas.

Ietekme sniedzas tālāk par kārtošanu

Nepareizi datumi pēc GSMMO migrācijas rada reālas problēmas, kas sniedzas tālāk par nekārtīgu iesūtni.

Iedomājieties, ka esat grāmatvedis, kas tikko pārcēlies uz Google Workspace. Jums jāatrod visa klientu sarakste no 2024. gada 3. ceturkšņa nodokļu deklarācijai. Jūs meklējat Gmail pēc datumu diapazona: no jūlija līdz septembrim 2024. gadā. Nevienu rezultātu. Katrs e-pasts no šī perioda tagad rāda migrācijas datumu, tāpēc Gmail datumu filtrs tos nevar atrast. Jūs esat iestrēguši, ritinot tūkstošiem ziņojumu vai meklējot pēc atslēgvārdiem un cerot, ka atceraties pareizos terminus.

Regulētajās nozarēs tas ir vairāk nekā neveiklība. E-pastu laika zīmogi kalpo par juridisku pierādījumu. Finanšu konsultants, kuram jāpierāda, ka viņš nosūtīja informācijas atklāšanu pirms transakcijas datuma, to nevar izdarīt, ja e-pasts rāda 2026. gada aprīli, nevis 2023. gada februāri. Atbilstības auditi saskaņā ar SOX vai HIPAA prasībām paļaujas uz precīziem sarakstes laika zīmogiem, un nepareizi datumi nozīmē neizturētus auditus.

Un tad ir pavedienu problēma. Gmail grupē sarakstes pēc datuma un temata. Kad katrs ziņojums pavedienā rāda vienu un to pašu datumu, sarunas skats sajūk. Atbildes parādās pirms sākotnējā ziņojuma. Visa pavediena struktūra sabrūk kaudzē ar identiski datētiem e-pastiem.

GSMMO datumu labošana ar Redate.io

Labā ziņa: tā sākotnējā Date: galvene joprojām ir neskarta katrā migrētajā e-pastā. GSMMO nemaina ziņojuma saturu. Pareizais datums tur ir, Gmail attēlošanas loģika to vienkārši ignorē, jo INTERNALDATE un augšējā Received galvene norāda uz migrācijas datumu.

Redate.io pieslēdzas Google Workspace pastkastei, skenē e-pastus, ko ietekmējusi GSMMO migrācija, un labo datumu metadatus, izmantojot Redate izstrādātu galveņu ķēdes analīzes un datumu rekonstrukcijas dzinēju. Redate nav nepieciešams zināt, kurš rīks veica migrāciju: tas atrod e-pastus, kuru attēlotais datums neatbilst to sākotnējam datumam, un labo tos, nemainot ziņojuma saturu, pielikumus vai pavedienus.

Katrs izlabotais e-pasts tiek individuāli pārbaudīts: ziņojuma integritāte, pielikumu saglabāšana, etiķešu kartēšana un pavedienu konsekvence. Oriģināli paliek redzamā Redate.io - Originals rezerves mapē jūsu pastkastē, kamēr jūs pats tos neizdzēšat.

Vai jūs varētu to salabot pats ar skriptu? Problēmas izpratne ir viena lieta. 12 000 e-pastu labošana, nesalaužot S/MIME parakstus, nesabojājot iegultās MIME daļas vai nesagraujot RFC 2047 kodētas galvenes reālā darba pastkastē, ir kas pavisam cits. Kā rīkoties ar e-pastu, kuram ir 38 MB liels pielikums un sabojāta MIME robeža, ko GSMMO importēja, bet kas turējās kopā ar pūlēm? Kā pārbaudīt, ka pilnīgi ikviens ziņojums pārgāja neskarts? Skripts, kas darbojas ar 20 testa ziņojumiem laboratorijā, nepārdzīvos reālu pastkasti ar 8 gadu saraksti.

Platformām specifiskas pamācības par GSMMO

Tā kā GSMMO migrē tieši uz Google Workspace, labošana notiek Gmail līmenī. Bet ietekmētie e-pasti ir redzami katrā klientā, kas pieslēgts šim Gmail kontam:

• Izlabojiet GSMMO migrācijas datumus Gmail
• Izlabojiet GSMMO migrācijas datumus programmā Outlook (pieslēgts Google Workspace)
• Izlabojiet GSMMO migrācijas datumus Apple Mail

Jau migrējāt pirms mēnešiem? Sākotnējā Date: galvene laika gaitā nezaudē derīgumu. Redate.io var izlabot GSMMO ietekmētos e-pastus neatkarīgi no tā, vai migrācija notika pagājušajā nedēļā vai pirms trim gadiem.

GSMMO migrācija atstāja jūsu e-pastus ar nepareiziem datumiem? Sāciet bezmaksas skenēšanu, lai redzētu precīzu ietekmēto e-pastu skaitu un labošanas izmaksas, pirms uzņematies jebkādas saistības.