eM Client: klaidingos datos po PST ar Thunderbird importo

Simptomas: visi el. laiškai rodo tą pačią datą

Ką tik baigėte PST importą į eM Client, arba perkėlėte laiškus iš Thunderbird į naują pašto dėžutę. Importas praėjo be jokių akivaizdžių klaidų. Tačiau atidarę gautų laiškų aplanką pastebite kažką keisto: šimtai, kartais tūkstančiai el. laiškų rodo tą pačią datą, importo dieną. 2019 metų laiškas atrodo gautas vakar. Prieš trejus metus pasirašyta sutartis rodoma tarsi ką tik atsiųsta.

Pirmiausia natūraliai kaltinate eM Client. Netinkamas nustatymas, netinkamas rūšiavimo stulpelis, ekrano klaida... Ieškote nuostatos. Perjungiate tarp "Gavimo datos" ir "Siuntimo datos". Nieko nesikeičia. Tiksliau, kažkas pasikeičia, bet problemos esmė lieka ta pati.

Taip yra todėl, kad problema nėra eM Client. Ji yra serverio metaduomenyse.

Tikroji priežastis: importo metu perrašytas IMAP INTERNALDATE

Norint suprasti, kas vyksta, reikia žengti žingsnį atgal ir pažvelgti į tai, kaip IMAP protokolas saugo el. laiškus.

Kiekvienas pranešimas IMAP serveryje turi dvi skirtingas datų rūšis:

• Antraštė Date: (apibrėžta RFC 2822): tai data, kurią siuntėjas įrašė pranešime išsiuntimo metu. Ji įterpta į pranešimo turinį ir teoriškai neturėtų būti pakeičiama.
• INTERNALDATE: serverio metaduomenys, esantys už pranešimo ribų, nurodantys, kada pranešimas buvo patalpintas į dėžutę. Būtent šią reikšmę pašto klientai naudoja pirmumo tvarka rūšiuodami ir rodydami el. laiškus.

Importuojant PST arba perkeliant laiškus iš Thunderbird, importo įrankis (nesvarbu, ar tai eM Client vidinis modulis, trečiosios šalies įrankis, ar rankinis IMAP kopijavimas) patalpina pranešimus į tikslinį IMAP serverį. Ir jei įrankis eksplicitiškai neišsaugo originalaus INTERNALDATE talpinimo metu, serveris automatiškai priskiria dabartinį INTERNALDATE, t. y. importo datą ir laiką.

Rezultatas: 8 000 archyvuotų laiškų nuo 2017 metų, visi pažymėti kaip "gauti" migracijos momentu.

(Beje, jei jums teko skaityti neapdorotus el. laiško antraščius per Rodyti šaltinį eM Client, galėjote pastebėti, kad originali Date: antraštė vis dar yra, nepažeista. Tai ženklas, kad problema kyla iš serverio INTERNALDATE, o ne iš paties pranešimo.)

Kodėl rūšiavimo stulpelio keitimas nepadeda

Painiava kyla dėl skirtumo, kurį mažai kas žino. eM Client, kaip ir Outlook ar Thunderbird, paprastai siūlo du datos stulpelius:

• "Gavimo data" (arba "Atvykimo data"): pagrįsta serverio INTERNALDATE.
• "Data" arba "Siuntimo data": pagrįsta pranešimo Date: antraštėje.

Daugelis administratorių tai atranda ir galvoja radę sprendimą: perjungti į "Siuntimo datą", ir problema vizualiai dingsta eM Client. Bet tai nėra visiškai tiesa.

Patikslinsiu: net rūšiuojant pagal siuntimo datą eM Client, problema išlieka visuose kituose klientuose ir sąsajose, kurios prisijungia prie tos pačios dėžutės. Jei jūsų vartotojai tikrina el. paštą per OWA, per Outlook darbe, per Gmail programėlę telefone, ar per bet kurį kitą IMAP klientą, jie matys importo datas. eM Client rūšiavimo nustatymas taikomas tik eM Client ir niekaip neveikia serverio pusėje saugomų metaduomenų.

Be to, Microsoft 365 ir Google Workspace savoji žiniatinklio sąsaja rūšiuoja pagal INTERNALDATE. Šio elgesio negalite pakeisti iš kliento.

Rūšiavimas pagal siuntimo datą nėra sprendimas. Tai pleistras, uždengiąntis tikrą problemą jos nepašalinant.

PST importo ypatumai

PST failų importas nusipelno atskiro skyrelio. PST failas (Personal Storage Table) yra patentuotas Microsoft formatas, kuris lokaliai saugo el. laiškus, kontaktus ir kalendorius. Importuojant PST į eM Client, galimi du scenarijai:

• Lokalus importas į IMAP paskyrą: eM Client nuskaito PST ir perkelia pranešimus į tikslinį IMAP serverį. Jei talpinimo data neišsaugoma, INTERNALDATE perrašomas. Tai dažniausias atvejis, ir būtent čia datos sugenda.
• Importas į lokalų aplanką: pranešimai lieka kompiuteryje, ne serveryje. INTERNALDATE šiame kontekste neegzistuoja, o eM Client gali rodyti pranešimo Date: datą. Datų problemos čia mažiau, bet ir praktinė nauda mažesnė.

Su Thunderbird situacija panaši. Jei naudojate eM Client integruotą importo funkciją (kuri nuskaito Thunderbird profilius) arba kopijavote mbox aplankus per IMAP, pranešimai perkeliami į serverį be INTERNALDATE išsaugojimo garantijos. O serveris, gaunantis pranešimą be eksplicitinės datos instrukcijos, sistemingai priskirs gavimo momento laiko žymą.

Kokios platformos paveiktos?

Problema vienoda nepriklausomai nuo tikslinės platformos, nes tai standartinis IMAP protokolo elgesys:

• Microsoft 365 / Exchange Online: INTERNALDATE perrašomas bet kurio importo, nenaudojančio IMAP APPEND komandos su eksplicitiniu datos parametru. Tas pats galioja migruojant iš Exchange on-premise.
• Google Workspace: elgesys identiškas. El. laiškai, importuoti per eM Client ar trečiųjų šalių įrankius, Gmail ir administravimo sąsajoje rodo importo datą.
• Klasikiniai IMAP talpintojai (OVH, Infomaniak, Ionos, o2switch ir pan.): jokie specialūs datos apdorojimo veiksmai gaunant pranešimą per APPEND neatliekami. INTERNALDATE bus talpinimo data.

Vienas klientas kreipėsi į mus perkelęs apie šimtą dėžučių iš Exchange 2013 į Microsoft 365, naudodamas eM Client kaip perėjimo įrankį kai kurioms VIP paskyroms. Rezultatas: dėžutės, tinkamai perkeltos per MigrationWiz, buvo tvarkingos, tačiau tos, kurios praėjo per eM Client, visos turėjo importo datas. Nereikia nė sakyti, kad paveikti vartotojai nebuvo patenkinti.

Kodėl naminis skriptas šito lengvai neišspręs

Teoriškai kas nors, suprantantis IMAP protokolą, galėtų pagalvoti apie skriptą INTERNALDATE pataisymui. Originali Date: antraštė yra ten, nepažeista kiekviename pranešime. Tereikėtų ją perskaityti ir atitinkamai atstatyti serverio metaduomenis, tiesa?

Teorijoje, taip. Praktiškai, tai minų laukas.

Pirma, kraštutiniai atvejai gamybinėje dėžutėje greitai kaupiasi. Skaitmeniškai pasirašyti S/MIME pranešimai ypač jautrūs bet kokiai struktūros manipuliacijai. PGP užšifruoti pranešimai taip pat. El. laiškai su dideliais priedais, nestandartinėmis MIME ribomis ar neįprastais Content-Transfer-Encoding kodavimais gali tyliai sugesti, jei apdorojimas nėra griežtas. Skriptas, veikiantis su 50 bandomųjų laiškų, neveiks patikimai 20 000 pranešimų dėžutėje su 6 metų istorija.

Antra, API kvotų valdymas. Microsoft 365 greičio ribos Graph API arba EWS 3 val. nakties metu su 8 000 pranešimų taisymo paketu, tai reikia valdyti. Bet savaime tai nevyksta. Neprižiūrimas skriptas, užkliuvęs dėl 429 Too Many Requests klaidos ties 3741-uoju pranešimu, gali tęsti arba ne. Ir nežinosite tiksliai, kurie pranešimai buvo apdoroti.

Ir svarbiausia: kaip patikrinti, kad kiekvienas pataisytas el. laiškas po apdorojimo yra sveikas? Naminiame skripte paprastai nėra individualaus tikrinimo mechanizmo. Redate.io tai atlieka automatiškai, kiekvienam pranešimui.

Datų taisymas iš šaknų su Redate.io

Redate.io sprendžia problemą ten, kur ji yra: serverio metaduomenų lygmenyje, o ne pašto kliento lygmenyje.

Procesas prasideda nemokama nuskaitymo faze. Redate.io prisijungia prie paveiktos dėžutės (Microsoft 365 per Azure AD, Google Workspace per domeno delegavimą arba tiesiogiai per IMAP klasikiniams talpintojams) ir identifikuoja el. laiškus, kurių datos metaduomenys neatitinka pranešimo turinio. Rezultatą matote prieš bet kokį mokėjimą.

Taisymui naudojamas patentuotas variklis, analizuojantis kiekvieno pranešimo antraščių grandinę, taikantis šablonų atpažinimą šimtams žinomų importo įrankių parašų (įskaitant specifinius eM Client, Thunderbird, PST importo elgesius) ir tikslingai atkuriantis datos metaduomenis nepakeičiant pranešimo turinio, jo priedų ar MIME struktūros.

Kiekvienas pataisytas el. laiškas tikrinamas individualiai. Originalai saugomi matomame atsarginės kopijos aplanke 30 dienų, ko naminis skriptas pagal nutylėjimą niekada nedarys.

Kainodara paprasta: vienkartinis mokėjimas už dėžutę, pagrįstas taisytinų el. laiškų kiekiu. Jokių prenumeratų, jokių pasikartojančių mokesčių. Detalės - pradžios puslapyje.

Prieš kitą migraciją: ką reikia patikrinti

Jei planuojate migraciją ir norite iš anksto išvengti šios problemos, kontrolės taškas paprastas: ar jūsų naudojamas įrankis eksplicitiškai išsaugo INTERNALDATE, kai talpina pranešimus į tikslinį serverį?

PST importui į Microsoft 365 Microsoft sertifikuoti įrankiai (pavyzdžiui, MigrationWiz savaisiais režimais arba Exchange Online migracijos įrankis) paprastai valdo šį išsaugojimą. Rankiniams importams per eM Client ar Thunderbird tai retai būna taip. Patikrinkite savo įrankio dokumentaciją prieš paleidžiant importą gamybinėse dėžutėse.

Gera el. pašto migracijos kontrolinė sąrašas visada apima datų patikrinimą po migracijos imties dėžutėse. Jei norite išsamesnio požiūrio, migracijos kontrolinis sąrašas šį klausimą aprašo išsamiai.

Administratoriams, reguliariai tvarkančiems migracijas savo klientams, straipsnis apie el. pašto datų taisymą MSP pusėje ir tas apie IMAP INTERNALDATE veikimą suteikia išsamesnį problemos vaizdą.

El. laiškų datos sugadintos po eM Client importo? Paleiskite nemokamą nuskaitymą Redate.io, kad įvertintumėte problemos mastą prieš nusprendžiant, ką daryti.