GSMMO a stricat data e-mailurilor? Cum o corectați

GSMMO și problema datei despre care nimeni nu vă avertizează

Google Workspace Migration for Microsoft Outlook (GSMMO) este instrumentul desktop oferit de Google pentru migrarea fișierelor PST, a profilurilor Outlook și a arhivelor locale de e-mail către Gmail. Este gratuit, este susținut oficial și este calea de migrare recomandată de Google atunci când mutați o echipă mică sau câteva cutii poștale individuale din Outlook către Google Workspace.

Instrumentul funcționează. E-mailurile ajung în Gmail, structura folderelor se transformă în etichete, contactele trec și ele. Dar deschideți Gmail după aceea și sortați după dată. Fiecare e-mail arată data de azi. Propunerea trimisă în ianuarie 2021? Aprilie 2026. Factura de la contabil din martie 2023? Tot aprilie 2026.

GSMMO nu vă avertizează că se va întâmpla asta. Jurnalul de migrare arată succes pentru fiecare mesaj. Documentația proprie a Google nu menționează acest lucru ca limitare cunoscută. Descoperiți abia atunci când cineva caută un e-mail vechi după interval de dată și obține zero rezultate.

Cum încarcă GSMMO e-mailul, de fapt

GSMMO citește mesajele din fișierul PST (sau direct din profilul Outlook) și le încarcă în Gmail prin API-ul Gmail (chiar notele de lansare ale Google pentru acest instrument confirmă asta). Aici își are originea problema datei, și merită să înțelegeți mecanismul, pentru că explică de ce corectarea nu este atât de simplă precum "reimportați, pur și simplu".

Când GSMMO încarcă un mesaj prin API-ul Gmail, Gmail adaugă un antet Received: nou, datat în momentul încărcării. Și când data originală nu este transmisă odată cu mesajul, INTERNALDATE, marca temporală pe care Gmail o folosește intern pentru sortare și afișare, este setată la momentul încărcării, nu la data originală de trimitere.

Iată cum arată lanțul de antete după o migrare 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

Vedeți acel antet Date: original din septembrie 2019? Este încă acolo, neschimbat. GSMMO nu modifică corpul mesajului, nici anteturile originale. Dar Gmail îl ignoră în scopul afișării și folosește în schimb INTERNALDATE, care acum arată aprilie 2026.

GSMMO vs. instrumentele de migrare de partea administratorului

Aici începe de multe ori confuzia. Google are mai multe instrumente de migrare, și nu se comportă toate la fel.

GSMMO (aplicația desktop) rulează pe calculatorul utilizatorului. Citește din Outlook sau dintr-un fișier PST și încarcă e-mailurile prin API-ul Gmail. Utilizatorul are nevoie de un cont Google Workspace și de modulul GSMMO instalat în Outlook. Este un instrument de partea clientului.

Google Workspace Migration Service (instrumentul din consola de administrare) este de partea serverului. Un administrator îl configurează în Google Admin Console, îl direcționează către un server Exchange sau către un alt cont Google Workspace, și migrarea se execută în infrastructura Google. Acest instrument are o gestionare puțin mai bună a datei în unele configurații, pentru că poate seta INTERNALDATE pe baza metadatelor din sursă. Dar "puțin mai bună" nu înseamnă "sigură", și mulți administratori raportează aceeași problemă a datei și cu acest instrument.

Care este diferența esențială? Cu GSMMO, nu există nicio inteligență de partea serverului care să decidă cu privire la păstrarea datei. Fiecare mesaj încărcat primește același tratament, fie că este un e-mail proaspăt, fie un mesaj arhivat de 10 ani: un antet Received: datat în ziua încărcării. Atât.

De ce păstrarea datei de către GSMMO nu funcționează

Dacă v-ați uitat la setările GSMMO, poate ați observat că nu există de fapt o opțiune "păstrează data". Nu este o omisiune. GSMMO se bazează pe modul în care Gmail tratează mesajele încărcate prin API-ul său, și nu îl poate suprascrie.

Iată lanțul tehnic de evenimente:

1. GSMMO citește mesajul din fișierul PST, inclusiv marcajele de timp originale
2. GSMMO încarcă datele mesajului prin API-ul Gmail
3. Gmail primește încărcarea și stochează mesajul în cutia poștală
4. Gmail adaugă un antet Received: nou, datat în momentul încărcării (linia gmailapi.google.com din exemplul de mai sus)
5. Când data originală nu este transmisă, Gmail setează INTERNALDATE la marca temporală a încărcării
6. Mesajul ajunge în Gmail cu data de azi

Pașii 4 și 5 sunt cei critici. Gmail adaugă acel antet la fiecare mesaj încărcat prin API-ul său, indiferent ce trimite instrumentul, și GSMMO nu are nicio setare pentru a transmite sau păstra data originală. Rezultatul este că toate e-mailurile dvs. din trecut par să fi ajuns azi.

Unii administratori au încercat să ruleze GSMMO cu anumite setări Google Workspace activate sau să ajusteze setările profilului GSMMO. Niciuna dintre acestea nu afectează comportamentul datei. Antetul Received: este adăugat de partea Google, și nicio configurare de partea clientului nu schimbă asta.

Scenarii GSMMO specifice care strică data

Nu orice migrare GSMMO se termină într-un haos al datei, deși majoritatea da. Iată unde contează:

• Fișier PST către Gmail: Data se strică. Acesta este cazul de utilizare GSMMO cel mai comun și cel mai afectat.
• Profil Outlook către Gmail: Data se strică. Aceeași încărcare prin API-ul Gmail ca la importul PST.
• Exchange Online (Microsoft 365) către Gmail prin GSMMO: Data se strică. GSMMO citește de pe serverul Exchange și încarcă prin API-ul Gmail.
• Exchange on-premises către Gmail prin GSMMO: Data se strică. Același mecanism.
• Gmail către Gmail (reimportul unui export PST): Data se strică. Chiar dacă e-mailurile originale aveau data corectă în PST, reimportul le marchează din nou, cu data curentă.

Modelul este clar. Fiecare mesaj încărcat prin API-ul Gmail primește un antet Received: datat în ziua încărcării. GSMMO folosește mereu această cale.

Ce face acest lucru deosebit de frustrant este că raportul de migrare GSMMO arată totul ca fiind reușit. Fără avertismente despre dată, fără erori, fără marcaje. Ar trebui să comparați manual marcajele temporale înainte și după migrare pentru a observa problema, și majoritatea administratorilor nu fac asta până când un utilizator nu reclamă.

Impactul depășește sortarea

Data greșită după o migrare GSMMO creează probleme reale, dincolo de o cutie de e-mail dezordonată.

Imaginați-vă că sunteți contabil și v-ați mutat de curând la Google Workspace. Trebuie să găsiți toată corespondența cu clienții din trimestrul al treilea din 2024 pentru o declarație fiscală. Căutați în Gmail după interval de dată: iulie - septembrie 2024. Zero rezultate. Fiecare e-mail din perioada respectivă arată acum data migrării, așa că filtrul de dată din Gmail nu le poate găsi. Rămâneți blocat derulând prin mii de mesaje sau căutând după cuvinte cheie și sperând că vă amintiți termenii corecți.

Pentru industriile reglementate, este mai grav decât un inconvenient. Marcajele temporale ale e-mailurilor servesc drept dovadă juridică. Un consultant financiar care trebuie să demonstreze că a trimis o informare înainte de data unei tranzacții nu poate face asta când e-mailul arată aprilie 2026 în loc de februarie 2023. Auditurile de conformitate conform SOX sau HIPAA se bazează pe marcaje temporale corecte ale comunicării, iar data greșită înseamnă audituri picate.

Și mai este problema firului de discuție. Gmail grupează conversațiile după dată și subiect. Când fiecare mesaj dintr-un fir arată aceeași dată, vizualizarea conversației devine amestecată. Răspunsurile apar înaintea mesajului original. Toată structura firului se prăbușește într-un morman de e-mailuri datate identic.

Corectarea datei e-mailurilor GSMMO cu Redate.io

Vestea bună: antetul original Date: este încă intact în interiorul fiecărui e-mail migrat. GSMMO nu modifică conținutul mesajului. Data corectă este acolo, doar că este ignorată de logica de afișare a Gmail, pentru că INTERNALDATE și antetul Received de sus indică data migrării.

Redate.io se conectează la cutia poștală Google Workspace, scanează e-mailurile afectate de migrarea GSMMO și corectează metadatele de dată printr-un motor propriu de analiză a lanțului de antete și de reconstrucție a datei. Redate nu are nevoie să știe care instrument a făcut migrarea: găsește e-mailurile a căror dată afișată nu corespunde datei originale și le corectează fără a modifica conținutul mesajului, atașamentele sau firul de discuție.

Fiecare e-mail corectat trece printr-o verificare individuală: integritatea mesajului, păstrarea atașamentelor, corespondența etichetelor și consistența firului de discuție. Originalele rămân într-un folder de backup vizibil, Redate.io - Originals, în propria dvs. cutie poștală, până când le ștergeți dumneavoastră înșivă.

Ați putea corecta asta singur, cu un script? Înțelegerea problemei este un lucru. Corectarea a 12.000 de e-mailuri fără a rupe semnăturile S/MIME, fără a corupe părțile MIME imbricate sau fără a deforma anteturile codificate RFC 2047 într-o cutie poștală de producție este cu totul altceva. Cum tratați e-mailul cu un atașament de 38 MB și o limită MIME corupată, pe care GSMMO l-a importat, dar l-a ținut cu greu întreg? Cum verificați că fiecare mesaj a trecut intact? Un script care funcționează pe 20 de mesaje de test într-un laborator nu va supraviețui într-o cutie poștală reală cu 8 ani de corespondență.

Ghiduri specifice platformei pentru GSMMO

Pentru că GSMMO migrează specific către Google Workspace, corectarea are loc la nivelul Gmail. Dar e-mailurile afectate sunt vizibile în orice client conectat la acel cont Gmail:

• Corectarea datei de migrare GSMMO în Gmail
• Corectarea datei de migrare GSMMO în Outlook (conectat la Google Workspace)
• Corectarea datei de migrare GSMMO în Apple Mail

Ați migrat deja de câteva luni? Antetul Date original nu se degradează în timp. Redate.io poate corecta e-mailurile afectate de GSMMO, fie că migrarea a avut loc săptămâna trecută, fie acum trei ani.

Migrarea GSMMO v-a lăsat e-mailurile cu dată greșită? Rulați o scanare gratuită pentru a vedea numărul exact de e-mailuri afectate și costul corectării lor, înainte de a vă angaja la ceva.