eM Client: pogrešni datumi posle PST ili Thunderbird importa

Simptom: svi emailovi imaju isti datum

Upravo ste završili PST import u eM Client, ili ste migrirali iz Thunderbirda u novi sandučić. Import je protekao bez vidljivih grešaka. Ali kada otvorite prijemno sanduče, nešto ne štima: stotine, ponekad hiljade emailova prikazuju isti datum, onaj dan kada je urađen import. Email iz 2019. izgleda kao da je primljen juče. Ugovor potpisan pre tri godine pojavljuje se kao da je tek stigao.

Prva prirodna reakcija je da se okrivljuje eM Client. Pogrešno podešavanje, pogrešna kolona sortiranja, greška prikaza... Tražite po podešavanjima. Prebacujete između "Datum prijema" i "Datum slanja". Ništa se ne menja. Ili tačnije, nešto se menja, ali to ne rešava suštinski problem.

Razlog je jednostavan: problem nije u eM Clientu. On se nalazi u metapodacima na serveru.

Pravi uzrok: IMAP INTERNALDATE prepisan tokom importa

Da biste razumeli šta se dešava, morate da siđete jedan nivo niže i pogledate kako IMAP protokol čuva emailove.

Svaka poruka na IMAP serveru ima dve vrste datuma:

• Zaglavlje Date: (definisano RFC 2822 standardom): datum koji je pošiljalac upisao u poruku u trenutku slanja. Enkapsuliran je unutar tela poruke i teorijski ga nije moguće promeniti spolja.
• INTERNALDATE: serverski metapodatak, koji je spoljan u odnosu na samu poruku, i koji predstavlja datum kada je poruka smeštena u sandučić. Ovu vrednost email klijenti primarno koriste za sortiranje i prikazivanje emailova.

Tokom PST importa ili migracije iz Thunderbirda, alatka za import (bio to ugrađeni modul eM Clienta, alat treće strane, ili ručno IMAP kopiranje) smešta poruke na odredišni IMAP server. I tu, ako alatka eksplicitno ne sačuva originalni INTERNALDATE u trenutku smeštanja, server automatski dodeljuje trenutni INTERNALDATE, tj. datum i vreme importa.

Rezultat: 8.000 arhiviranih emailova iz 2017, svi označeni kao "primljeni" u trenutku migracije.

(Inače, ako ste ikada pokušali da čitate sirova zaglavlja emaila pomoću Prikaži izvor u eM Clientu, mogli ste da primetite da je originalno zaglavlje Date: uvek tu, netaknuto. To je znak da problem dolazi od serverskog INTERNALDATE, a ne od same poruke.)

Zašto promena kolone sortiranja ne pomaže

Zabuna dolazi od razlike koju malo ko poznaje. U eM Clientu, kao i u Outlooku ili Thunderbirdu, obično postoje dve kolone datuma:

• "Datum prijema" (ili "Datum dolaska"): zasniva se na serverskom INTERNALDATE.
• "Datum" ili "Datum slanja": zasniva se na zaglavlju Date: poruke.

Mnogi admini to otkriju i pomisle da su pronašli rešenje: prebace se na "Datum slanja" i problem vizuelno nestaje u eM Clientu. Ali to nije sasvim tačno.

Da budemo precizni: čak i kada sortirate po datumu slanja u eM Clientu, problem ostaje za sve ostale klijente i sve ostale interfejse koji pristupaju istom sandučiću. Ako Vaši korisnici čitaju emailove iz OWA, iz Outlooka u kancelariji, iz Gmail aplikacije na mobilnom, ili iz bilo kojeg klijenta podešenog preko IMAP, videti će datume importa. Podešavanje sortiranja u eM Clientu važi samo za eM Client, i ne utiče na metapodatke sačuvane na strani servera.

Uz to, na Microsoft 365 i Google Workspace, nativni web interfejs sortira po INTERNALDATE. Taj se ponašanje ne može promeniti sa klijentske strane.

Sortiranje po datumu slanja nije rešenje. To je flaster koji prikriva pravi problem bez da ga ispravlja.

Poseban slučaj PST importa

Import PST fajlova zaslužuje poseban pasus. PST fajl (Personal Storage Table) je Microsoftov vlasnički format koji lokalno čuva emailove, kontakte i kalendare. Kada importujete PST u eM Client, moguća su dva scenarija:

• Lokalni import na IMAP nalog: eM Client čita PST i prenosi poruke na odredišni IMAP server. Ako datum smeštanja nije sačuvan, INTERNALDATE se prepisuje. Ovo je najčešći slučaj, i tu datumi bivaju oštećeni.
• Import u lokalni folder: poruke ostaju na mašini, van servera. INTERNALDATE u tom kontekstu ne postoji, i eM Client može da prikazuje Date: zaglavlje poruke. Manje problema sa datumima, ali i manje praktične koristi.

Za Thunderbird, situacija je slična. Ako koristite ugrađenu funkciju importa u eM Clientu (koja čita Thunderbird profile), ili ako ste kopirali mbox foldere preko IMAP, poruke se ponovo smeštaju na server bez garancije čuvanja INTERNALDATE. A server koji prima poruku bez eksplicitne instrukcije o datumu za INTERNALDATE sistematski će staviti vremensku oznaku trenutka prijema.

Koje platforme su pogođene?

Problem je isti bez obzira na odredišnu platformu, jer se radi o standardnom ponašanju IMAP protokola:

• Microsoft 365 / Exchange Online: INTERNALDATE se prepisuje pri svakom importu koji ne koristi IMAP APPEND komandu sa eksplicitnim parametrom datuma. Isto važi za migraciju sa Exchange on-premise servera.
• Google Workspace: isto ponašanje. Emailovi importovani putem eM Clienta ili alata trećih strana prikazuju datum importa u Gmailu i u administratorskom interfejsu.
• Klasični IMAP hosteri (OVH, Infomaniak, Ionos, i drugi): nema posebnog tretmana datuma pri prijemu poruke u APPEND. INTERNALDATE će biti datum smeštanja.

Jedan klijent nas je kontaktirao nakon što je migrirao stotinak sandučića sa Exchange 2013 servera na Microsoft 365, koristeci eM Client kao prelazni alat za neke VIP naloge. Rezultat: sandučići migracije kroz MigrationWiz bili su ispravni, ali oni koji su prošli kroz eM Client imali su sve datume importa. Nije potrebno reći da korisnici nisu bili oduševljeni.

Zašto domaći skript neće lako rešiti ovo

Tehnički, neko ko razume IMAP protokol mogao bi da pomisli na pisanje skripte za ispravku INTERNALDATE vrednosti. Originalno zaglavlje Date: je tu, netaknuto u svakoj poruci. Dovoljno bi bilo da ga pročitate i u skladu s tim rekonstruišete serverske metapodatke, zar ne?

U teoriji, da. U praksi, to je minsko polje.

Pre svega, rubni slučajevi se brzo gomilaju na produkcijskom sandučiću. Poruke potpisane S/MIME digitalnim potpisom posebno su osetljive na svaku manipulaciju strukturom. Isto važi za PGP šifrovane poruke. Emailovi sa velikim prilozima, nestandardnim MIME granicama, ili neuobičajenim Content-Transfer-Encoding enkodiranjem mogu se tiho oštetiti ako obrada nije precizna. Skripta koja radi na 50 testnih emailova neće pouzdano raditi na sandučiću sa 20.000 poruka i 6 godina istorije.

Zatim, upravljanje API kvotama. Na Microsoft 365, ograničenja brzine na Graph API ili EWS u 3 ujutro tokom korekcijskog batch-a od 8.000 poruka, to se može rešiti. Ali ne rešava se samo od sebe. Nenadgledana skripta koja naiđe na grešku 429 Too Many Requests na poruci broj 3.741 možda će nastaviti, a možda i ne. I nećete nužno znati koje su poruke obrađene.

I pre svega: kako verifikujete da je svaki ispravljen email netaknut nakon obrade? Domaća skripta obično nema mehanizam individualne verifikacije. Redate.io to radi automatski, za svaku poruku.

Ispravka datuma na izvoru uz Redate.io

Redate.io napada problem tamo gde se nalazi: na nivou serverskih metapodataka, a ne na nivou email klijenta.

Proces počinje besplatnom fazom skeniranja. Redate.io se povezuje na dotični sandučić (Microsoft 365 putem Azure AD, Google Workspace putem delegacije domena, ili direktno IMAP za klasične hostere) i identifikuje emailove čiji su metapodaci datuma nekonzistentni sa sadržajem poruke. Vidite rezultat pre bilo kakvog plaćanja.

Ispravka koristi vlasnički korekcioni mehanizam koji analizira kompletan lanac zaglavlja svake poruke, primenjuje prepoznavanje obrazaca na stotinama poznatih potpisa alatki za import (uključujući specifična ponašanja eM Clienta, Thunderbirda i PST importa), i rekonstruiše metapodatke datuma na ciljan način bez menjanja sadržaja poruke, njenih priloga, ili MIME strukture.

Svaki ispravljen email se individualno verifikuje. Originali se čuvaju u vidljivom backup folderu 30 dana, što domaća skripta nikada neće raditi podrazumevano.

Cenovni model je jednostavan: jednokratna uplata po sandučiću, zasnovana na volumenu emailova za ispravku. Bez pretplate, bez recurrentnih troškova. Posetite stranicu za početak za detalje.

Za sledeću migraciju: šta treba proveriti

Ako planirate migraciju i želite da izbegnete ovaj problem unapred, kontrolna tačka je jednostavna: da li alatka koju koristite eksplicitno čuva INTERNALDATE pri smeštanju poruka na odredišni server?

Za PST importove na Microsoft 365, Microsoftovi sertifikovani alati (kao što je MigrationWiz u nativnim režimima, ili Exchange Online alat za migraciju) generalno upravljaju ovim čuvanjem. Za ručne importe putem eM Clienta ili Thunderbirda, to retko biva slučaj. Proverite dokumentaciju Vaše alatke pre pokretanja importa na produkcijskim sandučićima.

Dobra kontrolna lista za email migraciju uvek uključuje post-migraciono proveravanje datuma na uzorku sandučića. Ako želite da idete dublje, kontrolna lista za email migraciju pokriva ovu tačku detaljno.

Za admins koji redovno upravljaju migracijama za klijente, članak o ispravci datuma emailova na strani MSP i onaj o funkcionisanju IMAP INTERNALDATE daju potpuniju sliku problema.

Datumi Vaših emailova su oštećeni posle eM Client importa? Pokrenite besplatno skeniranje na Redate.io da izmerite razmere problema pre nego što odlučite šta da radite.