GSMMO muutti sahkopostien paivamaarat? Nain korjaat ne

GSMMO ja paivamaaraongelma josta kukaan ei varoita

Google Workspace Migration for Microsoft Outlook (GSMMO) on tietokoneohjelmisto, jonka Google tarjoaa PST-tiedostojen, Outlook-profiilien ja paikallisten sahkopostiarkistojen siirtamiseen Gmailiin. Se on ilmainen, virallisesti tuettu, ja siirtopolku jonka Google suosittelee kun pienta tiimia tai yksittaisia postilaatikoita siirretaan Outlookista Google Workspaceen.

Tyokalu toimii. Sahkopostit saapuvat Gmailiin, kansiorakenne muuntuu tunnisteiksi, yhteystiedot siirtyvat. Mutta avaa Gmail sen jalkeen ja jarjesta paivamaaraen mukaan. Jokainen sahkoposti nayttaa tanaan paivan paivamaaraen. Se tarjous jonka lahetit tammikuussa 2021? Huhtikuu 2026. Kirjanpitajan lasku maaliskuulta 2023? Myos huhtikuu 2026.

GSMMO ei varoita tasta etukaateen. Siirtoloki nayttaa onnistumisen jokaiselle viestille. Googlen oma dokumentaatio ei mainitse sitae tunettuna rajoituksena. Asian huomaa vasta kun joku etsii vanhaa sahkopostia paivamaaravaalilta ja saa nolla tulosta.

Miten GSMMO oikeastaan lataa sahkopostisi

GSMMO lukee viestit PST-tiedostosta (tai suoraan Outlook-profiilista) ja lataa ne Gmailiin Googlen IMAP-yhdyskaytavan kautta. Tassa paivamaaraongelma syntyy, ja mekanismi kannattaa ymmartaa koska se selittaa miksi ratkaisu ei ole niin yksinkertainen kuin "tuo uudelleen".

Kun GSMMO lataa viestin, Gmailin IMAP-yhdyskaytava kasittelee sen kuin juuri saapuneen sahkopostin. Gmail leimaa viestin uudella Received:-otsikolla joka sisaltaa nykyisen aikaleiman. INTERNALDATE, aikaleima jota Gmail kayttaa sisaisesti lajitteluun ja nayttamiseen, asetetaan lataushetkeen alkuperaisen lahetyspaivamaaran sijaan.

Nain otsikkoketju nayttaa GSMMO-siirron jalkeen:

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

Naetko tuon alkuperaisen Date:-otsikon syyskuulta 2019? Se on yha siella, koskematon. GSMMO ei muuta viestin sisaltoa eika alkuperaisia otsikoita. Mutta Gmail jaattaa sen huomiotta naytossa ja kayttaa sen sijaan INTERNALDATE-arvoa, joka nyt sanoo huhtikuu 2026.

GSMMO vs. yllapitajan siirtotyokalut

Tasta sekaannus usein alkaa. Googlella on useita siirtotyokaluja, eivatka ne kaikki kaytta ydy samoin.

GSMMO (tietokonesovellus) toimii kayttajan koneella. Se lukee Outlookista tai PST-tiedostosta ja lahettaa sahkopostit Googlen IMAP-rajapinnan kautta. Kayttaja tarvitsee Google Workspace -tilin ja GSMMO-lisaosan asennettuna Outlookiin. Se on asiakaspuolen tyokalu, mika tarkoittaa etta Googlen palvelimet nakevat saapuvia viesteja, eivat siirrettya viesteja.

Google Workspace Migration Service (hallintakonsolin tyokalu) toimii palvelinpuolella. Yllapitaja maarittaa sen Google Admin -konsolissa, osoittaa sen Exchange-palvelimeen tai toiseen Google Workspace -vuokralaiseen, ja siirto suoritetaan Googlen infrastruktuurissa. Tama tyokalu kasittelee paivamaariat hieman paremmin joissain kokoonpanoissa koska se voi asettaa INTERNALDATE-arvon lahteen metatietojen perusteella. Mutta "hieman paremmin" ei tarkoita "luotettavasti", ja monet yllapitajat raportoivat saman paivamaaraongelman myos talla tyokalulla.

Ratkaiseva ero? GSMMO:ssa ei ole palvelinpuolen alykkyytta paivamaarien sailyttamiseen. IMAP-yhdyskaytava kasittelee jokaisen ladatun viestin identtisesti, oli se tuore sahkoposti tai 10 vuotta vanha arkistoitu viesti. Se leimaa nykyisen paivamaaraen. Piste.

Miksi GSMMO:n paivamaarien sailyttaminen ei toimi

Jos olet tarkastellut GSMMO:n asetuksia, olet ehka huomannut etta "sailyta paivamaarat" -vaihtoehtoa ei ole. Se ei ole unohdus. GSMMO luottaa Gmailin IMAP-yhdyskaytavan toimintaan paivamaarien kasittelyssa eika voi ohittaa sitae.

Tekninen tapahtumaketju:

1. GSMMO lukee viestin PST-tiedostosta, mukaan lukien alkuperaiset aikaleimat
2. GSMMO yhdistaa Gmailiin IMAP-protokollalla ja lahettaa APPEND-komennon viestidatalla
3. Gmailin IMAP-yhdyskaytava vastaanottaa APPEND-komennon ja kasittelee sen sisaisen kuljetusputken kautta
4. Kuljetusputki lisaa uuden Received:-otsikon nykyisella paivamaraalla
5. Gmail asettaa INTERNALDATE-arvon latausaikaleimaan
6. Viesti paatyy Gmailiin tanaan paivan paivamaraalla

Vaihe 3 on ratkaiseva. Vaikka IMAP APPEND -protokolla teknisesti tukee mukautetun INTERNALDATE-arvon asettamista, Gmailin toteutus ei aina kunnioita sitae, erityisesti GSMMO-reitin kautta. Tulos: kaikki historialliset sahkopostisi nayttavat saapuneen tanaan.

Jotkut yllapitajat ovat kokeilleet ajaa GSMMO:ta erilaisilla Google Workspace -asetuksilla tai saadetyilla GSMMO-profiiliparametreilla. Mikaan naista ei vaikuta paivamaarakayttaytymiseen. Paivamaara leimataan palvelinpuolella, eika mikaan asiakaspuolen konfiguraatio muuta sitae.

GSMMO-skenaariot jotka rikkovat paivamaarat

Kaikki GSMMO-siirrot eivat paady paivamaarakaaokseen, mutta suurin osa patyy. Tassa ovat vaikutuksen alaiset tapaukset:

• PST-tiedosto Gmailiin: Paivamaarat rikkoutuvat. Tama on yleisin GSMMO-kayttotapaus ja eniten vaikutuksen alainen.
• Outlook-profiili Gmailiin: Paivamaarat rikkoutuvat. Sama IMAP-yhdyskaytavan kayttaytyminen kuin PST-tuonnissa.
• Exchange Online (Microsoft 365) Gmailiin GSMMO:lla: Paivamaarat rikkoutuvat. GSMMO lukee Exchange-palvelimelta ja lataa Gmailin IMAP-yhdyskaytavan kautta.
• Paikallinen Exchange Gmailiin GSMMO:lla: Paivamaarat rikkoutuvat. Sama mekanismi.
• Gmail Gmailiin (PST-viennin uudelleentuonti): Paivamaarat rikkoutuvat. Vaikka alkuperaisissa sahkoposteissa olisi ollut oikeat paivamaarat PST-tiedostossa, uudelleentuonti leimaa ne uudelleen.

Kaava on selva. Mika tahansa reitti joka kulkee Gmailin IMAP-yhdyskaytavan kautta latauksen aikana ylikirjoittaa paivamaarat. GSMMO kayttaa aina tatae reittia.

Erityisen turhauttavaa on se, etta GSMMO-siirtoraportti nayttaa kaiken onnistuneena. Ei varoituksia paivamaarista, ei virheita, ei lippuja. Aikaleimoja pitaisi verrata manuaalisesti ennen ja jalkeen siirron havaitakseen ongelman, ja useimmat yllapitajat eivat tee sitae ennen kuin kayttaja valittaa.

Vaikutukset ulottuvat paljon lajittelua pidemmalle

Vaaraet paivamaarat GSMMO-siirron jalkeen luovat todellisia ongelmia jotka ylittavat sotkuisen saapuneet-kansion.

Kuvittele etta olet kirjanpitaja ja olet juuri siirtynyt Google Workspaceen. Sinun taytyy loytaa kaikki asiakaskirjeenvaihto Q3 2024 veroilmoitusta varten. Haet Gmailissa paivamaaravaalilla: heinakuusta syyskuuhun 2024. Nolla tulosta. Jokainen tuon ajanjakson sahkoposti nayttaa nyt siirtopaivamaaran, joten Gmailin paivamaarasuodatin ei loyda niita. Jaat kiinni selaamaan tuhansia viesteja tai hakemaan avainsanoilla ja toivomaan etta muistat oikeat termit.

Saannellyilla toimialoilla tama on pahemp aa kuin aersyttaevaeae. Sahkopostien aikaleimat toimivat oikeudellisena todisteena. Taloudellinen neuvonantaja jonka taytyy todistaa lahettaneensa ilmoituksen ennen transaktion paivamaraaa ei voi tehda sitae kun sahkoposti nayttaa huhtikuu 2026 helmikuun 2023 sijaan. Tietosuoja-asetuksen (GDPR) mukaiset compliance-tarkastukset nojaavat tarkkoihin viestintaaikaimeihin, ja vaaraet paivamaarat tarkoittavat eponnistuneita tarkastuksia.

Ja sitten on keskusteluketjuongelma. Gmail ryhmittelee keskustelut paivamaaraen ja aiheen mukaan. Kun jokainen viesti ketjussa nayttaa saman paivamaaraen, keskustelunakymasta tulee sekava. Vastaukset nakyvaet ennen alkuperaeistae viestiae. Koko ketjurakenne romahtaa kasaan identtisesti paivaatyiksi sahkoposteiksi.

Korjaa GSMMO-paivamaarat Redate.io:lla

Hyva uutinen: se alkuperainen Date:-otsikko on yha ehjana jokaisessa siirretyssa sahkopostissa. GSMMO ei muuta viestin sisaltoa. Oikea paivamaara on siella, Gmailin nayttologiikka vain jaattaa sen huomiotta koska INTERNALDATE ja ylin Received-otsikko osoittavat siirtopaivamaraaan.

Redate.io yhdistaa Google Workspace -postilaatikkoon, skannaa GSMMO-siirron vaikutuksen alaiset sahkopostit ja korjaa paivamaarametatiedot patentoidun otsikkoketjuanalyysin ja paivamaarien rekonstruointimoottrin avulla. Korjaus tunnistaa GSMMO-kohtaiset kaavat Received-otsikkoketjussa (gmailapi.google.com-allekirjoituksen ja paikalliset IMAP-yhdyskaytavatunnisteet) ja suorittaa kohdennetun metatietokorjauksen muuttamatta viestin sisaltoa, liitteita tai ketjutusta.

Jokainen korjattu sahkoposti kay lapi yksilollisen varmistuksen: viestin eheys, liitteiden sailyminen, tunnisteiden kohdistus ja ketjun johdonmukaisuus. Alkuperaiset sailyvat nakyvassa Redate.io - Originals -kansiossa 30 paivan ajan.

Voisitko korjata taman itse skriptilla? Kaytannossa ongelman ymmartaminen on yksi asia. 12 000 sahkopostin korjaaminen rikkomatta S/MIME-allekirjoituksia, vahingoittamatta sisakkaeisia MIME-osia tai tuhoamatta RFC 2047 -koodattuja otsikoita tuotantopostilaatikossa on aivan eri asia. Miten kasittelet sahkopostin jossa on 38 Mt liite ja vaurioitunut MIME-raja jonka GSMMO toi mutta tuskin piti kasassa? Skripti joka toimii 20 testiviestilla laboratoriossa ei selvia oikeasta postilaatikosta jossa on 8 vuoden kirjeenvaihto.

Alustakohtaiset oppaat GSMMO:lle

Koska GSMMO siirtaa nimenomaan Google Workspaceen, korjaus tapahtuu Gmail-tasolla. Mutta vaikutuksen alaiset sahkopostit nakyvat jokaisessa asiakasohjelmassa joka on yhdistetty tuohon Gmail-tiliin:

• Korjaa GSMMO-siirtopaivamaarat Gmailissa
• Korjaa GSMMO-siirtopaivamaarat Outlookissa (yhdistetty Google Workspaceen)
• Korjaa GSMMO-siirtopaivamaarat Apple Mailissa

Siirto tehty kuukausia sitten? Alkuperainen Date-otsikko ei heikkene ajan myota. Redate.io voi korjata GSMMO:n vaikutuksen alaiset sahkopostit riippumatta siita tapahtuiko siirto viime viikolla vai kolme vuotta sitten.

GSMMO-siirto jaetti sahkopostisi vaarilla paivamaarilla? Suorita ilmainen skannaus nahdaksesi tarkan maaran vaikutuksen alaisia sahkoposteja ja korjauksen hinnan, ennen kuin sitoudut mihinkaan.