GSMMO muutti sähköpostien päivämäärät? Näin korjaat ne

GSMMO ja päivämääräongelma, josta kukaan ei varoita

Google Workspace Migration for Microsoft Outlook (GSMMO) on työpöytäsovellus, jonka Google tarjoaa PST-tiedostojen, Outlook-profiilien ja paikallisten sähköpostiarkistojen siirtämiseen Gmailiin. Se on ilmainen, virallisesti tuettu, ja se on siirtotapa, jota Google suosittelee, kun pientä tiimiä tai muutamaa yksittäistä postilaatikkoa siirretään Outlookista Google Workspaceen.

Työkalu toimii. Sähköpostit saapuvat Gmailiin, kansiorakenne muuttuu tunnisteiksi, yhteystiedot siirtyvät. Mutta avaa Gmail sen jälkeen ja järjestä päivämäärän mukaan. Jokainen sähköposti näyttää tämän päivän päivämäärän. Se tarjous, jonka lähetit tammikuussa 2021? Huhtikuu 2026. Kirjanpitäjän lasku maaliskuulta 2023? Myös huhtikuu 2026.

GSMMO ei varoita tästä etukäteen. Siirtoloki näyttää onnistumisen jokaiselle viestille. Googlen oma dokumentaatio ei mainitse sitä tunnettuna rajoituksena. Asian huomaa vasta, kun joku etsii vanhaa sähköpostia päivämääräväliltä ja saa nolla tulosta.

Miten GSMMO oikeastaan lataa sähköpostisi

GSMMO lukee viestit PST-tiedostosta (tai suoraan Outlook-profiilista) ja lataa ne Gmailiin Gmail API:n kautta (Googlen omat työkalun julkaisutiedot kertovat tämän). Tästä päivämääräongelma syntyy, ja mekanismi kannattaa ymmärtää, koska se selittää, miksi ratkaisu ei ole niin yksinkertainen kuin "tuo vain uudelleen".

Kun GSMMO lataa viestin Gmail API:n kautta, Gmail lisää uuden Received:-otsikon, joka on päivätty lataushetkeen. Ja kun alkuperäistä päivämäärää ei välitetä viestin mukana, INTERNALDATE, aikaleima, jota Gmail käyttää sisäisesti lajitteluun ja näyttämiseen, asetetaan lataushetkeen alkuperäisen lähetyspäivämäärän sijaan.

Näin otsikkoketju näyttää GSMMO-siirron jälkeen:

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

Näetkö tuon alkuperäisen Date:-otsikon syyskuulta 2019? Se on yhä siellä, koskemattomana. GSMMO ei muuta viestin sisältöä eikä alkuperäisiä otsikoita. Mutta Gmail jättää sen huomiotta näytössä ja käyttää sen sijaan INTERNALDATE-arvoa, joka nyt kertoo huhtikuun 2026.

GSMMO vs. ylläpitäjän siirtotyökalut

Tästä sekaannus usein alkaa. Googlella on useita siirtotyökaluja, eivätkä ne kaikki toimi samalla tavalla.

GSMMO (työpöytäsovellus) toimii käyttäjän koneella. Se lukee Outlookista tai PST-tiedostosta ja lataa sähköpostit Gmail API:n kautta. Käyttäjä tarvitsee Google Workspace -tilin ja GSMMO-lisäosan asennettuna Outlookiin. Se on asiakaspuolen työkalu.

Google Workspace Migration Service (hallintakonsolin työkalu) toimii palvelinpuolella. Järjestelmänvalvoja määrittää sen Google Admin -konsolissa, osoittaa sen Exchange-palvelimeen tai toiseen Google Workspace -vuokralaiseen, ja siirto suoritetaan Googlen infrastruktuurissa. Tällä työkalulla on joissain kokoonpanoissa hieman parempi päivämäärien käsittely, koska se voi asettaa INTERNALDATE-arvon lähteen metatietojen perusteella. Mutta "hieman paremmin" ei tarkoita "luotettavasti", ja monet järjestelmänvalvojat raportoivat saman päivämääräongelman myös tällä työkalulla.

Ratkaiseva ero? GSMMO:ssa ei ole palvelinpuolen älykkyyttä, joka tekisi päätöksiä päivämäärien säilyttämisestä. Jokainen sen lataama viesti saa saman kohtelun, oli se tuore sähköposti tai 10 vuotta vanha arkistoitu viesti: Received:-otsikko, joka on päivätty latauspäivään. Piste.

Miksi GSMMO:n päivämäärien säilyttäminen ei toimi

Jos olet tarkastellut GSMMO:n asetuksia, olet saattanut huomata, että "säilytä päivämäärät" -vaihtoehtoa ei todellisuudessa ole. Se ei ole unohdus. GSMMO nojaa siihen, miten Gmail käsittelee API:n kautta ladatut viestit, eikä voi ohittaa sitä.

Tekninen tapahtumaketju on tämä:

1. GSMMO lukee viestin PST-tiedostosta, mukaan lukien sen alkuperäiset aikaleimat
2. GSMMO lataa viestin datan Gmail API:n kautta
3. Gmail vastaanottaa latauksen ja tallentaa viestin postilaatikkoon
4. Gmail lisää uuden Received:-otsikon, joka on päivätty lataushetkeen (yllä olevan esimerkin gmailapi.google.com-rivi)
5. Kun alkuperäistä päivämäärää ei välitetä, Gmail asettaa INTERNALDATE-arvon latausaikaleimaan
6. Viesti päätyy Gmailiin tämän päivän päivämäärällä

Vaiheet 4 ja 5 ovat ratkaisevia. Gmail lisää tämän otsikon jokaiseen API:n kautta ladattuun viestiin, riippumatta siitä, mitä työkalu lähettää, ja GSMMO:ssa ei ole asetusta, jolla alkuperäinen päivämäärä voitaisiin välittää tai säilyttää. Tuloksena kaikki historialliset sähköpostisi näyttävät saapuneen tänään.

Jotkut järjestelmänvalvojat ovat kokeilleet ajaa GSMMO:ta erilaisilla Google Workspace -asetuksilla käytössä tai säätäneet GSMMO-profiilin asetuksia. Mikään näistä ei vaikuta päivämääräkäyttäytymiseen. Received:-otsikko lisätään Googlen puolella, eikä mikään asiakaspuolen asetus muuta sitä.

GSMMO-skenaariot, jotka rikkovat päivämäärät

Kaikki GSMMO-siirrot eivät pääty päivämääräkaaokseen, vaikka useimmat päätyvät. Tässä on, missä sillä on merkitystä:

• PST-tiedosto Gmailiin: Päivämäärät rikkoutuvat. Tämä on yleisin GSMMO-käyttötapaus ja siihen vaikutus on suurin.
• Outlook-profiili Gmailiin: Päivämäärät rikkoutuvat. Sama Gmail API -lataus kuin PST-tuonnissa.
• Exchange Online (Microsoft 365) Gmailiin GSMMO:lla: Päivämäärät rikkoutuvat. GSMMO lukee Exchange-palvelimelta ja lataa Gmail API:n kautta.
• Paikallinen Exchange Gmailiin GSMMO:lla: Päivämäärät rikkoutuvat. Sama mekanismi.
• Gmail Gmailiin (PST-viennin uudelleentuonti): Päivämäärät rikkoutuvat. Vaikka alkuperäisissä sähköposteissa olisi ollut oikeat päivämäärät PST-tiedostossa, uudelleentuonti leimaa ne uudelleen.

Kaava on selvä. Jokainen Gmail API:n kautta ladattu viesti saa Received:-otsikon, joka on päivätty latauspäivään. GSMMO käyttää aina tätä reittiä.

Erityisen turhauttavaa on se, että GSMMO-siirtoraportti näyttää kaiken onnistuneena. Ei varoituksia päivämääristä, ei virheitä, ei lippuja. Aikaleimoja pitäisi verrata manuaalisesti ennen siirtoa ja sen jälkeen huomatakseen ongelman, ja useimmat järjestelmänvalvojat eivät tee sitä, ennen kuin käyttäjä valittaa.

Vaikutus ulottuu paljon lajittelua pidemmälle

Väärät päivämäärät GSMMO-siirron jälkeen aiheuttavat todellisia ongelmia, jotka ylittävät sotkuisen postilaatikon.

Kuvittele, että olet kirjanpitäjä, joka on juuri siirtynyt Google Workspaceen. Sinun täytyy löytää kaikki asiakaskirjeenvaihto vuoden 2024 kolmannelta neljännekseltä veroilmoitusta varten. Haet Gmailissa päivämääräväliltä: heinäkuu-syyskuu 2024. Nolla tulosta. Jokainen tuon ajanjakson sähköposti näyttää nyt siirtopäivämäärän, joten Gmailin päivämääräsuodatin ei löydä niitä. Jäät selaamaan tuhansia viestejä tai hakemaan avainsanoilla ja toivomaan, että muistat oikeat termit.

Säännellyillä toimialoilla tämä on pahempaa kuin epämukavaa. Sähköpostien aikaleimat toimivat oikeudellisena todisteena. Talousneuvoja, jonka täytyy todistaa lähettäneensä tiedonannon ennen transaktion päivämäärää, ei voi tehdä sitä, kun sähköposti näyttää huhtikuun 2026 helmikuun 2023 sijaan. SOX- tai HIPAA-vaatimustenmukaisuustarkastukset nojaavat tarkkoihin viestintäaikaleimoihin, ja väärät päivämäärät tarkoittavat epäonnistuneita tarkastuksia.

Ja sitten on ketjutusongelma. Gmail ryhmittelee keskustelut päivämäärän ja aiheen mukaan. Kun jokainen viesti ketjussa näyttää saman päivämäärän, keskustelunäkymästä tulee sekava. Vastaukset näkyvät ennen alkuperäistä viestiä. Koko ketjun rakenne romahtaa kasaan identtisesti päivätyiksi sähköposteiksi.

GSMMO-päivämäärien korjaaminen Redate.io:lla

Hyvä uutinen: se alkuperäinen Date:-otsikko on yhä ehjänä jokaisessa siirretyssä sähköpostissa. GSMMO ei muuta viestin sisältöä. Oikea päivämäärä on siellä, Gmailin näyttölogiikka vain jättää sen huomiotta, koska INTERNALDATE ja ylin Received-otsikko osoittavat siirtopäivämäärään.

Redate.io yhdistää Google Workspace -postilaatikkoon, tarkistaa GSMMO-siirron vaikutuksen alaiset sähköpostit ja korjaa päivämäärämetatiedot Redaten kehittämän otsikkoketjuanalyysin ja päivämäärien rekonstruointimoottorin avulla. Redaten ei tarvitse tietää, mikä työkalu siirron teki: se löytää sähköpostit, joiden näytetty päivämäärä ei vastaa niiden alkuperäistä päivämäärää, ja korjaa ne muuttamatta viestin sisältöä, liitteitä tai ketjutusta.

Jokainen korjattu sähköposti käy läpi yksilöllisen varmistuksen: viestin eheys, liitteiden säilyminen, tunnisteiden kohdistus ja ketjun johdonmukaisuus. Alkuperäiset säilyvät oman postilaatikkosi näkyvässä Redate.io - Originals -varmuuskopiokansiossa, kunnes poistat ne itse.

Voisitko korjata tämän itse skriptillä? Ongelman ymmärtäminen on yksi asia. 12 000 sähköpostin korjaaminen rikkomatta S/MIME-allekirjoituksia, vahingoittamatta sisäkkäisiä MIME-osia tai sekoittamatta RFC 2047 -koodattuja otsikoita tuotantopostilaatikossa on aivan eri asia. Miten käsittelet sähköpostin, jossa on 38 Mt liite ja vaurioitunut MIME-raja, jonka GSMMO toi mutta joka tuskin pysyi kasassa? Skripti, joka toimii 20 testiviestillä laboratoriossa, ei selviä oikeasta postilaatikosta, jossa on 8 vuoden kirjeenvaihto.

Alustakohtaiset korjausoppaat GSMMO:lle

Koska GSMMO siirtää nimenomaan Google Workspaceen, korjaus tapahtuu Gmail-tasolla. Mutta vaikutuksen alaiset sähköpostit näkyvät jokaisessa asiakasohjelmassa, joka on yhdistetty kyseiseen Gmail-tiliin:

• Korjaa GSMMO-siirron päivämäärät Gmailissa
• Korjaa GSMMO-siirron päivämäärät Outlookissa (yhdistetty Google Workspaceen)
• Korjaa GSMMO-siirron päivämäärät Apple Mailissa

Siirto tehtiin kuukausia sitten? Alkuperäinen Date-otsikko ei heikkene ajan myötä. Redate.io voi korjata GSMMO:n vaikutuksen alaiset sähköpostit riippumatta siitä, tapahtuiko siirto viime viikolla vai kolme vuotta sitten.

Jättikö GSMMO-siirto sähköpostisi väärillä päivämäärillä? Suorita ilmainen tarkistus nähdäksesi vaikutuksen alaisten sähköpostien tarkan määrän ja korjauksen hinnan, ennen kuin sitoudut mihinkään.