PST-tuonti Outlookiin: miksi päivämäärät katoavat

Oire: kaikki sähköpostisi ovat tämän päivän päiväisiä

PST-tuonti on valmis. Edistymispalkki on täynnä, kaikki meni hyvin. Avaat postilaatikon... ja jokainen tuotu sähköposti näyttää tämän päivän päivämäärää. Viesti vuodelta 2019, toinen vuodelta 2021, viiden vuoden arkisto: kaikilla on sama päivämäärä. Tuontipäivän päivämäärä.

Tämä ei ole näyttövirhe. Ei myöskään aikavyöhykeongelma. Kyseessä on täysin dokumentoitu käyttäytyminen, joka liittyy siihen, miten IMAP käsittelee päivämäärämetatietoja. Mutta se on silti katastrofi kaikille, jotka tarvitsevat vanhat sähköpostit päivämäärän mukaan järjestettynä.

Paikallinen PST ja IMAP: kaksi täysin erilaista maailmaa

Ennen kuin selitetään, miksi päivämäärät hajoavat, pitää ymmärtää mitä PST-tiedosto tarkoittaa päivämäärien hallinnan kannalta.

PST-tiedosto (Personal Storage Table) on Microsoftin oma tiedostomuoto. Se tallentaa sähköpostit täydellisineen metatietoineen: lähetyspäivä, vastaanottoaika, liitteet, luokat, lukemismerkit. Outlook hallinnoi näitä metatietoja suoraan, ilman mitään viestiprotokollaa. Kun PST avataan Outlookissa ilman palvelinyhteyttä, näytetyt päivämäärät tulevat suoraan PST-tiedoston sisäisistä kentistä. Tähän asti kaikki toimii.

Ongelma ilmaantuu, kun tätä sisältöä yritetään siirtää IMAP-palvelimelle isännöityyn postilaatikkoon, olipa kyseessä Microsoft 365, Google Workspace tai mikä tahansa tavallinen palveluntarjoaja. Silloin poistutaan PST-maailmasta ja astutaan IMAP-maailmaan, jossa säännöt muuttuvat radikaalisti.

IMAP APPEND ja INTERNALDATE: ongelman ydin

IMAP-protokollassa jokaisella palvelimella tallennetulla viestillä on kahdenlaisia päivämäärätietoja:

• Date:-otsake (RFC 2822), joka on osa itse viestin sisältöä. Se on lähettäjän viestiin kirjaama päivämäärä.
• INTERNALDATE, joka on IMAP-palvelimen hallitsema metatieto. Se kuvaa hetkeä, jolloin viesti tallennettiin palvelimelle. Juuri tätä arvoa Outlook käyttää viestien järjestämiseen "Vastaanottopäivä"-näkymässä.

(Jos olet koskaan yrittänyt lukea sähköpostin raakaotsikkeita, tiedät ettei se ole rantakirjallisuutta. Mutta siellä kaikki tapahtuu.)

Kun sähköposti saapuu normaalisti palvelimelle, postipalvelin asettaa INTERNALDATE:n automaattisesti tarkkaan vastaanottohetkeen. Tulos: Outlookissa näytetty päivämäärä vastaa sitä, milloin viesti todellisuudessa saapui.

Kun Outlook tuo PST-tiedostoa IMAP-postilaatikkoon, se käyttää IMAP APPEND -komentoa jokaisen viestin lähettämiseen palvelimelle. IMAP-standardi sallii eksplisiittisen INTERNALDATE:n antamisen APPEND-komennon yhteydessä. Outlook ei kuitenkaan tee näin. Se lähettää viestit ilman INTERNALDATE-määritystä. IMAP-palvelin soveltaa silloin oletussääntöään: INTERNALDATE asetetaan nykyiseen aikaan, eli tuontihetkeen.

Tulos: 8 000 tuotua sähköpostia, kaikilla tämän päivän päivämäärä.

Miksi Outlook toimii näin

Tämä ei ole Microsoftin unohdus. Se on toteutusvalinta, joka on aikoinaan varmasti tuntunut järkevältä: PST-tuonnin alkuperäisessä käyttötapauksessa käyttäjä arkistoi viestejä paikallisesti ja "tuo" ne nykyiseen postilaatikkoonsa. Lajittelun kannalta olennainen päivämäärä olisi alkuperäinen vastaanottoaika... mutta Microsoft päätti olla välittämättä INTERNALDATE:a tuontioperaation yhteydessä.

Tarkasti ottaen tämä käyttäytyminen koskee PST-tuontia Outlookin natiivin ohjatun toiminnon kautta (Tiedosto > Avaa ja vie > Tuo/Vie). Muut tuontimenetelmät, kuten tietyt kolmannen osapuolen työkalut tai Exchange-hallintakeskuksen kautta tehdyt migraatiot, voivat toimia eri tavalla riippuen niiden IMAP APPEND -toteutuksesta.

Tämä käyttäytyminen on ollut tiedossa ja dokumentoitu Microsoftin foorumeilla vuosia. Se ei muuttunut Outlook 2016:n myötä, ei Outlook 2019:n myötä, eikä nykyisten Microsoft 365 -versioiden myötä. Tänään PST:n tuova käyttäjä kohtaa täsmälleen saman ongelman kuin vuonna 2015.

Miten tämä eroaa tavallisesta IMAP-migraatiosta

Tässä käy mielenkiintoiseksi, koska PST-tuonti tuottaa samankaltaisen lopputuloksen kuin tavallinen IMAP-migraatio rikkinäisine päivämäärineen, mutta eri mekanismilla.

Tyypillisessä IMAP-migraatiossa, esimerkiksi BitTitan MigrationWizilla tai imapsyncillä, sähköpostit siirtyvät lähde-IMAP-palvelimelta kohde-IMAP-palvelimelle. Migraatiotyökalu hakee viestit ja lisää ne uudelleen IMAP APPEND -komennolla. Jotkut työkalut säilyttävät INTERNALDATE:n oikein, toiset eivät. Kaikissa tapauksissa viesteille lisätään migraatiopalvelimen Received:-otsake migraatioajankohdalla, mikä voi häiritä Outlookin näyttämää päivämäärää riippumatta INTERNALDATE:sta.

PST-tuonnissa mekanismi on yksinkertaisempi: migraation Received:-otsiketta ei lisätä (PST-tiedostot eivät kulje välipalvelimen kautta), mutta INTERNALDATE:a ei yksinkertaisesti koskaan aseteta oikeaan arvoon. Näkyvä lopputulos on sama, taustalla oleva syy hieman eri.

Tällä erottelulla on suora vaikutus korjaukseen: lähestymistapa ei ole täysin sama IMAP-migraation ja PST-tuonnin välillä. Katso myös miksi INTERNALDATE aiheuttaa rikkinäisiä päivämääriä molempien tapausten yksityiskohtaista selitystä varten.

Miksi Outlookin näkymäasetukset eivät auta

Tavallinen reaktio ongelman löytyessä on kaivella Outlookin asetuksia. Sieltä löytyy todellakin asetus, joka vaikuttaa lupaavalta: mahdollisuus lajitella sähköpostit "Päivämäärän" sijaan "Vastaanottopäivän" mukaan.

Lähetyspäivän mukaan lajittelu ei ole ratkaisu. Se on laastari.

Tässä syy: vaikka vaihtaisi lajittelun näyttämään "Päivämäärä"-sarakkeen (joka vastaa viestin Date:-otsiketta eli alkuperäistä päivämäärää), useita ongelmia jää jäljelle:

• Outlookin haku indeksoi INTERNALDATE:n mukaan. Haku "tammikuun 2020 sähköpostit" ei palauta tuotuja tammikuun 2020 viestejä, koska niiden INTERNALDATE kertoo niiden olevan tuontipäivältä.
• "Tänään", "Tällä viikolla", "Tässä kuussa" -kansiot Outlookin käyttöliittymässä perustuvat INTERNALDATE:en, eivät Date:-otsikkoon.
• Verkkoliittymissä (Outlook Web App, Gmail) ja mobiilisovelluksissa näytetty päivämäärä ja lajittelukäyttäytyminen perustuvat lähes aina palvelimen INTERNALDATE:hen.
• Vastaanottopäivään perustuvat automaattiset säännöt ja suodattimet eivät toimi oikein.

Lyhyesti: näkymän vaihtaminen korjaa näytön yhdelle käyttäjälle, yhdessä sovelluksessa, tietyssä konfiguraatiossa. Se ei korjaa ongelmaa lähteestä.

OST:n uudelleensynkronointi ei auta sekään

Toinen klassinen yritys: tyhjennä OST-välimuisti ja pakota täydellinen uudelleensynkronointi palvelimelta. Ajatus on, että ongelma ehkä johtuu Outlookin paikallisesta välimuistista, ei palvelimesta.

Väärä suunta. OST-tiedosto on paikallinen välimuisti, joka heijastaa IMAP-palvelimen tilaa. Jos INTERNALDATE on virheellinen palvelimella, se on virheellinen myös OST:ssa uudelleensynkronoinnin jälkeen. OST:n poistaminen ei muuta Exchange Online- tai Google Workspace -palvelimelle tallennettuihin tietoihin mitään. Palvelin on ainoa totuuden lähde.

Ainoa tapa korjata päivämäärät on korjata metatiedot suoraan palvelimella, viesti viestiltä. Ja juuri siinä manuaalinen tekeminen muuttuu hankalaksi.

Skaalausongelma: 1 viesti on triviaalia, 15 000 on eri asia

Teknisesti ottaen, jos ongelma ymmärretään, voisi kuvitella kirjoittavansa skriptin, joka käy postilaatikon läpi, lukee jokaisen viestin Date:-otsikon ja korjaa INTERNALDATE:n sen mukaisesti. Ongelman ymmärtäminen on yksi asia. Sen korjaaminen 15 000 sähköpostin kohdalla menettämättä yhtäkään on aivan toinen juttu.

Käytännön realiteetteja:

• Microsoft Graph API:lla ja Gmaililla on pyyntömäärärajoitukset (rate limits). Yksinkertainen skripti aiheuttaa 429 Too Many Requests -virheitä, keskeyttää suorituksen korjauksen puolivälissä ja jättää postilaatikon osittain korjattuna ilman tietoa siitä, mitkä viestit käsiteltiin ja mitkä ei.
• Joissakin PST:n sähköposteissa voi olla puutteellisia tai virheellisiä Date:-otsikoita. Skripti ilman näiden reunatapausten käsittelyä voi vioittaa viestejä tai ohittaa ne hiljaa.
• Allekirjoitetuilla (S/MIME) tai salatuilla (PGP) sähköposteilla on lisäeheysrajoituksia. Metatietojen muuttaminen varomattomasti voi mitätöidä kryptografisen allekirjoituksen.
• Moniosaiset multipart/alternative-rakenteet monimutkaisine MIME-rajoineen reagoivat toisinaan arvaamattomasti muokkausoperaatioihin.
• Ei palautusmekanismia. Jos jokin menee pieleen käsittelyn puolessa välissä, miten palataan alkutilaan?

Skripti, joka toimii 10 testiviestillä, ei toimi 50 000 viestin tuotantopostilaatikossa. Viime vuonna asiakas, jolla oli 40 Gt:n PST-arkisto, yritti korjata tämän Stack Overflowsta löydetyllä Python-skriptillä. Tulos: 3 000 viestiä kahdennettuna, 200 viestiä joihin ei päässyt kiinni liitteiden takia, ja kaksi viikkoa manuaalista siivousta.

Mitä Redate.io tekee tässä tilanteessa

Redate.io analysoi jokaisen viestin metatiedot kohdepostilaatikossa, tunnistaa sähköpostit, joiden päivämäärät ovat virheellisiä (myös PST-tuonnista peräisin olevat), ja soveltaa korjausta sen omistusoikeudellisen moottorin avulla. Monivaiheinen analyysiprosessi vertaa jokaisen viestin otsikkoketjua, poimii alkuperäisen päivämäärän RFC-vaatimustenmukaisuuden validoinnilla ja suorittaa kohdennetun metatietojen korjauksen ilman viestin sisällön muuttamista.

Jokainen korjattu sähköposti tarkistetaan yksitellen. Alkuperäiset säilytetään näkyvässä varmuuskopiointikansiossa 30 päivän ajan ennen lopullisia muutoksia. Korjaus toimii kolmella pääalustalla: Microsoft 365 (Azure AD:n kautta), Google Workspace (toimialueen delegoinnin kautta) ja suora IMAP tavallisille palveluntarjoajille.

Alkuperäinen skannaus on maksuton. Sen avulla näkee tarkalleen kuinka monta sähköpostia on vaikuttunut ja mikä on virheellisten päivämäärien jakauma, ennen kuin päätetään mistään.

Katso myös:

• Sähköpostipäivien korjaus Microsoft 365 -migraation jälkeen
• Outlook: IMAP-migraation päivämääräongelma selitettynä
• Voidaanko päivämäärät korjata migraation jälkeen?

PST-tuonti ylikirjoitti kaikkien sähköpostiesi päivämäärät? Skannaa postilaatikkosi ilmaiseksi Redate.io:ssa ja selvitä ongelman laajuus ennen toimenpiteisiin ryhtymistä.