Novi Outlook: napačni datumi po migraciji, pravi vzroki

Dva Outlooka, dve različni obnašanji pri istih e-poštnih sporočilih

Če ste nedavno selili poštne predale v Microsoft 365 in se nekateri uporabniki pritožujejo, da vsa njihova stara e-poštna sporočila prikazujejo isti datum (datum selitve), ste morda opazili nekaj čudnega: uporabniki s klasičnim Outlookom včasih vidijo pravilen datum v podoknu za branje, medtem ko tisti z novim Outlookom za Windows sistematično vidijo datum selitve. Isti poštni predal. Ista sporočila. Različni rezultati.

To ni napaka v pravem pomenu besede. Je arhitekturna odločitev, ki ima neposredne posledice za način prikaza datumov po IMAP migraciji. Da razumemo, kaj se dogaja, je treba poglobiti v podrobnosti glav e-pošte in protokola IMAP, kar ni ravno lahka bralna snov, a pojasni, zakaj nobena manipulacija na strani odjemalca ne zadostuje za rešitev težave.

IMAP INTERNALDATE: pravi krivec

Ko je e-poštno sporočilo shranjeno na strežniku IMAP, ima dve vrsti datumov, ki soobstajata in se ne mešata.

Prva je glava Date:, določena z RFC 2822. To je datum, zapisan v samem sporočilu, ki ga je pošiljatelj nastavil ob pošiljanju e-pošte. Je del telesa sporočila in se nikoli ne spremeni, ne glede na pot, ki jo e-pošta pozneje prevzame.

Druga je INTERNALDATE, metapodatek, ki ga upravlja strežnik IMAP in je zunaj sporočila. To je datum, ko je strežnik zabeležil sporočilo. Pri normalni selitveni operaciji resna orodja ohranijo izvirni INTERNALDATE. Toda pri slabo nastavljeni selitvi, ali z nekaterimi orodji, ki tega metapodatka ne upravljajo pravilno, se INTERNALDATE ponastavi na datum selitve. Rezultat: vsa preseljena sporočila nosijo isti datum prejema z vidika strežnika.

(Mimogrede, če ste kdaj brali dnevnike imapsync ali MigrationWiz, veste, da obstajajo posebne možnosti za poskus ohranitve INTERNALDATE. Te možnosti ne delujejo vedno, nekateri ciljni strežniki pa jih zavrnejo.)

Klasični Outlook: kako bere datume

Klasični Outlook, torej lokalno nameščene COM različice (Outlook 2016, 2019, 2021 in namizni odjemalec Microsoft 365 Apps), uporablja nekoliko bolj zapleten mehanizem za določanje, kateri datum prikazati v seznamu sporočil.

Za e-pošto v mapi Poslano se opira na glavo Date:. Za prejeta sporočila daje prednost INTERNALDATE strežnika, vendar v določenih kontekstih (zlasti ko je vključen predpomnilnik OST ali pri prvem prikazu v podoknu za branje) lahko prav tako prebere verigo glav Received:, da rekonstruira približni izvirni datum.

Ravno zato opazimo to nedosledno obnašanje: klasični Outlook lahko včasih prikaže pravilen datum v podoknu za branje, ker za podrobni predogled prebere izvirno glavo Date: sporočila, čeprav sam seznam e-poštnih sporočil uporablja napačni INTERNALDATE. Toda pozor, to ni zanesljivo in ne popravi ničesar. Razvrščanje ostaja pokvarjeno, iskanja po datumu ostajajo napačna.

Novi Outlook: radikalno drugačna arhitektura

Novi Outlook za Windows, ki se postopoma uveljavlja od konca leta 2023, ni več aplikacija COM. V bistvu je Progressive Web App (PWA), ki temelji na isti kodni bazi kot Outlook na spletu (OWA). Ta prenova ima globoke posledice.

Novi Outlook v celoti prepusti prikaz datumov API-ju Microsoft 365. Ne bere glav Received:, ne koplje v verigo glav, da bi poiskal izvirni datum, in ne poskuša rekonstruirati ničesar na strani odjemalca. Preprosto prikazuje tisto, kar mu vrne strežnik: INTERNALDATE.

Rezultat: če je bil INTERNALDATE med selitvijo napačno nastavljen, novi Outlook nima nobenega oklevanja. Za vsako prizadeto sporočilo prikaže datum selitve, brez izjem, brez odtenkov. To je bolj dosledno in predvidljivo obnašanje kot pri klasičnem Outlooku, toda težavo migracije naredi takoj vidno in jo je nemogoče prezreti.

Administrator, ki v petek zvečer preseli 300 poštnih predalov, bo v ponedeljek zjutraj odkril, da vsi uporabniki z novim Outlookom vidijo celotne arhive, datirane z minulim vikendom. Zahtevki za podporo prihajajo hitro.

Zakaj nobena rešitev na strani odjemalca ne deluje

Mnogi administratorji poskusijo rešitve na strani odjemalca, preden ugotovijo, da je težava v podatkih na strežniku. Tukaj so klasični poskusi in razlogi, zakaj ne uspejo.

Razvrščanje po "Datumu pošiljanja" namesto "Datuma prejema"

Razvrščanje po datumu pošiljanja v Outlooku se opira na glavo Date: sporočila, ki je nedotaknjena. Torej, to razvrščanje lahko deluje. Toda to je obliž, ne rešitev. Iskanja po datumu ostajajo pokvarjena. Pravila, ki temeljijo na datumu, ostajajo neuporabna. In zlasti: uporabnik mora ročno znova nastaviti vsako mapo in vsak poštni predal. Pri 300 poštnih predalih je to nerealno. Razvrščanje po datumu pošiljanja ni rešitev, končni uporabniki pa ne razumejo, zakaj morajo spremeniti svoje navade.

Brisanje predpomnilnika Outlooka ali ponovna ustvaritev profila

To ne dotakne INTERNALDATE na strežniku. Po ponovni ustvaritvi profila Outlook znova sinhronizira e-pošto s strežnika in pridobi natanko iste napačne metapodatke. Predpomnilnik ni težava.

Uporaba OWA namesto tega

OWA in novi Outlook si delita isto podatkovno bazo. Če je INTERNALDATE na strežniku Exchange Online napačen, OWA prikazuje natanko isti napačni datum. Menjava odjemalca ne spremeni podatkov.

Težava je na strežniku, v metapodatkih vsakega sporočila. Nobeno ukrepanje na strani odjemalca ne more popraviti podatkov, shranjenih na strežniku.

Past glav Received: zakaj vse zakomplicirajo

Ko orodje za selitev kopira e-pošto z enega strežnika na drugega prek IMAP, ciljni strežnik samodejno doda glavo Received: na vrh verige z datumom in uro vstavljanja. To je normalno obnašanje strežnikov SMTP in IMAP, ki so skladni z RFC.

Te glave se kopičijo v obratnem vrstnem redu poti, ki jo je prehodilo e-poštno sporočilo. Najnovejša je na vrhu. Nekateri e-poštni odjemalci berejo prvo glavo Received:, da ocenijo datum prejema, kar da datum selitve namesto izvirnega datuma.

Popravek: to obnašanje ni značilno za samo eno orodje. BitTitan MigrationWiz, CloudM, imapsync, GSMMO in celo ročno IMAP kopiranje med dvema odjemalcema Thunderbird dajo vsi ta rezultat. Izvirna glava Date: ostane nedotaknjena v sporočilu. Ravno to tehnično omogoča popravek. Toda INTERNALDATE je ločen metapodatek, ki ga upravlja strežnik, in ga ni mogoče popraviti z enostavno manipulacijo glav sporočila na strani odjemalca.

Za več podrobnosti o tem mehanizmu si oglejte članek o IMAP INTERNALDATE in pokvarjenih datumih, ki pojasnjuje, kako ta metapodatek upravljajo različni strežniki.

Katera orodja za selitev povzročajo to težavo v Microsoft 365

Vprašanje se pogosto pojavlja: ali vsa orodja za selitev povzročajo to težavo?

Kratek odgovor je, da je odvisno od konfiguracije in ciljne platforme. Na Exchange Online / Microsoft 365 je strežnik posebej strikten pri upravljanju INTERNALDATE. Celo orodja, ki ga poskušajo ohraniti, včasih ne uspejo, ker imata Graph API in EWS (Exchange Web Services) različna obnašanja glede na pot vstavljanja.

BitTitan MigrationWiz je eno najpogosteje uporabljenih orodij za selitev v Microsoft 365, hkrati pa eno tistih, katerih težave z datumi so najbolje dokumentirane. Namenjena stran popravek datumov BitTitan v Exchange Online pokriva specifične konfiguracije, ki jih je treba spremljati. CloudM in imapsync imata svoje posebnosti, dokumentirane pri popravku datumov CloudM v Microsoft 365 oziroma popravku datumov imapsync v Microsoft 365.

Kar je skupno vsem tem orodjem: izvirna glava Date: preživi selitev. To je osnova, na kateri je mogoč popravek.

Zakaj je domača skripta tukaj slaba ideja

Razumevanje težave včasih ustvari iluzijo, da je rešitev preprosta. Ni je, ne v produkcijskem obsegu.

Spreminjanje metapodatkov e-poštnih sporočil, shranjenih na Exchange Online, ni trivialno. Microsoftov Graph API nalaga stroge omejitve hitrosti (napaka 429 Too Many Requests med nočno obdelavo skupka se pojavi hitro). Upravljanje e-poštnih sporočil, podpisanih z S/MIME ali šifriranih s PGP, zahteva posebno pozornost, da se ne razveljavijo podpisi. Večdelne strukture z velikimi prilogami dodajajo omejitve pri omrežnih prekoračitvah časa. In zlasti: kako preveriti, sporočilo po sporočilo, da je popravek uspel brez spremembe vsebine ali prilog?

Skripta, ki dobro deluje na 50 testnih e-poštnih sporočilih, se ne bo enako obnašala na poštnem predalu s 40.000 sporočili in 8 leti zgodovine. Verjetnost, da kakšen robni primer kaj pokvari, narašča z vsakim dodatnim tisočem sporočil. Brez mehanizma za povrnitev nazaj napaka na sredini pusti poštni predal v nedoslednem stanju.

Oglejte si tudi: popravek datumov e-pošte po selitvi Microsoft 365 za celovit pregled razpoložljivih možnosti.

Kaj Redate.io konkretno naredi

Ko se uporabnik prijavi s svojim Microsoftovim računom, Redate.io odpre njegov poštni predal z dostopom, ki ga ta prijava omogoči, brez portala in brez registracije aplikacije. Nato brezplačno pregleda e-poštna sporočila z napačnimi datumi in na identificirana sporočila uporabi lastniški korekcijski mehanizem. Večstopenjski analitični cevovod izvaja ujemanje vzorcev čez stotine znanih podpisov orodij za selitev, preverjanje skladnosti RFC in analizo verige glav za rekonstrukcijo pravilnih metapodatkov datumov.

Vsako popravljeno sporočilo je preverjeno posamično. Prvotna sporočila ostanejo v vidni varnostni kopiji, dokler jih ne izbrišete sami. Cenovna politika temelji na enkratnem plačilu na poštni predal, brez naročnine.

Novi Outlook nato prikazuje pravilne datume, ker so popravljeni podatki na strežniku, ne prikrita napaka.

Imate prizadete poštne predale v novem Outlooku? Zaženite brezplačno skeniranje na Redate.io in ugotovite natanko, koliko sporočil je prizadetih, preden se odločite za nadaljnje korake.