PST importas Outlook: kodėl visos datos tampa šiandienos

Simptomas: visi jūsų el. laiškai datuoti šiandien

Ką tik baigėte PST importą Outlook programoje. Eigos juosta pasiekė 100 %, viskas atrodė gerai. Atidarote gautuosius... ir kiekvienas importuotas el. laiškas rodo šiandienos datą. 2019-ųjų žinutė, 2021-ųjų pranešimas, penkerių metų archyvas - viskas turi tą pačią datą. Importo dieną.

Tai ne rodymo klaida. Ne laiko juostos problema. Tai puikiai dokumentuotas elgesys, tiesiogiai susijęs su tuo, kaip IMAP tvarko datos metaduomenis. Bet jei jums reikia rasti senus el. laiškus pagal datą, tai tikras katastrofos receptas.

Vietinis PST ir IMAP: du visiškai skirtingi pasauliai

Prieš aiškinant, kodėl datos sugenda, reikia suprasti, kas yra PST failas datos valdymo požiūriu.

PST failas (Personal Storage Table) yra patentuotas Microsoft formatas. Jis saugo el. laiškus su visais metaduomenimis: siuntimo data, gavimo data, priedai, kategorijos, skaitymo žymės. Šie metaduomenys valdomi tiesiogiai Outlook programos, nepriklausomai nuo jokio pašto protokolo. Kai žiūrite į PST be serverio ryšio, rodomos datos paimamos tiesiogiai iš PST failo vidinių laukų. Iki šiol viskas gerai.

Problema iškyla, kai bandote perkelti tą turinį į pašto dėžutę, esančią IMAP serveryje, nesvarbu ar tai Microsoft 365, Google Workspace, ar bet kuris kitas įprastas hostingo paslaugų teikėjas. Paliekate PST pasaulį ir įžengiate į IMAP pasaulį, o ten taisyklės pasikeičia radikaliai.

IMAP APPEND ir INTERNALDATE: problemos šerdis

IMAP protokole kiekvienas serveryje saugomas laiškas turi dviejų tipų datos duomenis:

• Antraštę Date: (RFC 2822), kuri yra paties pranešimo turinio dalis. Tai siuntėjo įrašyta data laiške.
• INTERNALDATE - serverio valdomas metaduomenų laukas. Jis žymi momentą, kai pranešimas buvo įkeltas į serverį. Būtent šią reikšmę Outlook naudoja laiškams rikiuoti rodinyje "Gavimo data".

(Beje, jei esate bandę skaityti neapdorotus el. laiško antraštes, žinote, kad tai nėra pati maloniausia veikla. Bet kaip tik ten ir vyksta viskas svarbiausia.)

Kai el. laiškas įprastai atvyksta į serverį, pašto serveris automatiškai nustato INTERNALDATE tiksliu gavimo momentu. Todėl Outlook rodoma data atitinka, kada iš tikrųjų gavote laišką.

Kai Outlook importuoja PST failą į IMAP dėžutę, jis naudoja komandą IMAP APPEND, kad išsiųstų kiekvieną pranešimą serveriui. IMAP standartas leidžia nustatyti INTERNALDATE per APPEND komandą. Bet Outlook to nedaro. Pranešimai siunčiami nenurodant INTERNALDATE. Serveris, negavęs instrukcijų, taiko numatytąją taisyklę: INTERNALDATE nustatoma į dabartinį laiką, tai yra importo momentą.

Rezultatas: 8000 importuotų el. laiškų, 8000 el. laiškų su šiandienos data.

Kodėl Outlook elgiasi būtent taip

Tai nėra Microsoft aplaidumas. Tai įgyvendinimo sprendimas, kuris savo metu tikriausiai atrodė pagrįstas: pradiniame PST importo naudojimo scenarijuje vartotojas archyvuoja pranešimus vietiškai ir "importuoja" juos į savo dabartinę dėžutę. Rikiavimui aktuali data būtų originalaus gavimo data... tačiau Microsoft pasirinko nepropaguoti INTERNALDATE importo operacijos metu.

Tiksliai sakant, šis elgesys susijęs su PST importu per Outlook integruotą vedlį (Failas > Atidaryti ir eksportuoti > Importuoti/eksportuoti). Kiti importo metodai, pavyzdžiui kai kurie trečiųjų šalių įrankiai ar migracijos per Exchange administravimo centrą, gali elgtis skirtingai priklausomai nuo jų IMAP APPEND įgyvendinimo.

Šis elgesys žinomas ir dokumentuotas Microsoft forumuose daugelį metų. Jis nepasikeitė su Outlook 2016, nei su Outlook 2019, nei su dabartinėmis Microsoft 365 versijomis. Vartotojas, kuris šiandien importuoja PST, susidurs lygiai su ta pačia problema kaip ir 2015-aisiais.

Kuo tai skiriasi nuo įprastos IMAP migracijos

Čia tampa įdomu, nes PST importas duoda panašų rezultatą kaip įprasta IMAP migracija su sugadintomis datomis, bet per visiškai kitokį mechanizmą.

Tipinės IMAP migracijos metu, pavyzdžiui naudojant BitTitan MigrationWiz ar imapsync, el. laiškai perkeliami iš vieno IMAP serverio į kitą. Migracijos įrankis atgauna pranešimus ir pakartotinai juos įkelia per IMAP APPEND. Kai kurie įrankiai teisingai išsaugo INTERNALDATE, kiti ne. Bet visais atvejais pranešimai jau turi Received: antraštę su migracijos data, pridėta pakeliui, kuri gali trikdyti rodymą Outlook nepriklausomai nuo INTERNALDATE.

PST importo atveju mechanizmas paprastesnis: nėra pridedamos migracijos Received: antraštės (PST failai nekeliauja per tarpinius pašto serverius), tačiau INTERNALDATE paprasčiausiai niekada nenustatoma į teisingą reikšmę. Matomas rezultatas identiškas, o pagrindinė priežastis šiek tiek skiriasi.

Šis skirtumas tiesiogiai veikia taisymą: požiūris nėra visiškai toks pat, atsižvelgiant į tai, ar tvarkoma IMAP migracija, ar PST importas. Taip pat skaitykite kodėl INTERNALDATE sugadina datas - ten rasite išsamų abiejų atvejų paaiškinimą.

Kodėl Outlook peržiūros parinktys nieko netaiso

Įprasta reakcija atradus šią problemą, tai pradėti knaisiotis Outlook nustatymuose. Ir iš tikrųjų yra viena parinktis, kuri atrodo perspektyviai: galimybė rikiuoti el. laiškus pagal "Datą", o ne pagal "Gavimo datą".

Rikiavimas pagal siuntimo datą nėra sprendimas. Tai tik pleistras.

Kodėl: net jei pakeičiate rikiavimą, kad būtų rodoma stulpelis "Data" (atitinkantis pranešimo antraštę Date:, tai yra originalią datą), kelios problemos išlieka:

• Outlook paieška indeksuoja pagal INTERNALDATE. Paieška "el. laiškai iš 2020 m. sausio" negrąžins jūsų importuotų 2020 m. sausio laiškų, nes jų INTERNALDATE rodo importo dieną.
• Outlook sąsajos aplankai "Šiandien", "Šią savaitę", "Šį mėnesį" grindžiami INTERNALDATE, o ne antrašte Date:.
• Žiniatinklio sąsajose (Outlook Web App, Gmail) ir mobiliuosiuose klientuose rodoma data ir rikiavimo elgesys beveik visada priklauso nuo serverio INTERNALDATE.
• Automatinės taisyklės ir filtrai, taikomi gavimo datai, veiks neteisingai.

Kitais žodžiais, peržiūros keitimas išsprendžia rodymą konkrečiam vartotojui, konkrečiame kliente, konkrečioje konfigūracijoje. Tai netaiso problemos šaltinyje.

OST resinchronizavimas taip pat nepadeda

Kitas klasikinis bandymas: išvalyti OST talpyklą ir priversti visišką resinchronizavimą iš serverio. Idėja ta, kad galbūt problema kyla iš vietinės Outlook talpyklos, o ne iš serverio.

Neteisinga kryptis. OST failas yra vietinė talpykla, atspindinti IMAP serverio būseną. Jei INTERNALDATE klaidingas serveryje, po resinchronizavimo jis bus klaidingas ir OST faile. OST ištrynimas nieko nekeičia duomenyse, saugomuose Exchange Online ar Google Workspace serveryje. Serveris turi autoritetą.

Vienintelis būdas ištaisyti datas yra taisyti metaduomenis tiesiogiai serverio pusėje, pranešimas po pranešimo. Ir kaip tik čia rankiniu būdu viskas tampa sudėtinga.

Masto problema: 1 el. laiškas yra trivialus. 15000 - jau kita istorija

Techniškai, suprantant problemą, galima įsivaizduoti skriptą, kuris perranda dėžutę, nuskaito kiekvieno pranešimo antraštę Date: ir atitinkamai taiso INTERNALDATE. Suprasti problemą yra vienas dalykas. Ją ištaisyti 15000 el. laiškų neprarandant nė vieno - visai kitas.

Kelios lauko realybės:

• Microsoft Graph ir Gmail API nustato greičio apribojimus (rate limits). Paprastas skriptas išprovokuos klaidas 429 Too Many Requests, nutrauks vykdymą taisymo viduryje ir paliks jus su iš dalies pataisyta dėžute, nežinant, kurie el. laiškai buvo apdoroti, o kurie ne.
• Kai kurie PST el. laiškai gali turėti sugadintas arba trūkstamas Date: antraštes. Skriptas be šių kraštinių atvejų tvarkymo gali sugadinti tuos pranešimus arba tyliai juos praleisti.
• Pasirašyti (S/MIME) ar užšifruoti (PGP) el. laiškai turi papildomų vientisumo apribojimų. Atsainiai keičiant jų metaduomenis galima pažeisti kriptografinį parašą.
• Sudėtingų MIME ribų multipart/alternative struktūros kartais reaguoja nenuspėjamai į modifikavimo operacijas.
• Nėra grįžimo atgal mechanizmo. Jei kažkas nepavyksta apdorojimo viduryje, kaip grįžti į pradinę būseną?

Skriptas, veikiantis su 10 bandomųjų el. laiškų, neveiks gamybinėje dėžutėje su 50000 pranešimų. Praėjusiais metais vienas klientas su 40 GB PST archyvu bandė tai ištaisyti Python skriptu, rastų Stack Overflow. Rezultatas: 3000 el. laiškų dublikatų, 200 pranešimų su nepasiekiamais priedais ir dvi savaitės rankinio valymo.

Ką daro Redate.io šiuo konkrečiu atveju

Redate.io analizuoja kiekvieno pranešimo metaduomenis tikslinėje dėžutėje, identifikuoja el. laiškus su klaidingomis datomis (įskaitant tuos, kurie importuoti iš PST), ir taiko taisymą per savo patentuotą varikį. Daugiapakopio analizės konvejeris lygina kiekvieno pranešimo antraščių grandinę, ištraukia originalią datą su RFC atitikties validacija, ir atlieka tikslinį metaduomenų taisymą nekeičiant pranešimo turinio.

Kiekvienas pataisytas el. laiškas patikrinamas atskirai. Originalai saugomi matomame atsarginės kopijos aplanke 30 dienų prieš bet kokį galutinį pakeitimą. Taisymas veikia trijose pagrindinėse platformose: Microsoft 365 (per Azure AD), Google Workspace (per domeno delegavimą) ir tiesioginio IMAP įprastiems hostingo paslaugų teikėjams.

Pradinis skenavimas nemokamas. Jis leidžia pamatyti tiksliai, kiek el. laiškų yra paveikta ir kokia yra klaidingų datų pasiskirstymas, prieš priimant bet kokį sprendimą.

Taip pat skaitykite:

• Kaip pataisyti el. pašto datas po Microsoft 365 migracijos
• Outlook: IMAP migracijos data vs siuntimo data
• Ar galima pataisyti el. laiškų datas po migracijos?

Jūsų PST importas sunaikino visų el. laiškų datas? Nuskanuokite savo dėžutę nemokamai Redate.io ir išmatuokite problemos mastą prieš imdamiesi veiksmų.