PST-import Outlookis: miks kõik kuupäevad lähevad katki

Sümptom: kõik e-kirjad on tänase kuupäevaga

Olete just lõpetanud PST-impordi Outlookis. Edenemisriba jõudis 100%-ni, kõik läks ladusalt. Avate postkasti... ja iga imporditud e-kiri kannab tänase kuupäeva. 2019. aasta sõnum, 2021. aasta kiri, viie aasta vanune arhiiv: kõik näitavad sama kuupäeva. Impordi päeva kuupäeva.

See ei ole kuvamistõrge. See ei ole ajavööndiprobleem. See on täiesti dokumenteeritud käitumine, mis tuleneb IMAP-protokolli kuupäevametaandmete haldamise loogikast. Aga see on katastroof igaühele, kes peab vanemaid e-kirju kuupäeva järgi leidma.

Kohalik PST ja IMAP: kaks täiesti erinevat maailma

Enne kui selgitada, miks kuupäevad katki lähevad, tuleb mõista, mis on PST-fail kuupäevahalduse vaatenurgast.

PST-fail (Personal Storage Table) on Microsofti omanduslik formaat. See salvestab e-kirjad koos täieliku metaandmestikuga: saatmiskuupäev, vastuvõtmiskuupäev, manused, kategooriad, lugemismärgid. Neid metaandmeid haldab Outlook otse, väljaspool igasugust e-posti protokolli. Kui avate PST-i Outlookis serveriga ühendumata, tulevad kuvatavad kuupäevad otse PST-faili sisemistest väljadest. Seni kõik korras.

Probleem ilmub siis, kui proovite sisu üle viia IMAP-serveris majutatud postkasti, olgu selleks Microsoft 365, Google Workspace või mõni tavaline hostingupakkuja. Seal lahkute PST-maailmast ja astute IMAP-maailma, kus reeglid muutuvad kardinaalselt.

IMAP APPEND ja INTERNALDATE: probleemi tuum

IMAP-protokollis on serveril talletatud igal sõnumil kahte tüüpi kuupäevaandmeid:

• Päis Date: (RFC 2822), mis on osa sõnumi enda sisust. See on kuupäev, mille saatja sõnumisse kirjutas.
• INTERNALDATE, mis on IMAP-serveri hallatud metaandmevälju. See tähistab hetke, mil sõnum serverile saadeti. Just seda väärtust kasutab Outlook sõnumite järjestamiseks vaates "Vastuvõtmise kuupäev".

(Muide, kui olete kunagi proovinud e-kirja toorandmeid lugeda, teate, et see pole päris rannalugemine. Aga just seal toimub kõik oluline.)

Kui e-kiri saabub serverile tavapäraselt, määrab meiliserver INTERNALDATE automaatselt vastuvõtmise täpsele hetkele. Tulemus: Outlookis kuvatav kuupäev vastab tegelikule vastuvõtmisajale.

Kui Outlook impordib PST-faili IMAP-postkasti, kasutab ta iga sõnumi serverile saatmiseks käsku IMAP APPEND. IMAP-standard lubab APPEND-käsus eksplitsiitset INTERNALDATE väärtust edastada. Aga Outlook seda ei tee. Ta saadab sõnumid INTERNALDATE väärtust täpsustamata. IMAP-server rakendab sel juhul oma vaikereegli: INTERNALDATE seatakse praegusele kellaajale, ehk impordi hetkele.

Tulemus: 8000 imporditud e-kirja, 8000 e-kirja tänase kuupäevaga.

Miks Outlook nii käitub

See ei ole Microsofti unustus. See on implementatsioonivalik, mis tundus omal ajal tõenäoliselt mõistlik: PST-impordi algses kasutusjuhul arhiveerib kasutaja sõnumid kohalikult ja "impordib" need oma praegusesse postkasti. Sortimiseks asjakohane kuupäev peaks olema algne vastuvõtmiskuupäev... aga Microsoft valis INTERNALDATE imporditoimingus mitte propageerida.

Täpsustuseks: see käitumine puudutab PST-importi Outlooki natiivse viisardi kaudu (Fail > Ava ja ekspordi > Impordi/Ekspordi). Teised importmeetodid, näiteks teatud kolmandate osapoolte tööriistad või Exchange'i administreerimiskeskuse kaudu tehtavad migratsioonid, võivad käituda erinevalt sõltuvalt nende IMAP APPEND implementatsioonist.

See käitumine on Microsofti foorumitel aastaid teada olnud ja dokumenteeritud. See ei muutunud Outlook 2016-ga, ei Outlook 2019-ga ega praeguste Microsoft 365 versioonidega. Kasutaja, kes täna PST-i impordib, kohtab täpselt sama probleemi nagu 2015. aastal.

Mille poolest erineb see tavalisest IMAP-migratsioonist

See on huvitav koht, sest PST-import annab sarnase tulemuse nagu tavaline IMAP-migratsioon katkiste kuupäevadega, kuid erineva mehhanismi kaudu.

Tüüpilises IMAP-migratsioonis, näiteks BitTitan MigrationWiz-i või imapsync-i abil, liiguvad e-kirjad lähte-IMAP-serverilt siht-IMAP-serverile. Migratsioonitööriist hangib sõnumid ja süstib need uuesti sisse IMAP APPEND käsuga. Mõned tööriistad säilitavad INTERNALDATE korrektselt, teised mitte. Kuid kõigil juhtudel lisatakse sõnumitele migratsiooni käigus uus päis Received: migratsiooni kuupäevaga, mis võib Outlooki kuvamist INTERNALDATE-st sõltumatult segada.

PST-impordil on mehhanism lihtsam: migratsioonipäist Received: ei lisata (PST-failid ei liigu läbi vahepealse meiliserveri), kuid INTERNALDATE ei seata lihtsalt kunagi õigele väärtusele. Nähtav tulemus on identne, aluspõhjus on pisut erinev.

Sellel erinevusel on otsene mõju parandamisele: IMAP-migratsiooniga võrreldes PST-impordi puhul ei ole lähenemine päris sama. Vaata ka miks INTERNALDATE põhjustab katkisi kuupäevi - seal on mõlemad juhud üksikasjalikult lahti seletatud.

Miks Outlooki vaateseaded probleemi ei paranda

Tavaline reaktsioon probleemi avastades on Outlooki seadetes tuhnida. Ja seal on tõepoolest parameeter, mis tundub paljulubav: võimalus sortida e-kirju "Kuupäeva" järgi, mitte "Vastuvõtmise kuupäeva" järgi.

Saatmiskuupäeva järgi sortimine ei ole lahendus. See on plaaster.

Põhjus on lihtne: isegi kui muudate sortimist, et kuvada veerg "Kuupäev" (mis vastab sõnumi päisele Date:, seega algsele kuupäevale), jäävad mitmesugused probleemid alles:

• Outlooki otsing indekseerib INTERNALDATE järgi. Otsing "e-kirjad jaanuarist 2020" ei tagasta teie imporditud jaanuari 2020 kirju, sest nende INTERNALDATE ütleb, et need pärinevad impordi päevast.
• Outlooki liidese kaustad "Täna", "See nädal", "See kuu" põhinevad INTERNALDATE väärtustel, mitte päisel Date:.
• Veebiliidestel (Outlook Web App, Gmail) ja mobiilklientidel sõltub kuvatav kuupäev ja sortimiskäitumine peaaegu alati serveri INTERNALDATE väärtusest.
• Vastuvõtmiskuupäeval põhinevad automaatsed reeglid ja filtrid ei toimi korrektselt.

Lühidalt: vaate muutmine parandab kuvamise ühe konkreetse kasutaja jaoks, ühes konkreetses kliendis, konkreetses konfiguratsioonis. See ei paranda probleemi algpõhjust.

OST-vahemälu tühjendamine ei aita ka

Teine klassikaline katse: tühjendada OST-vahemälu ja sundida täielik uuesti sünkroonimine serverist. Mõte on, et probleem võib tulla Outlooki kohalikust vahemälust, mitte serverist.

Vale jälg. OST-fail on kohalik vahemälu, mis peegeldab IMAP-serveri olekut. Kui INTERNALDATE on serveris vale, on see pärast uuesti sünkroonimist vale ka OST-is. OST-faili kustutamine ei muuda Exchange Online'i ega Google Workspace'i serverile salvestatud andmeid. Server on autoriteet.

Ainus viis kuupäevi parandada on metaandmeid otse serveripoolel parandada, sõnum sõnumi haaval. Ja just see ongi käsitsi tegemiseks keeruline.

Mastaabiproblem: 1 e-kiri on triviaalne. 15 000 on hoopis teine lugu

Tehniliselt, kui probleemist aru saada, võiks mõelda skripti kirjutamisele, mis postkasti läbib, loeb iga sõnumi päist Date: ja parandab INTERNALDATE vastavalt. Probleemist arusaamine on üks asi. Selle parandamine 15 000 e-kirjal ilma ühtegi kaotamata on hoopis teine.

Mõned praktilised reaalsused:

• Microsoft Graph API ja Gmail API jõustavad päringupiiranguid (rate limits). Naiivne skript käivitab 429 Too Many Requests vigu, katkestab töö parandamise keskel ja jätab teile osaliselt parandatud postkasti, ilma et teaksite, milliseid e-kirju töödeldi ja milliseid mitte.
• Mõnel PST-faili e-kirjal võivad olla vigased või puuduvad Date: päised. Skript, mis neid äärejuhtumeid ei käsitle, võib need sõnumid rikkuda või vaikselt vahele jätta.
• Allkirjastatud (S/MIME) või krüptitud (PGP) e-kirjadel on täiendavad terviklisusnõuded. Metaandmete muutmine ettevaatamatult võib krüptograafilise allkirja kehtetuks teha.
• Keerukate MIME-piiridega multipart/alternative struktuurid reageerivad muutmistoimingutele mõnikord ettearvamatul viisil.
• Tagasipööramise mehhanism puudub. Kui midagi läheb töötluse keskel valesti, kuidas naasta algsesse olekusse?

Skript, mis töötab 10 testsõnumiga, ei tööta 50 000 sõnumiga tootmispostkastis. Eelmisel aastal proovib klient 40 GB PST-arhiiviga Stack Overflowlt leitud Pythoni skriptiga seda parandada. Tulemus: 3000 kirja dubleeritud, 200 sõnumil ligipääsmatud manused ja kaks nädalat käsitsi koristamist.

Mida Redate.io sel konkreetsel juhul teeb

Redate.io analüüsib iga sõnumi metaandmeid sihtpostkastis, tuvastab e-kirjad, mille kuupäevad on valed (sealhulgas PST-impordist pärinevad), ja rakendab paranduse oma patenteeritud korrektsioonimootori abil. Mitmeastmeline analüüsitorustik võrdleb iga sõnumi päiseketti, ekstraheerib algse kuupäeva RFC-vastavuse valideerimisega ja teostab sihitud metaandmete korrektsiooni ilma sõnumi sisu muutmata.

Iga parandatud e-kiri kontrollitakse individuaalselt. Originaalid säilitatakse nähtavas varunduskaustas 30 päeva jooksul enne lõplikku muutmist. Parandus töötab kolmel peamisel platvormil: Microsoft 365 (Azure AD kaudu), Google Workspace (domeeninidelegatsiooni kaudu) ja otse-IMAP tavaliste hostingupakkujate jaoks.

Esialgne skannimine on tasuta. See näitab täpselt, kui palju e-kirju on mõjutatud ja milline on valede kuupäevade jaotus, enne kui midagi otsustada.

Vaata ka:

• Kuupäevade parandamine pärast Microsoft 365 migratsiooni
• Outlook: IMAP migratsiooni vastuvõetud kuupäev vs saadetud kuupäev
• Kas e-kirjade kuupäevi saab pärast migratsiooni parandada?

PST-import kirjutas kõik teie e-kirjade kuupäevad üle? Skannige oma postkasti tasuta Redate.io-s, et mõõta probleemi ulatust enne tegutsemist.