eM Client: napačni datumi po uvozu PST ali Thunderbird

Simptom: vsi e-poštni sporočili imajo isti datum

Pravkar ste končali uvoz PST v eM Client ali ste selili pošto iz Thunderbirda v novi poštni predal. Uvoz je potekal brez napake. Toda ko odprete mapo Prejeto, je nekaj narobe: sto, včasih tisoč e-poštnih sporočil prikazuje isti datum, torej datum dneva uvoza. E-pošta iz leta 2019 navidezno prispela včeraj. Pogodba, podpisana pred tremi leti, izgleda kot da je pravkar prišla.

Prva naravna reakcija je, da krivdo pripisujete eM Clientu. Napačna nastavitev, napačen stolpec razvrščanja, napaka pri prikazu... Iščete v nastavitvah. Preklopite med "Datum prejema" in "Datum pošiljanja". Nič se ne spremeni. Oziroma, nekaj se spremeni, ampak to ne odpravi bistva težave.

Razlog je preprost: težava ni v eM Clientu. Je v metapodatkih strežnika.

Pravi vzrok: INTERNALDATE IMAP prebrisan med uvozom

Da bi razumeli, kaj se dogaja, je treba pogledati na nižji nivo in preveriti, kako protokol IMAP shranjuje e-pošto.

Vsako sporočilo na strežniku IMAP ima dve vrsti datumov:

• Glava Date: (določena s RFC 2822): to je datum, ki ga je pošiljatelj vpisal v sporočilo ob pošiljanju. Zaprt je znotraj telesa sporočila in ga načeloma ni mogoče spremeniti.
• INTERNALDATE: metapodatek strežnika, zunaj sporočila, ki predstavlja datum, kdaj je bilo sporočilo dostavljeno v poštni predal. To vrednost e-poštni odjemalci najprej uporabijo pri razvrščanju in prikazu sporočil.

Pri uvozu PST ali selitvi iz Thunderbirda orodje za uvoz (ne glede na to, ali gre za vgrajeni modul eM Clienta, orodje tretje osebe ali ročno IMAP kopiranje) odloži sporočila na ciljni IMAP strežnik. Če orodje ne ohrani prvotnega INTERNALDATE ob odlaganju, strežnik samodejno dodeli trenutni INTERNALDATE, torej datum in uro uvoza.

Rezultat: 8.000 arhivskih e-poštnih sporočil iz leta 2017, vsa označena kot "prejeta" ob vaši selitvi.

(Mimogrede, če ste kdaj poskusili prebrati surove glave sporočila z možnostjo Prikaži vir v eM Clientu, ste lahko opazili, da je originalna glava Date: še vedno tam, nedotaknjena. To je znak, da težava izhaja iz INTERNALDATE strežnika, ne iz samega sporočila.)

Zakaj menjava stolpca razvrščanja ne pomaga

Zmeda nastane iz razlike, ki jo malo kdo pozna. V eM Clientu, tako kot v Outlooku ali Thunderbirdu, sta na voljo dva stolpca z datumi:

• "Datum prejema" (ali "Datum prihoda"): temelji na INTERNALDATE strežnika.
• "Datum" ali "Datum pošiljanja": temelji na glavi Date: sporočila.

Veliko skrbnikov to odkrije in misli, da so našli rešitev: preklopijo na "Datum pošiljanja" in vizualno v eM Clientu se težava izgine. Toda to ni čisto točno.

Pravzaprav: tudi če razvrščate po datumu pošiljanja v eM Clientu, težava ostane za vse ostale odjemalce in vmesnike, ki dostopajo do istega poštnega predala. Če vaši uporabniki pregledujejo e-pošto prek OWA, prek Outlooka v pisarni, prek Gmailove mobilne aplikacije ali prek katerega koli odjemalca v IMAP konfiguraciji, vidijo datume uvoza. Nastavitev razvrščanja v eM Clientu velja samo za eM Client in ne vpliva na metapodatke, shranjene na strežniku.

Poleg tega Microsoft 365 in Google Workspace v nativnem spletnem pogledu razvrščata po INTERNALDATE. Tega obnašanja ni mogoče spremeniti iz odjemalca.

Razvrščanje po datumu pošiljanja ni rešitev. Je obliž, ki zakriva pravi problem brez da bi ga odpravil.

Posebnost uvoza PST

Uvoz datotek PST si zasluži svojo obravnavo. PST (Personal Storage Table) je Microsoftov lastniški format, ki lokalno shranjuje e-pošto, stike in kalendarje. Ko uvozite PST v eM Client, sta možna dva scenarija:

• Lokalni uvoz na IMAP račun: eM Client prebere PST in potisne sporočila na ciljni IMAP strežnik. Če datum odlaganja ni ohranjen, se INTERNALDATE prepiše. To je najpogostejši primer, kjer se datumi pokvariijo.
• Uvoz v lokalno mapo: sporočila ostanejo na stroju, izven strežnika. INTERNALDATE v tem kontekstu ne obstaja in eM Client lahko prikaže glavo Date: sporočila. Manj težav z datumi, a tudi manj praktične uporabnosti.

Pri Thunderbirdu je situacija podobna. Če uporabljate vgrajeno funkcijo uvoza eM Clienta (ki bere profile Thunderbirda) ali ste kopirali mape mbox prek IMAP, se sporočila znova odložijo na strežnik brez zagotovila ohranitve INTERNALDATE. Strežnik, ki prejme sporočilo brez jasnega navodila za datum INTERNALDATE, bo sistematično označil čas sprejema.

Katera platforma je prizadeta?

Težava je enaka ne glede na ciljno platformo, ker gre za standardno obnašanje protokola IMAP:

• Microsoft 365 / Exchange Online: INTERNALDATE se prepiše pri vsakem uvozu, ki ne uporablja ukaza IMAP APPEND z izrecnim parametrom datuma. Enako velja za selitev iz lokalnega Exchangea.
• Google Workspace: enako obnašanje. E-poštna sporočila, uvožena prek eM Clienta ali orodij tretjih oseb, v Gmailu in administrativnem vmesniku prikazujejo datum uvoza.
• Klasični IMAP gostitelji (OVH, Infomaniak, Ionos, o2switch itd.): brez posebne obravnave datuma ob prejemu sporočila v APPEND. INTERNALDATE bo datum odlaganja.

Stranka nas je kontaktirala po selitvi dobrih sto poštnih predalov iz Exchange 2013 na Microsoft 365, pri čemer so za nekatere VIP račune kot prehodno orodje uporabili eM Client. Poštni predali, preneseni pravilno prek MigrationWiza, so bili v redu, tisti, ki so šli skozi eM Client, pa so imeli vse datume uvoza. Prizadeti uporabniki tega niso cenili.

Zakaj domač skript tega ne bo zlahka rešil

Tehnično bi nekdo, ki razume protokol IMAP, lahko pomislil na pisanje skripta za popravek INTERNALDATE. Originalna glava Date: je tam, nedotaknjena v vsakem sporočilu. Preprosto bi jo prebrali in v skladu s tem rekonstruirali metapodatke strežnika, kajne?

Teoretično, da. V praksi je to minsko polje.

Najprej se robni primeri na produkcijskem poštnem predalu hitro naberejo. Digitalno podpisana S/MIME sporočila so posebej občutljiva na vsako manipulacijo s strukturo. Enako velja za PGP šifrirana sporočila. E-poštna sporočila z velikimi prilogami, nestandardnimi MIME mejami ali nenavadnimi kodiranji Content-Transfer-Encoding se lahko tiho pokvariijo, če obdelava ni skrbna. Skript, ki deluje na 50 testnih e-poštnih sporočilih, ne bo zanesljivo deloval na poštnem predalu z 20.000 sporočili in 6 leti zgodovine.

Nato je tu upravljanje API kvot. Na Microsoft 365 se omejitve hitrosti na Graph API ali EWS ob 3. uri zjutraj na popravnem paketu 8.000 sporočil dajo obvladati. Ampak ne same od sebe. Nenadzorovan skript, ki naleti na napako 429 Too Many Requests pri sporočilu številka 3741, bo morda nadaljeval, morda pa ne. In ne boste nujno vedeli, katera sporočila so bila obdelana.

In predvsem: kako preveriti, da je vsako popravljeno e-poštno sporočilo po obdelavi nedotaknjeno? Domač skript praviloma nima mehanizma za individualno preverjanje. Redate.io to stori samodejno, za vsako sporočilo posebej.

Popravek datumov pri izvoru z Redate.io

Redate.io se loti težave tam, kjer se nahaja: na ravni metapodatkov strežnika, ne na ravni e-poštnega odjemalca.

Postopek se začne z brezplačnim skeniranjem. Redate.io se poveže s prizadetim poštnim predalem (Microsoft 365 prek Azure AD, Google Workspace prek delegacije domene ali neposredno IMAP za klasične gostitelje) in identificira e-poštna sporočila, katerih datumski metapodatki so neskladni z vsebino sporočila. Rezultat vidite, preden kar koli plačate.

Za popravek Redate.io uporablja lastniški motor, ki analizira celotno verigo glav vsakega sporočila, uporablja ujemanje vzorcev na stotinah znanih podpisov uvoznih orodij (vključno s specifičnimi obnašanji eM Clienta, Thunderbirda in uvozov PST) ter ciljno rekonstruira datumske metapodatke brez poseganja v vsebino sporočila, njegove priloge ali strukturo MIME.

Vsako popravljeno e-poštno sporočilo je individualno preverjeno. Originali so shranjeni v vidni varnostni mapi 30 dni, kar domač skript privzeto nikoli ne bo naredil.

Cena je preprosta: enkratno plačilo na poštni predal, glede na obseg e-poštnih sporočil za popravek. Brez naročnine, brez tekočih stroškov. Za podrobnosti obiščite stran za začetek.

Za naslednjo selitev: kaj preveriti vnaprej

Če načrtujete selitev in se želite izogniti tej težavi, je kontrolna točka preprosta: ali orodje, ki ga uporabljate, izrecno ohrani INTERNALDATE pri odlaganju sporočil na ciljni strežnik?

Za uvoz PST na Microsoft 365 certificirana Microsoftova orodja (kot je MigrationWiz v naravnih načinih ali orodje za selitev Exchange Online) to ohranitev praviloma obvladajo. Pri ročnih uvozih prek eM Clienta ali Thunderbirda to redko drži. Preverite dokumentacijo svojega orodja, preden zaženete uvoz na produkcijskih poštnih predalih.

Dobr kontrolni seznam selitve e-pošte vedno vključuje preverjanje datumov po selitvi na vzorcu poštnih predalov. Če želite iti globlje, kontrolni seznam selitve e-pošte ta točko podrobno obravnava.

Za skrbnike, ki redno upravljajo selitve za svoje stranke, članek o popravku datumov e-pošte pri strankah MSP in tisti o delovanju IMAP INTERNALDATE dajeta celovitejši pogled na težavo.

So se datumi vaše e-pošte pokvarili po uvozu v eM Client? Zaženite brezplačno skeniranje na Redate.io in ocenite obseg težave, preden se odločite, kaj storiti.