Uusi Outlook: väärät päivät siirron jälkeen

Kaksi Outlookia, kaksi erilaista käyttäytymistä samoille sähköposteille

Jos olet siirtänyt postilaatikoita Microsoft 365:een hiljattain ja käyttäjät valittavat, että kaikki vanhat sähköpostit näyttävät saman päivämäärän (siirtopäivän), olet saattanut huomata jotain outoa: klassista Outlookia käyttävät näkevät joskus oikean päivämäärän lukunäkymässä, kun taas uuden Outlook for Windowsin käyttäjät näkevät poikkeuksetta siirtopäivämäärän. Sama postilaatikko. Samat sähköpostit. Eri tulokset.

Kyse ei ole varsinaisesti bugista. Se on arkkitehtuurillinen päätös, jolla on suorat seuraukset sille, miten päivämäärät näkyvät IMAP-siirron jälkeen. Ilmiön ymmärtämiseksi täytyy sukeltaa sähköpostiotsikoiden ja IMAP-protokollan yksityiskohtiin, mikä ei ole kevyttä luettavaa, mutta selittää, miksi mikään asiakaspuolen muutos ei riitä korjaamaan ongelmaa.

IMAP INTERNALDATE: todellinen syyllinen

Kun sähköposti tallennetaan IMAP-palvelimelle, sillä on kaksi rinnakkaista päivämäärätyyppiä, jotka eivät sekoitu toisiinsa.

Ensimmäinen on Date:-otsikko, joka on määritelty RFC 2822:ssa. Se on itse viestiin kirjoitettu päivämäärä, jonka lähettäjä on asettanut sähköpostia lähettäessään. Se on osa viestin sisältöä eikä muutu koskaan, riippumatta siitä mitä reittiä sähköposti kulkee sen jälkeen.

Toinen on INTERNALDATE, jota IMAP-palvelin hallitsee viestin ulkopuolella. Se on päivämäärä, jolloin palvelin on tallentanut viestin. Normaalin siirron yhteydessä asialliset työkalut säilyttävät alkuperäisen INTERNALDATEn. Mutta huonosti konfiguroidussa siirrossa, tai tietyillä työkaluilla jotka eivät käsittele tätä metatietoa oikein, INTERNALDATE nollataan siirtopäivään. Tulos: kaikilla siirretyillä sähköposteilla on sama saapumispäivä palvelimen silmissä.

(Muuten, jos olet joskus lukenut imapsyncing tai MigrationWizin lokeja, tiedät että on olemassa erityisiä asetuksia INTERNALDATEn säilyttämiseen. Ne eivät aina toimi, ja jotkin kohdepalvelimet yksinkertaisesti kieltäytyvät kunnioittamasta niitä.)

Klassinen Outlook: miten se lukee päivämäärät

Klassinen Outlook, eli paikallisesti asennetut COM-versiot (Outlook 2016, 2019, 2021 sekä Microsoft 365 Apps -työpöytäasiakas), käyttää hieman monimutkaisempaa mekanismia sen määrittämiseen, mikä päivämäärä viestilistauksessa näytetään.

Lähetetyissä viesteissä se nojautuu Date:-otsikkoon. Vastaanotetuissa viesteissä se käyttää ensisijaisesti palvelimen INTERNALDATEa, mutta tietyissä tilanteissa (erityisesti OST-välimuistin ollessa käytössä tai lukunäkymän ensinäyttöhetkellä) se saattaa myös lukea Received:-otsikkoketjua arvioidakseen alkuperäisen päivämäärän.

Tästä johtuu hämmentävä käyttäytyminen: klassinen Outlook voi joskus näyttää oikean päivämäärän lukunäkymässä, koska se lukee viestin alkuperäisen Date:-otsikon yksityiskohtaista esikatselua varten, vaikka itse viestilista käyttää korruptoitunutta INTERNALDATEa. Tämä ei kuitenkaan ole luotettavaa eikä se korjaa mitään. Lajittelu pysyy rikkinäisenä, päivämäärähaut pysyvät vääristyneinä.

Uusi Outlook: täysin erilainen arkkitehtuuri

Uusi Outlook for Windows, jota on otettu käyttöön asteittain vuoden 2023 lopusta lähtien, ei ole enää COM-sovellus. Se on käytännössä Progressive Web App (PWA), joka perustuu samaan koodipohjaan kuin Outlook verkossa (OWA). Tällä uudelleensuunnittelulla on merkittäviä seurauksia.

Uusi Outlook delegoi päivämäärien näyttämisen kokonaan Microsoft 365:n rajapinnalle. Se ei lue Received:-otsikoita, ei kaiva otsikkoketjuun etsiäkseen alkuperäistä päivämäärää, eikä tee mitään yritystä rekonstruoida sitä asiakaspuolella. Se näyttää yksinkertaisesti sen, mitä palvelin palauttaa: INTERNALDATEn.

Tulos: jos INTERNALDATE on korruptoitunut siirron yhteydessä, uudella Outlookilla ei ole epäilyksen häivää. Se näyttää siirtopäivämäärän jokaiselle kyseiselle sähköpostille, ilman poikkeuksia, ilman vivahteita. Käyttäytyminen on johdonmukaisempaa ja ennakoitavampaa kuin klassisessa Outlookissa, mutta se tekee siirto-ongelmasta välittömästi näkyvän ja mahdottoman sivuuttaa.

Admin, joka siirtää 300 postilaatikkoa perjantai-iltana, löytää maanantaiaamuna, että kaikki uuden Outlookin käyttäjät näkevät koko arkistonsa päivättynä viime viikonlopulta. Tiketit alkavat tulla nopeasti.

Miksi asiakaspuolen kiertotiet eivät toimi

Monet adminit kokeilevat asiakaspuolen ratkaisuja ennen kuin ymmärtävät, että ongelma on palvelimen datassa. Tässä tyypilliset yritykset ja selitys sille, miksi ne epäonnistuvat.

Lajittelu "Lähetyspäivämäärän" mukaan vastaanottopäivän sijaan

Outlookin lajittelu lähetyspäivän mukaan perustuu viestin Date:-otsikkoon, joka on ehjä. Joten kyllä, tämä lajittelu voi toimia. Mutta se on laastari, ei ratkaisu. Päivämäärähaut pysyvät rikkinäisinä. Päivämäärään perustuvat säännöt pysyvät käyttökelvottomina. Ja ennen kaikkea, käyttäjän täytyy manuaalisesti konfiguroida jokainen kansio, jokainen postilaatikko uudelleen. 300 postilaatikolla se on epärealistista. Lajittelu lähetyspäivän mukaan ei ole ratkaisu, ja loppukäyttäjät eivät ymmärrä, miksi heidän pitää muuttaa tapojaan.

Outlookin välimuistin tyhjentäminen tai profiilin uudelleenluominen

Se ei koske palvelinpuolen INTERNALDATEa. Profiilin uudelleenluomisen jälkeen Outlook synkronoi sähköpostit uudelleen palvelimelta ja hakee täsmälleen samat korruptoituneet metatiedot. Välimuisti ei ole ongelma.

OWAn käyttäminen vaihtoehtona

OWA ja uusi Outlook jakavat saman tietokannan. Jos INTERNALDATE on korruptoitunut Exchange Online -palvelimella, OWA näyttää täsmälleen saman väärän päivämäärän. Asiakassovelluksen vaihtaminen ei muuta dataa.

Ongelma on palvelimella, jokaisen viestin metatiedoissa. Mikään asiakaspuolen toimenpide ei pysty korjaamaan palvelinpuolelle tallennettua dataa.

Received-otsikkojen ansa: miksi se monimutkaistaa kaiken

Kun siirtotyökalu kopioi sähköpostin IMAP:n kautta palvelimelta toiselle, kohdepalvelin lisää automaattisesti Received:-otsikon ketjun alkuun, lisäysajankohdan päivämäärällä ja kellonajalla. Tämä on RFC-yhteensopivien SMTP- ja IMAP-palvelimien normaali käyttäytyminen.

Nämä otsikot kertyvät käänteisessä järjestyksessä sähköpostin kulkemaan polkuun nähden. Uusin on ylimpänä. Jotkut sähköpostiohjelmat lukevat ensimmäisen Received:-otsikon arvioidakseen saapumispäivän, mikä antaa siirtopäivämäärän alkuperäisen päivämäärän sijaan.

Tarkennus: tämä käyttäytyminen ei ole ominaista vain yhdelle työkalulle. BitTitan MigrationWiz, CloudM, imapsync, GSMMO ja jopa manuaalinen IMAP-kopiointi kahden Thunderbird-asiakkaan välillä tuottavat kaikki saman tuloksen. Alkuperäinen Date:-otsikko säilyy ehjänä viestissä. Juuri tämä tekee korjauksen teknisesti mahdolliseksi. INTERNALDATE sen sijaan on erillinen palvelimen hallitsema metatietokenttä, eikä sitä voi korjata manipuloimalla viestin otsikoita asiakaspuolella.

Lisätietoja tästä mekanismista löytyy artikkelista IMAP INTERNALDATE: miksi päivämäärät hajoavat, jossa käsitellään yksityiskohtaisesti, miten eri palvelimet hallitsevat tätä metatietoa.

Mitkä siirtotyökalut aiheuttavat tämän ongelman Microsoft 365:ssä

Kysymys nousee usein esiin: aiheuttavatko kaikki siirtotyökalut tämän ongelman?

Lyhyt vastaus on, että se riippuu konfiguraatiosta ja kohdeympäristöstä. Exchange Online / Microsoft 365:ssä palvelin on erityisen tarkka INTERNALDATEn käsittelyssä. Jopa työkalut, jotka yrittävät säilyttää sen, epäonnistuvat joskus, koska Graph API:lla ja EWS:llä (Exchange Web Services) on erilainen käyttäytyminen riippuen käytetystä lisäysreitistä.

BitTitan MigrationWiz on yksi yleisimmistä Microsoft 365 -siirtotyökaluista, ja se on myös yksi parhaiten dokumentoiduista päivämääräongelmien aiheuttajista. Sivu BitTitan-siirron päivämäärien korjaaminen Microsoft 365:ssä kattaa tarkkailtavat erityiskonfiguraatiot. CloudM:llä ja imapsyncilla on omat erityispiirteensä, jotka on dokumentoitu omilla sivuillaan: CloudM-siirron päivämäärien korjaus Microsoft 365:ssä ja imapsync-siirron päivämäärien korjaus Microsoft 365:ssä.

Kaikkien näiden työkalujen yhteinen piirre: alkuperäinen Date:-otsikko säilyy siirron läpi. Se on perusta, jonka varaan korjaus voidaan rakentaa.

Miksi itse tehty skripti on huono idea tässä

Ongelman ymmärtäminen antaa joskus illuusion siitä, että ratkaisu on yksinkertainen. Se ei ole, ei tuotantomittakaavassa.

Exchange Onlineen tallennettujen sähköpostien metatietojen muokkaaminen ei ole triviaalia. Microsoftin Graph API asettaa tiukat nopeudenrajoitukset (429 Too Many Requests -virhe yöaikaisessa erässä tulee vastaan nopeasti). S/MIME-allekirjoitettujen tai PGP-salattujen sähköpostien käsittely vaatii erityistä huolellisuutta, jotta allekirjoitukset eivät mitätöidy. Suurten liitetiedostojen sisältämät multipart-rakenteet lisäävät verkkoaikakatkaisuihin liittyviä rajoitteita. Ja ennen kaikkea: miten varmistat sähköposti kerrallaan, että korjaus on onnistunut muuttamatta sisältöä tai liitetiedostoja?

Skripti, joka toimii hyvin 50 testitähköpostilla, ei käyttäydy samoin 40 000 viestin postilaatikossa, jossa on 8 vuotta historiaa. Todennäköisyys, että jokin reunatapaus rikkoo jotain, kasvaa jokaisen lisätuhannen viestin myötä. Ilman rollback-mekanismia kesken jäänyt virhe jättää postilaatikon epäjohdonmukaiseen tilaan.

Katso myös: sähköpostipäivien korjaus Microsoft 365 -siirron jälkeen saadaksesi kattavan yleiskuvan käytettävissä olevista vaihtoehdoista.

Mitä Redate.io tekee käytännössä

Redate.io avaa postilaatikon sen jälkeen, kun käyttäjä kirjautuu sisään omalla Microsoft-tilillään, eikä vaadi sovelluksen rekisteröintiä. Jos organisaatio vaatii järjestelmänvalvojan hyväksynnän, Redate.io valmistelee linkin sitä varten. Se skannaa sähköpostit joilla on väärät päivämäärät maksutta, ja soveltaa tunnistettuihin viesteihin omaa korjausohjelmistoaan. Monivaiheinen analyysipipeline suorittaa mallivertailun satoihin tunnettujen siirtotyökalujen allekirjoituksiin, RFC-yhteensopivuustarkistuksen sekä otsikkoketjuanalyysin päivämäärän metatietojen rekonstruoimiseksi.

Jokainen korjattu sähköposti tarkistetaan yksittäin. Redate.io ei koskaan poista alkuperäisiä viesteja. Ne pysyvät näkyvässä varmuuskopiointikansiossa omassa postilaatikossa, kunnes poistat ne itse. Hinnoittelumalli on kertaluonteinen maksu postilaatikkoa kohden, ilman tilausmaksua.

Uusi Outlook näyttää sen jälkeen oikeat päivämäärät, koska palvelindata on korjattu, ei piilotettu.

Onko sinulla uudella Outlookilla kärsivällisiä postilaatikoita? Käynnistä maksuton skannaus Redate.io:ssa selvittääksesi tarkasti, kuinka monta sähköpostia on ongelmaisia ennen kuin päätät seuraavista toimenpiteistä.