eM Client: valed kuupäevad pärast PST või Thunderbirdi importi

Sümptom: kõik meilid kannavad sama kuupäeva

Olete just lõpetanud PST-faili impordi eM Clienti, või migreerinud Thunderbirdist uude postkasti. Import toimus näiliselt vigadeta. Aga postkasti avades midagi ei klapi: sajad, kohati tuhanded meilid näitavad kõik sama kuupäeva, mis on impordi päev. 2019. aasta meil näib saabunud eile. Kolm aastat tagasi allkirjastatud leping paistab just hetk tagasi saabununa.

Esimene loomulik reaktsioon on süüdistada eM Clienti. Vale seadistus, vale sortimisveerud, kuvamistõrge... Otsitakse eelistustest. Vahetatakse "Vastuvõtmise kuupäev" ja "Saatmise kuupäev" vahel. Midagi ei muutu. Tegelikult muutub küll midagi, aga probleemi tuuma see ei puuduta.

Põhjus on lihtne: probleem ei asu eM Clientis. See on serveri metaandmetes.

Tegelik põhjus: IMAP INTERNALDATE kirjutati impordi käigus üle

Et mõista, mis toimub, tuleb minna taseme võrra sügavamale ja vaadata, kuidas IMAP-protokoll meile salvestab.

Igal IMAP-serveris oleval sõnumil on kaks eraldi kuupäevatüüpi:

• Päis Date: (määratud RFC 2822-ga): see on kuupäev, mille saatja kirjutas sõnumisse saatmise hetkel. See on sõnumi kehasse kapseldatud ja teoreetiliselt puutumatu.
• INTERNALDATE: serveri metaandmed, mis asuvad sõnumist väljaspool ja näitavad, millal sõnum postkasti toimetati. Just seda väärtust kasutavad meilirakendused meilide sortimisel ja kuvamisel eelisjärjekorras.

PST-impordi või Thunderbirdist migratsiooni ajal toimetab impordivahend (olgu selleks eM Clienti sisseehitatud moodul, kolmanda osapoole tööriist või käsitsi IMAP-kopeerimine) sõnumid siht-IMAP-serverisse. Kui vahend ei säilita depositi hetkel algset INTERNALDATE'i, määrab server automaatselt INTERNALDATE'iks jooksva kellaaja, ehk impordi toimumise aja.

Tulemus: 8000 alates 2017. aastast arhiveeritud meili, kõik templiga "saabunud" migratsiooni hetkel.

(Muide, kui olete kunagi proovinud lugeda meili toorandmeid eM Clienti valikuga Kuva allikas, võisite märgata, et algne päis Date: on endiselt kohal ja puutumata. See ongi märk, et probleem peitub serveri INTERNALDATE'is, mitte sõnumis eneses.)

Miks sortimisveergu vahetamine ei aita

Segadus tuleneb eristusest, mida vähesed teavad. eM Clientis, nagu ka Outlookis või Thunderbirdis, on tavaliselt kaks kuupäevaveergu:

• "Vastuvõtmise kuupäev" (ehk "Saabumise kuupäev"): põhineb serveri INTERNALDATE'il.
• "Kuupäev" või "Saatmise kuupäev": põhineb sõnumi päisel Date:.

Paljud administraatorid avastavad selle ja arvavad, et lahendus on leitud: lülita sisse "Saatmise kuupäev" ja visuaalselt on probleem eM Clientis kadunud. Aga see pole päris täpne.

Tegelikult, isegi kui sortida eM Clientis saatmise kuupäeva järgi, püsib probleem kõigis teistes klientides ja liidestes, mis pääsevad samale postkastile ligi. Kui kasutajad loevad meile OWA kaudu, kontoris Outlooki kaudu, mobiilis Gmaili rakendusega, või ükskõik millise IMAP-kliendiga, näevad nad impordi kuupäevi. eM Clienti sortimisveerud kehtivad ainult eM Clientile ja ei mõjuta serveripoolseid metaandmeid kuidagi.

Lisaks sorteerivad Microsoft 365 ja Google Workspace oma veebivaates INTERNALDATE järgi. Seda käitumist ei saa kliendipoolselt muuta.

Saatmise kuupäeva järgi sortimine ei ole lahendus. See on plaaster, mis katab tegeliku probleemi peale ilma seda kõrvaldamata.

PST-impordi erijuhtum

PST-failide import väärib eraldi käsitlust. PST-fail (Personal Storage Table) on Microsofti loodud suletud lähtekoodiga vorming, mis salvestab meilid, kontaktid ja kalendrid kohalikult. eM Clienti PST-impordi käigus on võimalikud kaks stsenaariumi:

• Kohalik import IMAP-kontole: eM Client loeb PST-faili ja saadab sõnumid siht-IMAP-serverisse. Kui depositi kuupäeva ei säilitata, kirjutatakse INTERNALDATE üle. See on kõige tavalisem juhtum, kus kuupäevad rikutakse.
• Import kohalikku kausta: sõnumid jäävad masinasse, väljaspool serverit. Selles kontekstis INTERNALDATE'i ei eksisteeri ja eM Client saab kuvada sõnumi Date: päist. Siin on kuupäevaprobleeme vähem, aga ka praktilist väärtust on vähem.

Thunderbirdi puhul on olukord sarnane. Kui kasutate eM Clienti sisseehitatud importimisfunktsiooni (mis loeb Thunderbirdi profiile), või kopeerisite mbox-kaustu IMAP-i kaudu, toimetatakse sõnumid serverisse ilma INTERNALDATE'i säilitamise garantiita. Server, mis saab sõnumi ilma INTERNALDATE'ile selge kuupäeva etteandmata, tempib selle alati vastuvõtmise hetke ajatempliga.

Milliseid platvorme see mõjutab?

Probleem on identne olenemata sihtplatvormist, sest tegemist on IMAP-protokolli standardse käitumisega:

• Microsoft 365 / Exchange Online: INTERNALDATE kirjutatakse üle iga impordi käigus, mis ei kasuta IMAP APPEND käsku eksplitsiitse kuupäevaparameetriga. Sama kehtib ka kohapealsest Exchange'ist migreerimise puhul.
• Google Workspace: sama käitumine. eM Clienti või kolmanda osapoole tööriistade kaudu imporditud meilid näitavad impordi kuupäeva nii Gmailis kui ka administreerimisliideses.
• Tavalised IMAP-majutajad (nt Infomaniak, Ionos ja sarnased): APPEND-käsuga saabuvate sõnumite kuupäeva ei töödelda eraldi. INTERNALDATE saab depositi kuupäeva.

Üks klient võttis meiega ühendust pärast seda, kui ta oli migreerinud üle saja postkasti Exchange 2013-st Microsoft 365-i, kasutades eM Clienti üleminekuvahendina mõne VIP-konto jaoks. Tulemus: MigrationWizi kaudu korralikult migreeritud postkastid olid korras, aga eM Clienti kaudu migreeritud postkastidel olid kõigil impordi kuupäevad. Asjaomased kasutajad ei olnud sellega rahul, öelgem nii.

Miks omatehtud skript seda hõlpsalt ei parandaks

Teoreetiliselt võiks keegi, kes IMAP-protokollist aru saab, mõelda skripti kirjutamisele INTERNALDATE'ide parandamiseks. Algne päis Date: on olemas, puutumata kujul igas sõnumis. Piisaks selle lugemisest ja serveri metaandmete vastavalt rekonstrueerimisest, kas pole?

Teoreetiliselt jah. Praktikas on see miiniväli.

Esiteks koguvad äärejuhud tootmispostkastis kiiresti hoogu. Digitaalselt allkirjastatud S/MIME sõnumid on struktuurimanipulatsioonide suhtes eriti tundlikud. Sama kehtib PGP-ga krüpteeritud sõnumite kohta. Mahukate manustega meilid, mittestandardsed MIME piirid või ebatavalised Content-Transfer-Encoding kodeeringud võivad vaikimisi rikutud saada, kui töötlus pole täpne. Skript, mis töötab 50 testmeiliga, ei pruugi usaldusväärselt toimida 6-aastase ajalooga 20 000 sõnumiga postkastis.

Seejärel API kvootide haldus. Microsoft 365-il on Graph API või EWS kiiruspiirangud. 8000-sõnumiline paranduspartii kell 3 öösel, millele lisanduvad 429 Too Many Requests vead sõnumil number 3741... see on hallatav, aga ei halvata ennast iseseisvalt. Ja te ei pruugi teada, milliseid sõnumeid töödeldi.

Ennekõike aga: kuidas veenduda, et iga parandatud meil on töötlemise järel vigastamata? Omatehtud skriptil pole tavaliselt individuaalset kontrollimehhanismi. Redate.io teeb seda automaatselt, iga sõnumi kohta eraldi.

Kuupäevade parandamine allikast Redate.io abil

Redate.io tegeleb probleemiga seal, kus see asub: serveri metaandmete tasandil, mitte meilirakenduse tasandil.

Protsess algab tasuta skaneerimisfaasiga. Redate.io ühendub asjaomase postkastiga (Microsoft 365 Azure AD kaudu, Google Workspace domeenidelegatsiooni kaudu, või otsese IMAP-ühendusega tavaliste majutajate puhul) ja tuvastab meilid, mille kuupäeva metaandmed ei ühti sõnumi sisuga. Tulemust näete enne, kui midagi maksate.

Parandus kasutab patenteeritud korrektsioonimootorit, mis analüüsib iga sõnumi täielikku päiseahelat, rakendab mustrite sobitamist sadade tuntud impordivahendite signatuuride vastu (sh eM Clienti, Thunderbirdi ja PST-importide spetsiifilised käitumisviisid) ning rekonstrueerib kuupäeva metaandmed sihtotstarbeliselt, muutmata sõnumi sisu, manuseid ega MIME-struktuuri.

Iga parandatud meil kontrollitakse individuaalselt. Originaalid säilitatakse nähtavas varukaustas 30 päeva jooksul, mida omatehtud skript vaikimisi kunagi ei tee.

Hinnakujundus on lihtne: ühekordne makse postkasti kohta, põhinedes parandatavate meilide mahul. Ei kordustellimust, ei püsikulusid. Vaadake üksikasju alustamise lehelt.

Järgmiseks migratsiooniks: mida kontrollida

Kui planeerite migratsiooni ja soovite seda probleemi ennetada, on kontrollpunkt lihtne: kas kasutatav vahend säilitab INTERNALDATE'i selgelt sõnumite sihtserverisse toimetamise hetkel?

PST-importide puhul Microsoft 365-i korral haldavad Microsofti sertifitseeritud tööriistad (nt MigrationWiz oma natiivsetes režiimides või Exchange Online'i migratsioonitööriist) seda säilitamist üldjuhul korralikult. Käsitsi importide puhul eM Clienti või Thunderbirdi kaudu ei ole see harva nii. Kontrollige oma tööriista dokumentatsiooni enne tootmispostkastidel impordi käivitamist.

Hea e-posti migreerimise kontrollnimekiri sisaldab alati migratsioonijärgset kuupäevade kontrolli postkastide valimil. Kui soovite selles põhjalikumaks minna, käsitleb e-posti migratsiooni kuupäevaprobleemide ennetamise kontrollnimekiri seda teemat üksikasjalikult.

Administraatoritele, kes haldavad regulaarselt klientide migratsioone, annavad artikkel e-kirjade kuupäevade parandamisest MSP vaatenurgast ja artikkel IMAP INTERNALDATE toimimisest probleemist terviklikuma pildi.

Teie meilide kuupäevad on pärast eM Clienti importi rikutud? Käivitage Redate.io-l tasuta skaneerimine, et mõõta probleemi ulatust enne otsuse tegemist.