GSMMO elrontotta az e-mail datumokat? Javitas

Olvasási idő: 8 perc Utolsó frissítés:

A GSMMO és a dátumprobléma, amire senki nem figyelmeztet

A Google Workspace Migration for Microsoft Outlook (GSMMO) az a Google által biztosított asztali eszköz, amellyel PST-fájlokat, Outlook-profilokat és helyi e-mail-archívumokat lehet a Gmailbe migrálni. Ingyenes, hivatalosan támogatott, és ez az a migrációs útvonal, amelyet a Google akkor javasol, ha egy kisebb csapatot vagy néhány egyéni postafiókot telepít át Outlookból Google Workspace-be.

Az eszköz működik. Az e-mailek megérkeznek a Gmailbe, a mappaszerkezet címkékre képeződik le, a névjegyek átjönnek. De nyissa meg utána a Gmailt, és rendezze dátum szerint. Minden e-mail a mai dátumot mutatja. Az a 2021 januárjában küldött ajánlat? 2026 április. A könyvelőtől 2023 márciusában kapott számla? Ugyancsak 2026 április.

A GSMMO nem figyelmeztet erre előre. A migrációs napló minden üzenetnél sikert jelez. A Google saját dokumentációja sem említi ismert korlátozásként. Csak akkor derül ki, amikor valaki dátumtartomány szerint keres egy régi e-mailt, és nulla eredményt kap.

Hogyan tölti fel valójában a GSMMO az e-maileket

A GSMMO a PST-fájlból (vagy közvetlenül az Outlook-profilból) olvassa be az üzeneteket, és a Gmail API-n keresztül tölti fel őket a Gmailbe (ezt az eszköz saját, a Google-tól származó kiadási megjegyzései is megerősítik). Itt keletkezik a dátumprobléma, és érdemes megérteni a mechanizmust, mert ez magyarázza, miért nem olyan egyszerű a javítás, mint az "importáljuk újra" gondolat.

Amikor a GSMMO egy üzenetet a Gmail API-n keresztül tölt fel, a Gmail egy új, a feltöltés pillanatára datált Received: fejlécet ad hozzá. És amikor az eredeti dátum nem kerül átadásra az üzenettel együtt, az INTERNALDATE - a Gmail által a rendezéshez és a megjelenítéshez belsőleg használt időbélyeg - a feltöltés pillanatára áll be, nem az eredeti küldés dátumára.

Így néz ki a fejléclánc egy GSMMO-migráció után:

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

Látja azt az eredeti Date: fejlécet 2019 szeptemberéből? Még ott van, érintetlenül. A GSMMO nem módosítja az üzenet törzsét vagy az eredeti fejléceket. De a Gmail a megjelenítéshez nem ezt veszi figyelembe, hanem az INTERNALDATE-et használja, amely most 2026 áprilisát mondja.

GSMMO és a rendszergazdai oldali migrációs eszközök

Itt kezdődik gyakran a zavar. A Google-nak több migrációs eszköze is van, és nem mindegyik viselkedik egyformán.

A GSMMO (az asztali alkalmazás) a felhasználó gépén fut. Az Outlookból vagy egy PST-fájlból olvas, és a Gmail API-n keresztül tölti fel az e-maileket. A felhasználónak Google Workspace-fiókra és az Outlookba telepített GSMMO-bővítményre van szüksége. Ez egy kliensoldali eszköz.

A Google Workspace Migration Service (az admin konzol eszköze) szerveroldali. A rendszergazda a Google Admin Console-ban konfigurálja, egy Exchange-szerverre vagy egy másik Google Workspace-bérlőre irányítja, és a migráció a Google infrastruktúrájában fut. Ez az eszköz egyes konfigurációkban valamivel jobb dátumkezelést biztosít, mert a forrás metaadatai alapján tudja beállítani az INTERNALDATE-et. De a "valamivel jobb" nem jelenti azt, hogy "megbízható", és sok rendszergazda ugyanezt a dátumproblémát jelenti ezzel az eszközzel is.

Mi a fő különbség? A GSMMO esetében nincs szerveroldali intelligencia, amely döntéseket hozna a dátum megőrzéséről. Minden feltöltött üzenet ugyanazt a kezelést kapja, legyen szó friss e-mailről vagy egy 10 éves archív üzenetről: egy, a feltöltés napjára datált Received: fejlécet. Ennyi.

Miért nem működik a GSMMO dátummegőrzése

Ha megnézte a GSMMO beállításait, észrevehette, hogy nincs valódi "dátumok megőrzése" opció. Ez nem figyelmetlenség. A GSMMO azon alapul, ahogyan a Gmail kezeli az API-ján keresztül feltöltött üzeneteket, és ezt nem tudja felülírni.

Íme az események technikai láncolata:

  1. A GSMMO beolvassa az üzenetet a PST-fájlból, az eredeti időbélyegeivel együtt
  2. A GSMMO az üzenet adatait a Gmail API-n keresztül feltölti
  3. A Gmail fogadja a feltöltést, és eltárolja az üzenetet a postafiókban
  4. A Gmail hozzáad egy új, a feltöltés pillanatára datált Received: fejlécet (a fenti példában a gmailapi.google.com sor)
  5. Amikor az eredeti dátum nem kerül átadásra, a Gmail a feltöltés időbélyegére állítja az INTERNALDATE-et
  6. Az üzenet a mai dátummal landol a Gmailben

A 4. és 5. lépés a kritikus. A Gmail ezt a fejlécet minden, az API-ján keresztül feltöltött üzenethez hozzáadja, függetlenül attól, mit küld az eszköz, és a GSMMO-nak nincs beállítása az eredeti dátum átadására vagy megőrzésére. Az eredmény, hogy minden régi e-mail úgy néz ki, mintha ma érkezett volna.

Néhány rendszergazda kipróbálta a GSMMO futtatását különböző Google Workspace-beállításokkal, vagy módosította a GSMMO profilbeállításait. Ezek közül semelyik nem hat a dátumkezelésre. A Received: fejlécet a Google oldalán adják hozzá, és ezt semmilyen kliensoldali beállítás nem változtatja meg.

Konkrét GSMMO-forgatókönyvek, amelyek elrontják a dátumokat

Nem minden GSMMO-migráció végződik dátum-káoszban, de a legtöbb igen. Itt a lényeg:

  • PST-fájl Gmailbe: A dátumok elromlanak. Ez a leggyakoribb GSMMO-használati eset, és a leginkább érintett.
  • Outlook-profil Gmailbe: A dátumok elromlanak. Ugyanaz a Gmail API-feltöltés, mint a PST-importnál.
  • Exchange Online (Microsoft 365) Gmailbe GSMMO-val: A dátumok elromlanak. A GSMMO az Exchange-szerverről olvas, és a Gmail API-n keresztül tölt fel.
  • Helyszíni Exchange Gmailbe GSMMO-val: A dátumok elromlanak. Ugyanaz a mechanizmus.
  • Gmailből Gmailbe (a PST-export újra-importálása): A dátumok elromlanak. Még ha az eredeti e-maileknek helyes dátumuk volt is a PST-ben, az újraimportálás friss bélyegzőt ad rájuk.

A minta világos. Minden, a Gmail API-n keresztül feltöltött üzenet a feltöltés napjára datált Received: fejlécet kap. A GSMMO mindig ezt az utat használja.

Ami ezt különösen bosszantóvá teszi: a GSMMO migrációs jelentése mindent sikeresként jelez. Nincs figyelmeztetés a dátumokról, nincsenek hibák, nincsenek jelzések. Kézzel kellene összehasonlítania az időbélyegeket a migráció előtt és után, hogy észrevegye, és a legtöbb rendszergazda nem teszi meg ezt, amíg egy felhasználó nem panaszkodik.

A hatás túlmutat a rendezésen

A GSMMO-migráció utáni hibás dátumok valós problémákat okoznak, amelyek túlmutatnak egy rendezetlen postafiókon.

Képzelje el, hogy könyvelő, aki most tért át Google Workspace-re. Meg kell találnia minden 2024 harmadik negyedévéből származó ügyfél-levelezést egy adóbevalláshoz. Dátumtartomány szerint keres a Gmailben: július-szeptember 2024. Nulla eredmény. Az abból az időszakból származó minden e-mail most a migráció dátumát mutatja, így a Gmail dátumszűrője nem találja meg őket. Ott ragad, hogy több ezer üzenetet görgessen végig, vagy kulcsszó szerint keressen, és reménykedjen, hogy jól emlékszik a megfelelő kifejezésekre.

A szabályozott iparágak számára ez rosszabb, mint kényelmetlen. Az e-mail-időbélyegek jogi bizonyítékként szolgálnak. Egy pénzügyi tanácsadó, akinek bizonyítania kell, hogy egy tranzakció dátuma előtt küldött egy tájékoztatót, ezt nem teheti meg, ha az e-mail 2026 áprilisát mutatja 2023 februárja helyett. A SOX vagy a HIPAA szerinti megfelelőségi auditok pontos kommunikációs időbélyegekre támaszkodnak, és a hibás dátumok sikertelen auditokat jelentenek.

Aztán van a szálkezelés problémája is. A Gmail dátum és tárgy szerint csoportosítja a beszélgetéseket. Amikor egy szál minden üzenete ugyanazt a dátumot mutatja, a beszélgetés-nézet összekeveredik. A válaszok az eredeti üzenet előtt jelennek meg. A teljes szálstruktúra egyetlen, azonos dátumú e-mailekből álló halommá omlik össze.

GSMMO-dátumok javítása a Redate.io segítségével

A jó hír: az eredeti Date: fejléc minden migrált e-mail belsejében sértetlen. A GSMMO nem módosítja az üzenet tartalmát. A helyes dátum ott van, csak a Gmail megjelenítési logikája nem veszi figyelembe, mert az INTERNALDATE és a legfelső Received fejléc a migráció dátumára mutat.

A Redate.io csatlakozik a Google Workspace postafiókhoz, átvizsgálja a GSMMO-migráció által érintett e-maileket, és saját fejlesztésű fejléclánc-elemző és dátum-rekonstrukciós motorral javítja ki a dátum-metaadatokat. A Redate-nek nem kell tudnia, melyik eszköz végezte a migrációt: megtalálja azokat az e-maileket, amelyek megjelenített dátuma nem egyezik az eredeti dátumukkal, és kijavítja azokat az üzenet tartalmának, a mellékleteknek és a szálszerkezetnek a megváltoztatása nélkül.

Minden javított e-mail egyedi ellenőrzésen megy át: üzenet-integritás, melléklet-megőrzés, címke-hozzárendelés és szálkövetkezetesség. Az eredetik egy jól látható Redate.io - Originals biztonsági másolat mappában maradnak a saját postafiókjában, amíg saját maga nem törli őket.

Meg lehetne ezt saját kezűleg, egy szkripttel javítani? A probléma megértése egy dolog. 12 000 e-mail kijavítása anélkül, hogy megsértenénk az S/MIME-aláírásokat, megrongálnánk beágyazott MIME-részeket, vagy összekevernénk RFC 2047 szerint kódolt fejléceket egy éles postafiókban, egészen más dolog. Hogyan kezeli azt a 38 MB-os mellékletet tartalmazó e-mailt, amelynek sérült MIME-határa van, és amelyet a GSMMO alig tartott össze az importálás során? Hogyan ellenőrzi, hogy minden egyes üzenet sértetlenül érkezett meg? Egy szkript, ami 20 teszt-üzeneten működik egy laborban, nem éli túl egy valódi postafiókot 8 év levelezésével.

Platformspecifikus útmutatók a GSMMO-hoz

Mivel a GSMMO kifejezetten a Google Workspace-be migrál, a javítás a Gmail szintjén történik. De az érintett e-mailek minden, az adott Gmail-fiókhoz kapcsolt kliensben láthatók:

Már hónapokkal ezelőtt migrált? Az eredeti Date: fejléc nem évül el idővel. A Redate.io ki tudja javítani a GSMMO által érintett e-maileket, akár egy hete, akár három éve történt a migráció.

A GSMMO-migráció hibás dátumokkal hagyta az e-mailjeit? Indítson ingyenes átvizsgálást, hogy megnézze az érintett e-mailek pontos számát és a javítás költségét, mielőtt bármit is vállalna.

Kapcsolódó cikkek