Napačni datumi e-pošte po selitvi v Exchange Online

Klasičen scenarij ponedeljkovega jutra

Pravkar ste zaključili selitev IMAP v Exchange Online. Batch se je v centru za Exchange administracijo (EAC) zaključil brez napak, nabiralnike so sinhronizirani, uporabniki se lahko prijavijo. V petek zvečer zaprete računalnik z občutkom dobro opravljenega dela.

V ponedeljek zjutraj začnejo prihajati prijave. "Vsa moja e-sporočila so datirana s petkom." "Moja mapa prejeto je neuporabna." "Manjkajo stara e-sporočila." V resnici ne manjka nič: e-sporočila so tam, toda Outlook jih prikazuje z datumom selitve namesto z izvirnim datumom pošiljanja. Sporočilo iz leta 2019 se prikaže z datumom preteklega petka. Rezultat: celoten nabiralnik izgleda, kot da vsebuje samo nedavna sporočila.

To je ena izmed najbolj frustrirajočih težav pri selitvi IMAP v Exchange Online, ki jo Microsoft skoraj sistematično slabo dokumentira.

Zakaj selitev prek EAC pokvari datume

Ko uporabite Exchange Administration Center (EAC) za konfiguracijo IMAP selitve z lokalnega strežnika (Dovecot, Courier, Cyrus, UW-IMAP, karkoli), se Exchange Online poveže z izvornim strežnikom prek IMAP, prevzame sporočila in jih vstavi v ciljne nabiralanike prek svojega notranjega transportnega cevovoda.

Prav tu nastane težava.

Vsako e-sporočilo, ki gre skozi Exchangeov transportni cevovod, samodejno prejme glavo Received: s časovnim žigom. To je standardno vedenje SMTP in IMAP strežnikov že desetletja: vsak strežnik, ki se dotakne sporočila, mu doda svoj časovni podpis. Problem je, da Outlook (zlasti Outlook za Windows v novejših različicah) pri nejasnih metapodatkih uporabi najnovejšo glavo Received: kot referenčni datum prikaza.

Izvirna glava Date: (tista, ki kaže, kdaj je bilo e-sporočilo dejansko poslano, v smislu RFC 2822) je v sporočilu še vedno prisotna. Ni bila izbrisana. Toda "zasenčena" je s to novo glavo Received:, ki jo je Exchange dodal med vstavitvijo.

Vzporedno z tem je INTERNALDATE IMAP (metapodatek, ki ga IMAP strežniki uporabljajo za interno datiranje sporočil in ki v večini odjemalcev poganja razvrščanje) nastavljen na datum vstavljanja, ne na izvirni datum e-sporočila. Exchange Online nima nobene domače možnosti za ohranitev INTERNALDATE izvornega strežnika med paketno selitvijo prek EAC.

EAC v primerjavi z orodji tretjih strank

Ločiti moramo dve situaciji. Z orodji, kot sta BitTitan MigrationWiz ali CloudM Migrate, težava prav tako obstaja, vendar imajo ta orodja včasih možnosti konfiguracije (deloma dokumentirane, pogosto skrite v naprednih nastavitvah), ki skušajo ohraniti določene metapodatke datuma.

Domača selitev prek EAC pa ne ponuja nobene takšne možnosti. Microsoft ne izpostavlja parametra za nadzor ohranitve INTERNALDATE v cevovodu paketne selitve. To je črna skrinjica: konfigurirate batch, zaženete ga, Exchange pa interno počne, kar hoče. In to, kar počne sistematično, je datiranje sporočil z datumom njihovega vstavljanja.

(Mimogrede, če ste kdaj poskusili brati surove glave e-sporočila, seljenega prek EAC, veste, da je glava Received:, ki jo doda Exchange, prepoznavna od daleč: vsebuje sklice na Microsoftove notranje strežnike, kot so *.protection.outlook.com ali *.prod.exchangelabs.com, s časovnim žigom, ki natanko ustreza oknu selitve.)

Zakaj ponovna ustvaritev batcha ne reši ničesar

Instinktivna reakcija mnogih IT administratorjev je: "Če izbrišem preseljene nabiralanike in znova zaženem batch od začetka, bodo morda tokrat datumi pravilni."

Razumljivo. Toda to ne deluje.

Težava ni v konfiguraciji batcha. Ni v nastavitvi, ki bi jo pozabili označiti. Je v sami arhitekturi Exchangeovega transportnega cevovoda, ki je pri vsaki selitvi enak. Ponoven zagon batcha bo dal natanko enak rezultat: enake glave Received: z novim datumom selitve in enake napačne INTERNALDATE vrednosti. Izgubili boste čas, uporabnike pa boste motili drugič, brez koristi.

Nekateri administratorji poskusijo tudi spremeniti parametre razvrščanja v Outlooku ("razvrsti po datumu pošiljanja" namesto "datum prejema"). Razvrščanje po datumu pošiljanja ni rešitev. Je obliž. Glava Date: in INTERNALDATE ostaneta napačna za odjemalce, ki tega nastavka ne omogočajo, za OWA, za Outlook Mobile in za vsako aplikacijo tretje stranke, ki dostopa do nabiralnika prek IMAP ali EWS.

Kaj se dejansko dogaja v glavah sporočil

Tukaj je poenostavljen primer tega, kar vsebuje e-sporočilo po selitvi prek EAC. Izvirna glava:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@staradomena.si
Subject: Poročilo Q1 2019

Po selitvi sporočilo na vrhu verige prejme nekaj takega:

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

Outlook vidi to glavo Received: kot prvo (dodana je na vrh bloka glav), jo razlaga kot najnovejši datum obdelave sporočila in jo prikaže kot datum prejema. Izvirna glava Date: iz leta 2019 je še vedno tam, nespremenjena, nekaj vrstic nižje. Toda Outlook je ne uporabi za prikaz v seznamu sporočil.

Da bom natančen: vedenje se nekoliko razlikuje glede na različico Outlooka. Različice po letu 2021 (in zlasti novi Outlook za Windows, ki je bil uveden od konca leta 2023) so posebej občutljive na to težavo, ker se bolj zanašajo na metapodatke Exchange Graph kot na surovo glavo Date:. Kar pomeni, da so selitve, ki z Outlookom 2016 niso povzročale vidnih težav, zdaj problematične z novim Outlookom.

Koga to dejansko prizadene

Najpogostejši izvorni IMAP strežniki pri tovrstnih selitvah so Dovecot (zelo razširjen v okoljih Linux/cPanel) in Courier. Oba izpostavljata INTERNALDATE prek IMAP, ki ga EAC ne ohrani. Če selite s strežnika Exchange on-premises v Exchange Online (hibridna ali cutover selitev), je vedenje drugačno, ker Microsoft uporablja interni transportni protokol (MAPI/EWS), ki metapodatke bolje ohranja. Splošna IMAP selitev prek EAC je tista, ki povzroča težave.

Najbolj prizadeti so uporabniki z nabiralanike z dolgim zgodovinskim arhivom (5 let in več) in visokim volumnom sporočil. Uporabnik s 300 e-sporočili se bo hitro znašel. Prodajni direktor z 12.000 e-sporočili razvrščenimi po datumu, na katera se dnevno zanaša pri iskanju izmenjav s strankami, pa je popolnoma blokiran.

Zakaj domač skript tu ni dobra ideja

Nekateri IT administratorji, ki razumejo tehnično ozadje, so skušani napisati skript v PowerShellu ali Pythonu za ročno popravljanje glav. Osnovna zamisel se morda zdi preprosta, ko enkrat identificirate mehanizem. Toda resničnost produkcijskega popravka je povsem druga zadeva.

Najprej robni primeri. E-sporočila, podpisana s S/MIME, in sporočila, šifrirana s PGP, imajo strukturo, ki ne prenaša spremembe glav brez razveljavitve podpisa. Sporočila multipart/alternative z napačno oblikovanimi mejami MIME (pogosta na starih strežnikih Courier) so lahko pokvarjena s skriptom, ki sporočilo spremeni brez pravilne rekonstrukcije strukture. Glave, kodirane po RFC 2047, ki niso ASCII (imena pošiljateljev z naglašenimi znaki ali japonskimi znaki, na primer), so klasičen vir napak.

Nato volumen. Skript, ki deluje na 50 testnih e-sporočilih v razvojnem okolju, ne obvladuje omejitev hitrosti Exchange Online API-ja v produkciji. Napaka 429 Too Many Requests ob 2h zjutraj med batchem 8.000 sporočil, brez mehanizma za nadaljevanje, pomeni belo noč in potencialno podvojena ali izgubljena sporočila.

In predvsem: kako preverite, da je vsako popravljeno e-sporočilo nedotaknjeno? Da nobena priloga ni bila okrnjena, da nobena konverzacija ni prekinjena, da so oznake in mape ohranjene? Brez mehanizma individualnega preverjanja preprosto upate, da je vse v redu.

Popravljanje datumov po selitvi je problem, ki izgleda kot 50 vrstic skripta, v praksi pa zahteva tisočere vrstice, da je v produkciji zanesljiv.

Kaj Redate.io dela drugače

Redate.io se poveže z Exchange Online prek Microsoft 365 API-jev (Azure Active Directory, dovoljenja za delegacijo na ravni tenanta) in pregleda prizadete nabiralanike za identifikacijo e-sporočil, katerih metapodatki datuma so bili pokvarjeni med selitvijo. Ta korak skeniranja je brezplačen in daje natančno sliko obsega težave: število prizadetih sporočil, vpleteni nabiralniki, razpon pokvarjenih datumov.

Lastniški popravljalni mehanizem Redate.io nato obdela vsako e-sporočilo posamično prek večstopenjskega analitičnega cevovoda, ki vključuje ujemanje vzorcev na podpisih znanih orodij za selitev (vključno s transportnim cevovodom Exchange Online), validacijo skladnosti z RFC in preverjanje strukturne celovitosti sporočila pred in po popravku. E-sporočila, podpisana s S/MIME, kompleksne strukture MIME, nestandardne kodiranja: vse to obravnavajo specifične obdelovalne poti.

Vsako popravljeno sporočilo je preverjeno posamično. Izvirniki so shranjeni v vidni varnostni kopiji 30 dni. Če gre s posameznim sporočilom kaj narobe, se ne spremeni: Redate.io javi anomalijo namesto da tvega pokvarjenje.

Cena je vezana na volumen, enkratno plačilo na nabiralnik. Brez naročnine, brez tekočih stroškov. Težavo popravite enkrat, to je to.

Za selitve Exchange Online zlasti Redate.io podpira povezavo prek dovoljenj aplikacije Azure AD (brez ustvarjanja posameznih poverilnic za vsak nabiralnik), kar naredi obdelavo velikih skupin nabiralnikov bistveno preprostejšo za IT administratorja ali MSP.

Če upravljate več strank, ki so prestale tovrstno selitev, si oglejte tudi celotni vodič za popravljanje datumov po selitvi Microsoft 365 za pregled različnih pokritih scenarijev.

E-sporočila so tu, izvirni datumi prav tako. Zaženite brezplačno skeniranje na Redate.io in preverite, koliko sporočil je prizadetih v vaših nabiralnikih Exchange Online, preden se odločite, kaj storiti.