eM Client: krivi datumi nakon uvoza PST ili Thunderbirda

Simptom: svi emailovi nose isti datum

Upravo ste završili uvoz PST datoteke u eM Client, ili ste migrirali iz Thunderbirda u novi poštanski sandučić. Uvoz je prošao bez vidljive greške. Ali kad otvorite pristiglu poštu, nešto nije u redu: stotine, ponekad tisuće emailova prikazuju isti datum, onaj dan kada je uvoz obavljen. Email iz 2019. izgleda kao da je primljen jučer. Ugovor potpisan prije tri godine pojavljuje se kao da je upravo stigao.

Prva prirodna reakcija je okriviti eM Client. Pogrešna postavka, pogrešan stupac za sortiranje, greška prikaza... Pretražujete po postavkama. Prebacujete između "Datum primitka" i "Datum slanja". Ništa se ne mijenja. Ili bolje rečeno, nešto se mijenja, ali to ne rješava suštinski problem.

A to je zato što problem nije u eM Clientu. Problem je u metapodacima na serveru.

Pravi uzrok: IMAP INTERNALDATE prepisan tijekom uvoza

Da biste razumjeli što se događa, treba zaroniti jedan nivo dublje i pogledati kako IMAP protokol pohranjuje emailove.

Svaka poruka na IMAP serveru ima dvije različite vrste datuma:

• Zaglavlje Date: (definirano RFC 2822 standardom): to je datum koji je pošiljatelj upisao u poruku u trenutku slanja. Enkapsuliran je unutar tijela poruke i u teoriji je nedodirljiv.
• INTERNALDATE: metapodatak na serveru, izvan same poruke, koji predstavlja datum kada je poruka pohranjena u sandučić. Upravo tu vrijednost email klijenti koriste kao prioritet za sortiranje i prikaz emailova.

Tijekom uvoza PST datoteke ili migracije iz Thunderbirda, alat za uvoz (bio to ugrađeni modul eM Clienta, alat treće strane ili ručno IMAP kopiranje) odlaže poruke na odredišni IMAP server. I tu, ako alat ne sačuva eksplicitno originalni INTERNALDATE u trenutku pohrane, server automatski dodjeljuje trenutni INTERNALDATE, tj. datum i vrijeme uvoza.

Rezultat: 8.000 arhiviranih emailova od 2017., svi označeni kao "primljeni" u trenutku vaše migracije.

(Inače, ako ste ikad pokušali čitati sirova zaglavlja emaila koristeći Prikaži izvor u eM Clientu, mogli ste primijetiti da je originalno zaglavlje Date: i dalje tamo, netaknuto. To je znak da problem dolazi od INTERNALDATE-a na serveru, a ne od same poruke.)

Zašto promjena stupca za sortiranje ništa ne rješava

Zbunjenost dolazi iz razlike koju malo tko poznaje. U eM Clientu, kao i u Outlooku ili Thunderbirdu, obično postoje dva stupca datuma:

• "Datum primitka" (ili "Datum dolaska"): temelji se na INTERNALDATE servera.
• "Datum" ili "Datum slanja": temelji se na zaglavlju Date: poruke.

Mnogi administratori to otkriju i misle da su pronašli rješenje: prebace se na "Datum slanja" i problem vizualno nestaje u eM Clientu. Ali to nije sasvim točno.

Zapravo, čak i ako sortirate po datumu slanja u eM Clientu, problem ostaje za sve ostale klijente i sva ostala sučelja koji pristupaju istom sandučiću. Ako Vaši korisnici čitaju emailove putem OWA-e, putem Outlooka u uredu, putem Gmail aplikacije na mobitelu, ili putem bilo kojeg klijenta konfiguriranog u IMAP načinu, vidjet će datume uvoza. Postavka sortiranja u eM Clientu primjenjuje se samo na eM Client, i ne djeluje na metapodatke pohranjene na serveru.

Osim toga, na Microsoft 365 i Google Workspace platformama, nativno web sučelje sortira po INTERNALDATE-u. Tu ponašanje ne možete promijeniti iz klijenta.

Sortiranje po datumu slanja nije rješenje. To je flaster koji skriva stvarni problem ne ispravljajući ga.

Poseban slučaj: uvoz PST datoteke

Uvoz PST datoteka zaslužuje poseban odlomak. PST datoteka (Personal Storage Table) je Microsoftov vlasnički format koji lokalno pohranjuje emailove, kontakte i kalendare. Kada uvozite PST u eM Client, moguća su dva scenarija:

• Lokalni uvoz na IMAP račun: eM Client čita PST i gura poruke na odredišni IMAP server. Ako datum pohrane nije sačuvan, INTERNALDATE se prepisuje. To je najčešći slučaj, i tu se datumi kvare.
• Uvoz u lokalni folder: poruke ostaju na računalu, izvan servera. INTERNALDATE u tom kontekstu ne postoji, i eM Client može prikazati Date: datum iz poruke. Manje problema s datumima, ali i manje praktične korisnosti.

Za Thunderbird, situacija je slična. Ako koristite ugrađenu funkciju uvoza eM Clienta (koja čita Thunderbird profile), ili ste kopirali mbox foldere putem IMAP-a, poruke se ponovo odlažu na server bez jamstva da će INTERNALDATE biti sačuvan. A server koji prima poruku bez eksplicitnih uputa o datumu za INTERNALDATE sustavno će vremenom označiti trenutak primitka.

Koje platforme su zahvaćene?

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

• Microsoft 365 / Exchange Online: INTERNALDATE se prepisuje pri svakom uvozu koji ne koristi IMAP APPEND naredbu s eksplicitnim parametrom datuma. Isto vrijedi za migraciju iz Exchange on-premise okruženja.
• Google Workspace: isto ponašanje. Emailovi uvezeni putem eM Clienta ili alata trećih strana prikazuju datum uvoza u Gmailu i u administratorskom sučelju.
• Klasični IMAP hostinzi (OVH, Infomaniak, Ionos, razni domaći hostinzi): nema posebne obrade datuma pri primitku poruke putem APPEND naredbe. INTERNALDATE će biti datum pohrane.

Jedan klijent nam se javio nakon što je migrirao dobra stotinu sandučića s Exchange 2013 na Microsoft 365, koristeći eM Client kao alat za prijelaz za određene VIP račune. Rezultat: sandučići migrirani ispravno putem MigrationWiza bili su u redu, ali sandučići koji su prošli kroz eM Client imali su sve datume uvoza. Nije potrebno ni reći da dotični korisnici nisu bili oduševljeni.

Zašto kućna skripta neće lako riješiti ovo

Tehnički gledano, netko tko razumije IMAP protokol mogao bi pomisliti na pisanje skripte za ispravljanje INTERNALDATE vrijednosti. Originalno zaglavlje Date: je tu, netaknuto u svakoj poruci. Dovoljno bi bilo pročitati ga i rekonstruirati metapodatke servera prema tome, zar ne?

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

Prije svega, rubni slučajevi se brzo nakupljaju na produkcijskom sandučiću. Poruke digitalno potpisane S/MIME standardom posebno su osjetljive na bilo kakvu manipulaciju strukturom. Isto vrijedi za PGP šifrirane poruke. Emailovi s velikim privicima, nestandardnim MIME granicama, ili neobičnim Content-Transfer-Encoding kodiranjima mogu se tiho oštetiti ako obrada nije rigorozna. Skripta koja radi na 50 testnih emailova neće pouzdano raditi na sandučiću s 20.000 poruka i 6 godina povijesti.

Zatim, upravljanje API kvotama. Na Microsoft 365, ograničenja brzine na Graph API-ju ili na EWS-u u 3 ujutro, na seriji korekcija od 8.000 poruka, to se mora upravljati. Ali to se ne upravlja samo od sebe. Nesupervizirana skripta koja naiđe na grešku 429 Too Many Requests na poruci broj 3.741 možda će nastaviti, možda neće. I nećete nužno znati koje su poruke obrađene.

I što je najvažnije: kako provjeriti da je svaki ispravljeni email netaknut nakon obrade? Kućna skripta obično nema mehanizam individualnog provjere. Redate.io to radi automatski, za svaku poruku.

Ispravljanje datuma na izvoru s Redate.io

Redate.io napada problem tamo gdje se on nalazi: na razini metapodataka servera, a ne na razini email klijenta.

Proces počinje besplatnom fazom skeniranja. Redate.io se spaja na dotični sandučić (Microsoft 365 putem Azure AD, Google Workspace putem domenskog delegiranja, ili direktni IMAP za klasične hostinze) i identificira emailove čiji metapodaci datuma nisu usklađeni sa sadržajem poruke. Vidite rezultat prije nego što platite išta.

Korekcija koristi vlasnički mehanizam koji analizira cijeli lanac zaglavlja svake poruke, primjenjuje podudaranje uzoraka na stotine poznatih potpisa alata za uvoz (uključujući specifična ponašanja eM Clienta, Thunderbirda, PST uvoza) i rekonstruira metapodatke datuma na ciljani način bez mijenjanja sadržaja poruke, njezinih privitaka ili MIME strukture.

Svaki ispravljeni email verificira se individualno. Originali se čuvaju u vidljivom backup folderu 30 dana, što kućna skripta nikad ne radi po zadanim postavkama.

Cijenovni model je jednostavan: jednokratno plaćanje po sandučiću, temeljeno na volumenu emailova za ispravak. Bez pretplate, bez ponavljajućih troškova. Posjetite stranicu za početak za detalje.

Za sljedeću migraciju: što treba provjeriti

Ako planirate migraciju i želite unaprijed izbjeći ovaj problem, kontrolna točka je jednostavna: čuva li alat koji koristite eksplicitno INTERNALDATE pri pohrani poruka na odredišni server?

Za uvoz PST datoteka na Microsoft 365, Microsoftom certificirani alati (poput MigrationWiza u nativnim načinima rada, ili alata za migraciju Exchange Online) obično upravljaju tim čuvanjem. Za ručne uvoze putem eM Clienta ili Thunderbirda, to rijetko biva slučaj. Provjerite dokumentaciju Vašeg alata prije pokretanja uvoza na produkcijskim sandučićima.

Dobra lista za provjeru migracije emailova uvijek uključuje verifikaciju datuma post-migracije na uzorku sandučića. Ako želite ići dublje, kontrolni popis za migraciju emailova pokriva tu točku detaljno.

Za administratore koji redovito upravljaju migracijama za klijente, članak o ispravljanju datuma emailova kod MSP klijenata i onaj o funkcioniranju IMAP INTERNALDATE-a daju potpuniji uvid u problem.

Datumi Vaših emailova su pokvareni nakon uvoza u eM Client? Pokrenite besplatno skeniranje na Redate.io i izmjerite opseg problema prije nego što odlučite što učiniti.