eM Client: väärät päivämäärät PST- tai Thunderbird-tuonnin jälkeen

Oire: kaikissa sähköposteissa sama päivämäärä

Olet juuri tuonut PST-tiedoston eM Clientiin, tai siirtänyt postilaatikon Thunderbirdistä uuteen tiliisi. Tuonti sujui ilman näkyviä virheitä. Mutta kun avaat saapuneet-kansion, jokin on pielessä: sadat tai jopa tuhannet sähköpostit kantavat samaa päivämäärää, tuontipäivää. Vuodelta 2019 oleva viesti näyttää saapuneen eilen. Kolme vuotta sitten allekirjoitettu sopimus on kuin juuri vastaanotettu.

Ensimmäinen reaktio on syyttää eM Clientia. Väärä asetus, väärä lajittelusarake, näyttövirhe... Selataan asetukset läpi. Vaihdetaan "Vastaanottoaika" ja "Lähetysaika" välillä. Mikään ei muutu. Tai oikeastaan jotain muuttuu, mutta ongelman ydin jää koskematta.

Se johtuu siitä, että ongelma ei ole eM Clientissa. Se on palvelimen metatiedoissa.

Todellinen syy: IMAP INTERNALDATE ylikirjoitettiin tuonnin aikana

Jotta ymmärtää, mitä tapahtui, täytyy mennä askel syvemmälle ja katsoa, miten IMAP-protokolla varastoi sähköposteja.

Jokaisella IMAP-palvelimella olevalla viestillä on kaksi erillistä päivämäärätyyppiä:

• Date:-otsikko (RFC 2822:n mukainen): lähettäjän viestiä kirjoittaessaan asettama päivämäärä. Se on upotettuna viestin sisältöön, periaatteessa koskemattomana.
• INTERNALDATE: palvelimen metatietokenttä, viestin ulkopuolinen, joka kertoo milloin viesti tallennettiin postilaatikkoon. Sähköpostiohjelmat käyttävät tätä arvoa ensisijaisesti viestien lajittelussa ja näyttämisessä.

PST-tuonnin tai Thunderbird-siirron yhteydessä tuontityökalu (oli se sitten eM Clientin oma moduuli, kolmannen osapuolen ohjelma tai manuaalinen IMAP-kopiointi) tallentaa viestit kohde-IMAP-palvelimelle. Jos työkalu ei säilytä eksplisiittisesti alkuperäistä INTERNALDATEa tallennushetkellä, palvelin asettaa automaattisesti nykyisen ajan, eli tuonnin päivämäärän ja kellonajan.

Tulos: 8 000 vuodesta 2017 arkistoitua sähköpostia, kaikki leimattu "vastaanotetuksi" migraatiohetkellä.

(Muuten, jos olet joskus yrittänyt lukea sähköpostin raakaotsikkoja eM Clientin Näytä lähde -toiminnolla, olet ehkä huomannut, että alkuperäinen Date:-otsikko on siellä, ehjänä. Se on merkki siitä, että ongelma on palvelimen INTERNALDATEssa, ei itse viestissä.)

Miksi lajittelusarakkeen vaihtaminen ei auta

Hämmennys johtuu erottelusta, jonka harvat tuntevat. eM Clientissa, kuten Outlookissa ja Thunderbirdissäkin, on yleensä kaksi päivämääräsaraketta:

• "Vastaanottoaika" (tai "Saapumisaika"): perustuu palvelimen INTERNALDATEen.
• "Päivämäärä" tai "Lähetysaika": perustuu viestin Date:-otsikkoon.

Monet ylläpitäjät löytävät tämän ja luulevat löytäneensä ratkaisun: vaihdetaan lajittelu "Lähetysaikaan", ja ongelma katoaa eM Clientin näkymässä. Se ei kuitenkaan ole aivan oikein.

Oikeastaan, vaikka eM Clientissa lajittelisi lähetysajan mukaan, ongelma jatkuu kaikissa muissa asiakasohjelmissa ja käyttöliittymissä, jotka käyttävät samaa postilaatikkoa. Jos käyttäjät lukevat sähköposteja OWA:sta, toimiston Outlookista, mobiilisovelluksesta tai mistä tahansa IMAP-yhteydellä konfiguroidusta ohjelmasta, he näkevät tuontipäivät. eM Clientin lajitteluasetus koskee vain eM Clientia, eikä se vaikuta palvelimelle tallennettuihin metatietoihin.

Lisäksi Microsoft 365:ssä ja Google Workspacessa natiivi verkkokäyttöliittymä lajittelee INTERNALDATEn mukaan. Tätä käytöstä ei voi muuttaa asiakassovelluksesta käsin.

Lajittelu lähetysajan mukaan ei ole ratkaisu. Se on laastari, joka peittää todellisen ongelman sitä korjaamatta.

PST-tuonnin erityispiirteet

PST-tiedostojen tuonti ansaitsee oman osionsa. PST (Personal Storage Table) on Microsoftin suljetun lähdekoodin muoto, joka varastoi sähköposteja, yhteystietoja ja kalenterimerkintöjä paikallisesti. Kun PST tuodaan eM Clientiin, on kaksi mahdollista skenaariota:

• Paikallinen tuonti IMAP-tilille: eM Client lukee PST:n ja siirtää viestit kohde-IMAP-palvelimelle. Jos tallennushetken päivämäärää ei säilytetä, INTERNALDATE ylikirjoituu. Tämä on yleisin tapaus, ja juuri tässä päivämäärät menevät rikki.
• Tuonti paikalliseen kansioon: viestit jäävät koneelle, palvelimen ulkopuolelle. INTERNALDATEa ei ole tässä yhteydessä olemassa, ja eM Client voi näyttää viestin Date:-otsikon. Päivämääräongelmia on vähemmän, mutta käytännön hyötykin on vähäisempi.

Thunderbirdin osalta tilanne on samanlainen. Jos käytetään eM Clientin sisäänrakennettua tuontitoimintoa (joka lukee Thunderbird-profiileja) tai jos mbox-kansioita on kopioitu IMAP:n kautta, viestit tallennetaan palvelimelle ilman takeita INTERNALDATEn säilymisestä. Palvelin, joka vastaanottaa viestin ilman eksplisiittistä päivämääräohjetta INTERNALDATElle, aikaleimaa sen vastaanottohetkellä automaattisesti.

Mitä alustoja tämä koskee?

Ongelma on sama riippumatta kohdealustasta, koska kyse on IMAP-protokollan vakiokäytöksestä:

• Microsoft 365 / Exchange Online: INTERNALDATE ylikirjoittuu kaikissa tuonneissa, joissa ei käytetä IMAP APPEND -komentoa eksplisiittisellä päivämääräparametrilla. Sama koskee siirtoa paikallisesta Exchange-ympäristöstä.
• Google Workspace: sama käytös. eM Clientilla tai kolmannen osapuolen työkaluilla tuodut viestit näyttävät tuontipäivän Gmailissa ja hallintakonsolin näkymässä.
• Perinteiset IMAP-palvelimet (kuten erilaiset webhotellitarjoajat): ei erityistä päivämääräkäsittelyä APPEND-vastaanoton yhteydessä. INTERNALDATE on tallennushetken päivä.

Eräs asiakas otti yhteyttä siirrettyään yli sata postilaatikkoa Exchange 2013:sta Microsoft 365:een käyttäen eM Clientia siirtymävälineenä joidenkin VIP-tilien kohdalla. Tulos: MigrationWizilla oikein siirretyt postilaatikot olivat kunnossa, mutta eM Clientin kautta kulkeneet postilaatikot kantoivat kaikki tuontipäivää. Käyttäjät eivät olleet tyytyväisiä, kuten voi arvata.

Miksi oma skripti ei ratkaise tätä helposti

Teknisesti voisi ajatella, että IMAP-protokollan tunteva henkilö kirjoittaisi skriptin INTERNALDATEjen korjaamiseksi. Alkuperäinen Date:-otsikko on siellä, ehjänä jokaisessa viestissä. Pitäisi vain lukea se ja rakentaa palvelimen metatiedot sen mukaan, eikö niin?

Teoriassa kyllä. Käytännössä se on miinakentällä kävelyä.

Ensinnäkin reunatapaukset kertyvät nopeasti tuotantopostilaatikossa. Digitaalisesti allekirjoitetut S/MIME-viestit ovat erityisen herkkiä rakenteen manipuloinnille. Sama koskee PGP-salattuja viestejä. Sähköpostit, joissa on suuria liitetiedostoja, epästandardeja MIME-rajoja tai epätavallisia Content-Transfer-Encoding-arvoja, voivat korruptoitua äänettömästi, jos käsittely ei ole riittävän huolellista. Skripti, joka toimii 50 testisähköpostilla, ei toimi luotettavasti 20 000 viestin postilaatikossa, jossa on 6 vuotta historiaa.

Toiseksi API-kiintiöiden hallinta. Microsoft 365:ssä Graph API:n tai EWS:n nopeusrajoitukset aamuyöllä 8 000 viestin korjauserän aikana ovat hallittavissa. Mutta ne eivät hallitse itse itseään. Valvomaton skripti, joka kohtaa 429 Too Many Requests -virheen viestiä nro 3741 käsitellessä, saattaa jatkua tai ei. Et välttämättä tiedä, mitkä viestit on käsitelty.

Ja ennen kaikkea: miten varmistat, että jokainen korjattu sähköposti on ehjä käsittelyn jälkeen? Kotitekoisessa skriptissä ei yleensä ole yksittäistä viestiä koskevaa tarkistusmekanismia. Redate.io tekee sen automaattisesti, jokaiselle viestille.

Päivämäärien korjaus lähteellä Redate.io:n avulla

Redate.io tarttuu ongelmaan siellä, missä se sijaitsee: palvelimen metatietojen tasolla, ei sähköpostiohjelman tasolla.

Prosessi alkaa ilmaisella skannausvaiheella. Redate.io muodostaa yhteyden kyseessä olevaan postilaatikkoon (Microsoft 365 Azure AD:n kautta, Google Workspace toimialuedelegoinnin kautta tai suoraan IMAP:lla perinteisille palvelinasiakkaille) ja tunnistaa viestit, joiden päivämäärän metatiedot ovat ristiriidassa viestin sisällön kanssa. Tulokset näkyvät ennen kuin mitään maksetaan.

Korjaus käyttää omaa moottoria, joka analysoi jokaisen viestin koko otsikkoketjun, sovittaa sen sadoille tunnettujen tuontityökalujen signatuureille (mukaan lukien eM Clientin, Thunderbirdin ja PST-tuontien erityiskäytökset), ja rekonstruoi päivämäärän metatiedot kohdistetusti muuttamatta viestin sisältöä, liitetiedostoja eikä MIME-rakennetta.

Jokainen korjattu sähköposti tarkistetaan yksitellen. Alkuperäiset säilytetään näkyvässä varmuuskopiointikonsiossa 30 päivän ajan. Kotitekoisella skriptillä tämä ei onnistu oletuksena.

Hinnoittelu on yksinkertainen: kertamaksu postilaatikkoa kohden, korjattavien viestien määrän perusteella. Ei tilausta, ei toistuvia maksuja. Katso aloitussivulta tarkemmat tiedot.

Seuraavaa migraatiota varten: mitä kannattaa tarkistaa

Jos suunnittelet migraatiota ja haluat välttää tämän ongelman etukäteen, tarkistuspiste on yksinkertainen: säilyttääkö käyttämäsi työkalu INTERNALDATEn eksplisiittisesti, kun viestit tallennetaan kohdepalvelimelle?

PST-tuonneissa Microsoft 365:een Microsoftin sertifioimat työkalut (kuten MigrationWiz natiivimoodeissaan tai Exchange Onlinen oma siirtotyökalu) yleensä huolehtivat tästä säilyttämisestä. Manuaalisissa tuonneissa eM Clientin tai Thunderbirdin kautta näin on harvoin. Tarkista työkalusi dokumentaatio ennen kuin käynnistät tuonnin tuotantopostilaatikoille.

Hyvä sähköpostimigraation tarkistuslista sisältää aina päivämäärävarmistuksen muutamalle postilaatikolle migraation jälkeen. Lisätietoja löytyy artikkelista sähköpostimigraation tarkistuslista: päivämääräongelmat kuriin.

Ylläpitäjille, jotka hallinnoivat migraatioita säännöllisesti asiakkailleen, artikkeli MSP: asiakkaiden sähköpostien päivämääräkorjaus ja IMAP INTERNALDATE: miksi päivämäärät hajoavat antavat kattavamman kuvan ongelmasta.

eM Client -tuonnin jälkeen sähköpostien päivämäärät ovat rikki? Käynnistä ilmainen skannaus Redate.io:ssa ongelman laajuuden selvittämiseksi ennen kuin päätät, mitä teet.