Väärinpäiväiset sähköpostit Exchange Online -siirron jälkeen

Klassinen maanantaiaamun skenaario

IMAP-siirto Exchange Onlineen on juuri valmistunut. Eräajo päättyi virheettä Exchange-hallintakeskuksessa, postilaatikot ovat synkronoituja ja käyttäjät pääsevät kirjautumaan sisään. Suljet tietokoneesi perjantai-iltana tyytyväisenä.

Maanantaiaamuna tikettejä alkaa sadella. "Kaikki sähköpostini ovat perjantain päivältä." "Saapuneet-kansiosta ei saa mitään selvää." "Vanhoja sähköposteja puuttuu." Mitään ei oikeasti puutu: sähköpostit ovat tallessa, mutta Outlook näyttää ne kaikki siirron päivämäärällä alkuperäisen lähetyspäivän sijaan. Vuodelta 2019 peräisin oleva viesti näyttää saapuneen viime perjantaina. Koko postilaatikko vaikuttaa sisältävän vain tuoreita viestejä.

Tämä on yksi turhauttavimmista IMAP-siirtojen ongelmista Exchange Onlineen, ja Microsoft dokumentoi sen lähes järjestelmällisesti puutteellisesti.

Miksi EAC-siirto rikkoo päivämäärät

Kun käytät Exchange-hallintakeskusta (EAC) IMAP-siirron konfigurointiin paikalliselta palvelimelta (Dovecot, Courier, Cyrus, UW-IMAP tai jokin muu), Exchange Online muodostaa yhteyden lähdepalvelimeen IMAP-protokollalla, hakee viestit ja lisää ne kohdekäyttäjien postilaatikoihin oman sisäisen siirtoputkensa kautta.

Juuri siinä ongelma syntyy.

Jokainen Exchange-siirtoputken läpikäyvä sähköposti saa automaattisesti aikaleimallisen Received:-otsakkeen. Tämä on SMTP- ja IMAP-palvelimien vakiokäyttäytymistä vuosikymmenten ajalta: jokainen viestiin koskeva palvelin lisää oman aikaleimansa. Ongelma on siinä, että Outlook (erityisesti Windowsin Outlook tuoreissa versioissa) käyttää uusinta Received:-otsiketta näytön viitemääreenä silloin, kun muut metatiedot ovat moniselitteisiä.

Alkuperäinen Date:-otsikko, se joka kertoo milloin sähköposti todella lähetettiin RFC 2822:n tarkoittamassa mielessä, on yhä viestissä mukana. Sitä ei ole poistettu. Mutta se jää "varjoon" sen uuden Received:-otsikon alle, jonka Exchange lisäsi viestin siirron yhteydessä.

Samaan aikaan IMAP INTERNALDATE (se metatietokenttä, jota IMAP-palvelimet käyttävät viestien sisäiseen ajoitukseen ja joka ohjaa järjestystä useimmissa sähköpostiohjelmissa) asetetaan syöttöpäivämäärään, ei viestin alkuperäiseen päivämäärään. Exchange Onlinessa ei ole mitään natiivia tapaa säilyttää lähdepalvelimen INTERNALDATE-arvoa EAC:n eräajomigraatioissa.

EAC vs. kolmannen osapuolen työkalut: tärkeä ero

Kaksi tilannetta on syytä erottaa toisistaan. Sellaisilla työkaluilla kuin BitTitan MigrationWiz tai CloudM Migrate ongelma esiintyy niin ikään, mutta näissä työkaluissa on toisinaan konfigurointivaihtoehtoja (puoliksi dokumentoituja, usein piilotettu lisäasetuksiin), jotka yrittävät säilyttää joitakin päivämäärämetatietoja.

EAC:n natiivissa siirrossa tällaisia vaihtoehtoja ei ole lainkaan. Microsoft ei tarjoa asetusta INTERNALDATE-arvojen säilyttämisen hallintaan eräajosiirron putkessa. Kyse on mustasta laatikosta: konfiguroit eräajon, käynnistät sen, ja Exchange tekee sisäisesti mitä haluaa. Ja se, mitä se järjestelmällisesti tekee, on päivätä viestit niiden syöttöhetken mukaan.

(Jos olet koskaan yrittänyt lukea EAC:n kautta siirretyn sähköpostin raakaotsikot, tiedät että Exchangen lisäämä Received:-kenttä on tunnistettavissa tuhansien joukosta: se sisältää viittauksia Microsoftin sisäisiin palvelimiin kuten *.protection.outlook.com tai *.prod.exchangelabs.com, ja aikaleima vastaa täsmälleen siirtoikkunaa.)

Miksi eräajon uudelleenkäynnistys ei auta

Monien IT-ylläpitäjien ensireaktio tähän ongelmaan on: "Jos poistan siirretyt postilaatikot ja käynnistän eräajon alusta, ehkä päivämäärät ovat tällä kertaa oikein."

Se on ymmärrettävää. Mutta se ei toimi.

Ongelma ei ole eräajon konfiguraatiossa. Se ei ole asetuksessa, jota olisi unohdettu rastittaa. Se on Exchange-siirtoputken arkkitehtuurissa, joka on identtinen jokaisessa siirrossa. Eräajon uudelleenkäynnistys tuottaa täsmälleen saman tuloksen: samat Received:-otsikot uudella siirron päivämäärällä ja samat virheelliset INTERNALDATE-arvot. Aikaa on kulunut hukkaan ja käyttäjät on häiritty turhaan toistamiseen.

Jotkut ylläpitäjät yrittävät myös muuttaa Outlookin lajitteluasetuksia ("lajittele lähetyspäivän mukaan" vastaanotetun sijaan). Lajittelu lähetyspäivän mukaan ei ole ratkaisu. Se on laastari. Date:-otsikko ja INTERNALDATE pysyvät virheellisinä sellaisille sähköpostiohjelmille, joissa tämä asetus ei ole käytettävissä, OWA:lle, Outlook Mobilelle eikä millekään kolmannen osapuolen sovellukselle, joka käyttää postilaatikkoa IMAP:n tai EWS:n kautta.

Mitä otsikoissa oikeasti tapahtuu

Tässä yksinkertaistettu esimerkki siitä, miltä sähköposti näyttää siirron jälkeen EAC:n kautta. Alkuperäinen otsikko:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@olddomain.com
Subject: Q1 2019 Report

Siirron jälkeen viestin otsikkoketjun alkuun lisätään jotain tällaista:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook näkee tämän Received:-otsikon ensimmäisenä (se lisätään otsikkolohkon alkuun), tulkitsee sen viimeisimmäksi käsittelypäivämääräksi ja näyttää sen vastaanotettuna päivämääränä. Alkuperäinen Date:-otsikko vuodelta 2019 on siellä yhä, muuttumattomana, muutama rivi alempana. Mutta Outlook ei käytä sitä viestiluettelon näyttämiseen.

Tarkennettuna: käyttäytyminen vaihtelee hieman Outlook-versioittain. Vuoden 2021 jälkeiset versiot (ja erityisesti uusi Outlook Windowsille, joka on otettu käyttöön loppuvuodesta 2023 lähtien) ovat tälle erityisen herkkiä, koska ne nojaavat enemmän Exchange Graph -metatietoihin kuin raakaan Date:-otsikkoon. Tämä tarkoittaa, että siirrot, jotka eivät aiheuttaneet näkyvää ongelmaa Outlook 2016:ssa, voivat nyt hajota uudessa Outlookissa.

Ketä tämä oikeasti koskee

Yleisimmät IMAP-lähdepalvelimet tämäntyyppisessä siirrossa ovat Dovecot (yleinen Linux/cPanel-ympäristöissä) ja Courier. Molemmat tarjoavat IMAP:n kautta INTERNALDATE-arvoja, joita EAC ei säilytä. Jos siirto tapahtuu paikallisesta Exchangesta Exchange Onlineen (hybridi- tai cutover-siirto), käyttäytyminen on erilainen, koska Microsoft käyttää sisäistä siirtoprotokollaa (MAPI/EWS), joka säilyttää metatiedot paremmin. Ongelman aiheuttaa nimenomaan yleinen IMAP-siirto EAC:n kautta.

Pahimmin kärsivät käyttäjät, joilla on pitkä postilaatikkohistoria (5+ vuotta) ja suuri viestimäärä. Käyttäjä, jolla on 300 sähköpostia, toipuu nopeasti. Myyntijohtaja, jolla on 12 000 päivämäärän mukaan lajiteltua sähköpostia ja joka nojaa niihin päivittäin löytääkseen asiakasketjuja, on käytännössä lamaantunut.

Miksi itse tehty skripti on tässä huono idea

Osa teknisen ongelman ymmärtävistä IT-ylläpitäjistä houkuttuu kirjoittamaan PowerShell- tai Python-skriptin otsikoiden korjaamiseksi käsin. Perusidea voi tuntua yksinkertaiselta, kun mekanismi on tunnistettu. Mutta korjauksen ajaminen tuotannossa on aivan eri asia.

Ensin reunatapaukset. S/MIME-allekirjoitetuilla sähköposteilla ja PGP-salatuilla viesteillä on rakenne, joka ei kestä otsikon muokkausta mitätöimättä allekirjoitusta. Multipart/alternative-viestit, joissa on virheellisiä MIME-rajoja (yleisiä vanhemmilla Courier-palvelimilla), voivat vaurioitua skriptistä, joka muokkaa viestiä rakentamatta rakennetta oikein uudelleen. RFC 2047:n mukaan koodatut ei-ASCII-otsikot (esimerkiksi lähettäjän nimet, joissa on aksentteja tai japania) ovat klassinen virhelähde.

Sitten on volyymi. Skripti, joka toimii 50 testisähköpostilla kehitysympäristössä, ei selviä Exchange Online -API:n nopeusrajoituksista tuotannossa. 429 Too Many Requests -virhe kello kahdelta yöllä 8 000 viestin erän aikana, ilman uudelleenyrityslogiikkaa, tarkoittaa valvottua yötä ja mahdollisesti kaksinkertaisia tai kadonneita viestejä.

Ja isompi kysymys: miten varmistat, että jokainen korjattu sähköposti on ehjä? Ettei liite katkennut, ettei ketju rikkoutunut, että tunnisteet ja kansiot säilyvät? Ilman yksilöllistä tarkistusta voit vain toivoa, että kaikki menee hyvin.

Sähköpostien päivämäärien korjaaminen siirron jälkeen on ongelma, joka näyttää 50 rivin skriptiltä mutta vaatii tuhansia rivejä toimiakseen luotettavasti tuotannossa.

Mitä Redate.io tekee eri tavalla

Kukin kirjautuu sisään omalla Microsoft-tilillään, ja Redate.io avaa kyseisen postilaatikon tarkistaakseen sähköpostit, joiden näytetty päivämäärä ei vastaa niiden alkuperäistä päivämäärää siirron jälkeen. Tämä tarkistus on maksuton ja antaa tarkan kuvan ongelman laajuudesta: kuinka monta viestiä on kyseessä, mitkä postilaatikot, minkä ajanjakson virheelliset päivämäärät kattavat.

Redaten kehittämä korjausmoottori käsittelee sitten jokaisen sähköpostin yksilöllisesti monivaiheisen analyysin kautta, joka sisältää RFC-yhteensopivuuden tarkistuksen ja rakenteellisen eheyden todentamisen ennen korjausta ja sen jälkeen. S/MIME-allekirjoitetut sähköpostit, monimutkaiset MIME-rakenteet, epästandardit koodaukset: kaikki käsitellään omilla, niille tarkoitetuilla käsittelypoluillaan.

Jokainen korjattu viesti tarkistetaan yksilöllisesti. Alkuperäiset säilyvät näkyvässä varmuuskopiokansiossa omassa postilaatikossasi, kunnes poistat ne itse. Jos jokin viesti näyttää epäilyttävältä, se jätetään koskematta: Redate.io merkitsee poikkeaman sen sijaan, että ottaisi riskin vahingosta.

Hinnoittelu perustuu määrään, kertamaksuna postilaatikkoa kohden. Ei tilausta, ei toistuvia maksuja. Ongelma korjataan kerran, ja se on siinä.

Nimenomaan Exchange Online -siirroissa kukin käyttäjä kirjautuu sisään omalla Microsoft-tilillään, ja jos organisaatio vaatii järjestelmänvalvojan hyväksynnän, Redate.io valmistelee linkin, jonka voi välittää kyseiselle järjestelmänvalvojalle, mikä helpottaa huomattavasti suurten postilaatikkomäärien käsittelyn organisointia IT-ylläpitäjälle tai MSP:lle.

Jos hallinnoit useita asiakkaita, jotka ovat käyneet läpi tämäntyyppisen siirron, katso myös täydellinen opas sähköpostien päivämäärien korjaamiseen Microsoft 365 -siirron jälkeen, josta löytyy yleiskatsaus eri tilanteisiin.

Sähköpostit ovat tallessa, ja niin ovat alkuperäiset päivämäärätkin. Tee maksuton tarkistus Redate.io:ssa nähdäksesi tarkalleen, kuinka monta viestiä Exchange Online -postilaatikoissasi on vaikutuksen alaisena, ennen kuin päätät jatkotoimista.