Naujasis Outlook: klaidingos datos po migracijos

Du Outlook, du skirtingi elgesiai su tais pačiais laiškais

Jei neseniai migravote pašto dėžutes į Microsoft 365 ir kai kurie vartotojai skundžiasi, kad visi seni laiškai rodo tą pačią datą (migracijos datą), galbūt pastebėjote kažką keisto: vartotojai, naudojantys klasikinį Outlook, kartais skaitomojoje srityje mato teisingą datą, o tie, kurie naudoja naująjį Outlook, sistemingai mato migracijos datą. Ta pati dėžutė. Tie patys laiškai. Skirtingi rezultatai.

Tai nėra klaida griežta prasme. Tai architektūros sprendimas, turintis tiesioginę įtaką datų rodymo būdui po IMAP migracijos. Norint suprasti, kas vyksta, reikia gilintis į el. laiškų antraščių detales ir IMAP protokolą (o tai nėra pati lengviausia skaitinė medžiaga), tačiau būtent tai paaiškina, kodėl joks kliento pusės manipuliavimas nepadės išspręsti problemos.

IMAP INTERNALDATE: tikrasis kaltininkas

Kai el. laiškas saugomas IMAP serveryje, jis turi dviejų tipų datas, kurios egzistuoja kartu ir nesusipina.

Pirmoji yra antraštė Date:, apibrėžta RFC 2822 standarte. Tai data, įrašyta pačiame pranešime - ta, kurią siuntėjas nurodė išsiųsdamas laišką. Ji yra pranešimo turinio dalis ir niekada nesikeičia, nesvarbu, kokiu keliu laiškas keliautų toliau.

Antroji yra INTERNALDATE - IMAP serverio valdoma metaduomenų reikšmė, atskira nuo pranešimo. Tai data, kada serveris užregistravo pranešimą. Įprastos migracijos metu rimti įrankiai išsaugo pradinį INTERNALDATE. Tačiau blogai sukonfigūruotos migracijos metu, arba naudojant įrankius, kurie netinkamai tvarko šiuos metaduomenis, INTERNALDATE atstatomas į migracijos dienos datą. Rezultatas: visi perkelti laiškai serverio požiūriu turi tą pačią gavimo datą.

(Beje, jei kada nors žiūrėjote imapsync ar MigrationWiz žurnalus, žinote, kad yra specialių parinkčių, skirtų INTERNALDATE išsaugojimui. Jos ne visada veikia, ir kai kurie paskirties serveriai atsisako jų paisyti.)

Klasikinis Outlook: kaip jis nuskaito datas

Klasikinis Outlook, tai yra vietoje įdiegtos COM versijos (Outlook 2016, 2019, 2021 ir Microsoft 365 Apps darbalaukio klientas), naudoja šiek tiek sudėtingesnį mechanizmą nustatydamas, kurią datą rodyti pranešimų sąraše.

Išsiųstų laiškų aplanke jis remiasi antraštele Date:. Gautiems laiškams pirmenybė teikiama serverio INTERNALDATE, tačiau tam tikruose kontekstuose (ypač kai įtrauktas OST podėlis arba pirmą kartą atidarius laiškų skaitomąją sritį) jis taip pat gali nuskaityti Received: antraščių grandinę, kad apytiksliai atkurtų pradinę datą.

Štai kodėl matome tokį nenuoseklų elgesį: klasikinis Outlook kartais gali rodyti teisingą datą skaitomojoje srityje, nes detalios peržiūros metu nuskaito pradinę pranešimo Date: antraštę, net jei pats laiškų sąrašas naudoja sugadintą INTERNALDATE. Tačiau tai nėra patikima, ir tai nieko netaiso. Rikiavimas lieka sugedęs, paieškos pagal datą lieka klaidingos.

Naujasis Outlook: kardinaliai kitokia architektūra

Naujasis Outlook, kuris nuo 2023 m. pabaigos laipsniškai diegiamas Windows sistemoje, nebėra COM programa. Iš esmės tai progresyvioji žiniatinklio programa (PWA), paremta ta pačia kodo baze kaip ir Outlook žiniatinklyje (OWA). Šis perstatymas turi gilių pasekmių.

Naujasis Outlook visiškai perduoda datų rodymą Microsoft 365 API. Jis neskaito Received: antraščių, negilina į antraščių grandinę ieškodamas pradinės datos ir neatlieka jokio atstatymo kliento pusėje. Jis tiesiog rodo tai, ką grąžina serveris: INTERNALDATE.

Rezultatas: jei INTERNALDATE sugadintas migracijos metu, naujasis Outlook nesvyruoja. Kiekvienam paveiktam laiškui jis rodo migracijos datą be išimčių, be niuansų. Tai nuoseklesnis ir nuspėjamesnis elgesys nei klasikinio Outlook, tačiau jis daro migracijos problemą akimirksniu matomą ir nebeįmanomą nepastebėti.

Administratorius, kuris perkelia 300 dėžučių penktadienio vakare, pirmadienio rytą atras, kad visi vartotojai, naudojantys naująjį Outlook, mato visą savo archyvą su praėjusio savaitgalio datomis. Paraiškos ateina greitai.

Kodėl jokie kliento pusės sprendimai neveikia

Daugelis administratorių bando kliento pusės sprendimus, kol supranta, kad problema yra serverio duomenyse. Štai klasikiniai bandymai ir kodėl jie žlunga.

Rikiuoti pagal „siuntimo datą", o ne „gavimo datą"

Rikiavimas pagal siuntimo datą Outlook programoje remiasi pranešimo antrašte Date:, kuri yra nepažeista. Taigi, šis rikiavimas gali veikti. Tačiau tai pleistras, o ne sprendimas. Paieškos pagal datą lieka sugadintos. Taisyklės, pagrįstos datomis, lieka nenaudojamos. O svarbiausia - vartotojas turi rankiniu būdu perkonfigūruoti kiekvieną aplanką, kiekvieną dėžutę. Esant 300 dėžučių, tai neįmanoma. Rikiavimas pagal siuntimo datą nėra sprendimas, o galutiniai vartotojai nesupranta, kodėl jų prašoma keisti įpročius.

Išvalyti Outlook podėlį arba iš naujo sukurti profilį

Tai neliečia INTERNALDATE serverio pusėje. Iš naujo sukūrus profilį, Outlook sinchronizuoja laiškus iš serverio ir gauna lygiai tuos pačius sugadintus metaduomenis. Podėlis nėra problema.

Naudoti OWA vietoje Outlook

OWA ir naujasis Outlook naudoja tą pačią duomenų bazę. Jei INTERNALDATE yra sugadintas Exchange Online serveryje, OWA rodo lygiai tą pačią klaidingą datą. Kliento keitimas nekeičia duomenų.

Problema yra serveryje, kiekvieno pranešimo metaduomenyse. Jokie veiksmai kliento pusėje negali ištaisyti serverio pusėje saugomų duomenų.

Received antraščių spąstai: kodėl jos viską komplikuoja

Kai migracijos įrankis kopijuoja el. laišką iš vieno serverio į kitą per IMAP, paskirties serveris automatiškai prideda Received: antraštę grandinės viršuje su įterpimo data ir laiku. Tai normalus RFC atitinkančių SMTP ir IMAP serverių elgesys.

Šios antraštės kaupiasi atvirkštine laiško kelio tvarka. Naujausias yra viršuje. Kai kurie pašto klientai nuskaito pirmąjį Received:, kad įvertintų gavimo datą, o tai suteikia migracijos datą, o ne pradinę.

Patikslinkime: šis elgesys nėra būdingas vien vienam įrankiui. BitTitan MigrationWiz, CloudM, imapsync, GSMMO ir net rankinis IMAP kopijavimas tarp dviejų Thunderbird klientų - visi duoda tą patį rezultatą. Pradinė Date: antraštė pranešime lieka nepažeista. Būtent tai techniškai daro taisymą įmanomą. Tačiau INTERNALDATE yra atskiras metaduomenų laukas, kurį valdo serveris, ir jo negalima ištaisyti vien manipuliuojant pranešimo antraštėmis kliento pusėje.

Norėdami sužinoti daugiau apie šį mechanizmą, peržiūrėkite straipsnį IMAP INTERNALDATE: kodėl datos sugenda, kuriame išsamiai aprašoma, kaip šie metaduomenys tvarkomi skirtinguose serveriuose.

Kokie migracijos įrankiai sukelia šią problemą Microsoft 365

Klausimas dažnai pasikartoja: ar visi migracijos įrankiai sukelia šią problemą?

Trumpas atsakymas: priklauso nuo konfigūracijos ir paskirties platformos. Exchange Online / Microsoft 365 serveris yra ypač griežtas INTERNALDATE tvarkyme. Net įrankiai, bandantys jį išsaugoti, kartais žlunga, nes Graph API ir EWS (Exchange Web Services) turi skirtingą elgesį priklausomai nuo naudojamo įterpimo kelio.

BitTitan MigrationWiz yra vienas iš labiausiai paplitusių įrankių migracijoms į Microsoft 365, ir kartu vienas iš tų, kurių datų problemos yra geriausiai dokumentuotos. Specialus puslapis BitTitan migracijos datų taisymas Microsoft 365 aprašo konkrečias konfigūracijas, į kurias reikia atkreipti dėmesį. CloudM ir imapsync turi savų ypatumų, atitinkamai dokumentuotų CloudM migracijos datų taisymo Microsoft 365 ir imapsync migracijos datų taisymo Microsoft 365 puslapiuose.

Kas bendra visiems šiems įrankiams: pradinė Date: antraštė išgyvena migraciją. Tai pagrindas, kuriuo remiantis taisymas yra įmanomas.

Kodėl namų darbo skriptas čia yra bloga idėja

Problemos supratimas kartais sukuria iliuziją, kad sprendimas yra paprastas. Jis nėra, ne gamybinės aplinkos mastu.

El. laiškų metaduomenų keitimas Exchange Online aplinkoje nėra trivialus. Microsoft Graph API taiko griežtus užklausų greičio apribojimus (klaida 429 Too Many Requests naktinio paketo metu ateina greitai). S/MIME pasirašytų arba PGP užšifruotų laiškų tvarkymas reikalauja ypatingo atidumo, kad nebūtų negaliojamos parašai. Daugiadalių struktūrų su dideliais priedais apriboja tinklo skirtojo laiko reikalavimus. Ir svarbiausia: kaip patikrinti, laiškas po laiško, kad taisymas veikė teisingai nepakeičiant turinio ar priedų?

Skriptas, gerai veikiantis su 50 bandomųjų laiškų, 40 000 pranešimų dėžutėje su 8 metų istorija elgsis kitaip. Tikimybė, kad koks nors kraštutinis atvejis ką nors sulaužys, auga su kiekvienu papildomu tūkstančiu pranešimų. O be atkūrimo mechanizmo, klaida pusiaukelėje palieka dėžutę nenuoseklioje būsenoje.

Taip pat žiūrėkite: kaip pataisyti el. pašto datas po Microsoft 365 migracijos - išsamus turimų parinkčių apžvalga.

Ką konkrečiai daro Redate.io

Redate.io leidžia kiekvienam vartotojui prisijungti savo „Microsoft" paskyra, o taip atveriama tik ta pašto dėžutė, kurią ta paskyra leidžia pasiekti, nemokamai nuskaito laiškus su neteisingomis datomis, o tada taiko Redate sukurtą taisymo variklį identifikuotiems pranešimams. Daugiaetapis analizės konvejeris atlieka atitikimą su šimtais žinomų migracijos įrankių parašų, RFC atitikties tikrinimą ir antraščių grandinės analizę teisingoms datos metaduomenų reikšmėms atkurti.

Kiekvienas pataisytas laiškas tikrinamas atskirai. Pradiniai pranešimai saugomi matomame atsarginių kopijų aplanke, kol juos patys pašalinsite. Kainodara grįsta vienkartine mokėjimo pašto dėžutei modeliu, be prenumeratos.

Naujasis Outlook tada rodo teisingas datas, nes serverio duomenys yra pataisyti, o ne paslėpti.

Turite paveiktų dėžučių naudojančių naująjį Outlook ? Paleiskite nemokamą nuskaitymą Redate.io, kad tiksliai nustatytumėte, kiek laiškų paveikta, prieš nusprendžiant, kaip elgtis toliau.