Prelaz POP na IMAP: stari emailovi datiraju danas

Klasičan scenario ponedeljkom ujutro

Upravo ste prebacili email nalog sa POP3 na IMAP. Konfiguracija je bila jednostavna, hosting provajder Vas je proveo kroz sve korake, sve je prošlo bez problema. Dok niste ponovo otvorili prijemno sanduče. Vaši emailovi iz 2019, 2021, arhive od prošle godine... svi prikazuju isti datum: danas. Ponekad čak i isti sat, uz razliku od svega nekoliko sekundi.

Ovo nije greška Vašeg email klijenta. Nije problem sa vremenskom zonom. To je očekivano ponašanje IMAP protokola, i tiče se svakoga ko prenosi lokalno sačuvane emailove na server ovom metodom.

POP3 vs IMAP: fundamentalna razlika u čuvanju podataka

Da bismo razumeli zašto se problem javlja, potrebno je prvo razumeti kako POP3 funkcioniše i zašto se radikalno razlikuje od IMAP-a.

Kod POP3, server služi samo kao privremeno poštansko sanduče. Vaš klijent (Outlook, Thunderbird, Apple Mail) se poveže, preuzme poruke, a zatim ih briše sa servera (ili ih ostavlja, zavisno od podešavanja). Emailovi nakon toga žive isključivo lokalno: u .pst fajlu kod Outlooka, u lokalnom Thunderbird profilu, u bazi podataka na Vašem hard disku.

Kod IMAP-a, situacija je obrnuta: emailovi žive na serveru. Klijent samo prikazuje ono što je sačuvano na daljinu. Otuda i transparentna sinhronizacija između svih Vaših uređaja.

Problem nastaje pri prelasku između ta dva sistema. Konkretno, kad Vaše stare lokalne POP emailove prenosite na IMAP server.

IMAP APPEND: komanda koja menja sve

Kada Vaš email klijent prenosi lokalnu poruku na IMAP server, koristi komandu IMAP APPEND. Ta komanda serveru kaže: "sačuvaj ovu poruku u određenom folderu".

Server prima poruku, snima je i dodeljuje joj vremenski žig. Taj žig je INTERNALDATE. To je centralni metapodatak u IMAP-u: označava kada je poruka položena na server. I podrazumevano, ako klijent ne navede eksplicitno datum u APPEND komandi, server koristi... trenutni momenat.

Drugim rečima: nije važno što poruka u zaglavljima ima datum iz 2018. Ako niko ne kaže serveru "ovaj email je iz 2018", server zaključuje da je upravo sada dostavljen i dodeljuje mu INTERNALDATE od danas.

(Inače, ako ste ikad pogledali sirova zaglavlja nekog emaila, videli ste liniju Date: usred desetak linija Received:. Baš to polje Date:, definisano RFC 2822 standardom, sadrži pravi datum slanja. Ali IMAP INTERNALDATE je poseban metapodatak, čuvan na strani servera, koji nema veze sa sadržajem same poruke.)

Zašto je ovo drugačije od IMAP-na-IMAP migracije

Kod klasične migracije sa jednog IMAP servera na drugi (putem BitTitana, CloudM-a, imapsynca, itd.), problem je nešto drugačiji. Alat za migraciju kopira poruke sa jednog servera na drugi i pri tome može (u teoriji) da prenese originalni INTERNALDATE na odredišni server putem APPEND komande. Tamo je problem to što određeni alati dodaju Received: zaglavlje sa datumom migracije, što kvari prikaz u klijentima poput Outlooka.

U Vašem slučaju, polazite od čisto lokalnih podataka. Nema izvornog INTERNALDATE koji biste kopirali. Fajl .pst ili Thunderbird profil čuvaju poruke u sopstvenom vlasničkom formatu, sa sopstvenim internim metapodacima. Kada email klijent iščitava te poruke kako bi ih preneo na IMAP server, rekonstruiše APPEND komandu na osnovu sadržaja poruke. A u većini slučajeva, ne prenosi eksplicitni datum.

Rezultat: IMAP server prima stotine ili hiljade poruka u roku od nekoliko minuta i svima dodeljuje isti vremenski raspon: sada.

Upravo zato se problem trenutno propagira na svim Vašim uređajima. Vaš telefon, tablet, drugi računar, svi se povezuju na isti IMAP server i vide tačno isto. Ispravka na strani klijenta nije moguća.

Koji klijent prikazuje šta i zašto

Svi email klijenti ne reaguju na isti način. To je nešto što mnogi IT administratori otkriju tek naknadno.

Outlook (u novijim verzijama, posebno od ažuriranja 2023-2024) koristi INTERNALDATE sa servera za kolonu "Primljeno". Prikazuje dakle datum prenosa, ne originalni datum slanja. Za više detalja o ovom ponašanju specifičnom za Outlook, pogledajte: Outlook: datum prijema IMAP vs datum slanja.

Gmail / Google Workspace i Thunderbird imaju nešto nijansiranije ponašanje. Gmail, recimo, ponekad može da koristi polje Date: iz zaglavlja poruke za prikaz, što ostavlja utisak da je sve u redu... sve dok ne pokušate da sortirate po datumu i shvatite da je redosled potpuno nasumičan.

Apple Mail generalno prikazuje datum izvučen iz zaglavlja Date:, ali sortiranje i pretraga u pozadini koriste INTERNALDATE. Zbog toga Vaši emailovi mogu vizuelno "izgledati" ispravno datovani, ali funkcionalnost sortiranja više ne radi kako treba. Za detalje o ponašanju Apple Mail-a, pogledajte Apple Mail: pogrešan datum posle migracije.

Dobra vest: originalni datum je netaknut

Zaglavlje Date: svakog emaila, ono koje sadrži pravi datum slanja (ili prijema), nije dirnuto. I dalje je tu, u telu poruke. To je ono što vidite kada otvorite email i pogledate detalje.

Ono što je IMAP server "pokvario" jedino je INTERNALDATE, taj spoljašnji metapodatak koji nije deo poruke. Sama poruka je netaknuta.

Upravo to čini ispravku mogućom. I upravo to objašnjava zašto problem može neko vreme da ostane neprimećen: emailovi izgledaju ispravno kada ih otvarate jedan po jedan. Problem postaje vidljiv tek kad pogledate listu prijemnog sandučeta sortiranu po datumu. Emailovi iz 2019. pojavljuju se na vrhu kao da su upravo stigli. Svi sa istim datumom.

Problem obima: 3.000 emailova nije isto što i 3

Možda pomišljate: "Samo ću ih obrisati i ponovo uvesti, ovog puta ispravno." Na 5 ili 10 test emailova, da, to funkcioniše. Na sandučetu sa 8.000 poruka, ugnežđenim folderima, velikim prilozima, S/MIME potpisanim emailovima i nitima konverzacija koje sežu do 2015... to je sasvim drugačija priča.

Kućni skript koji funkcioniše na test skupu od 50 emailova lako može da pravi duplikate, gubi priloge ili kvari niti konverzacija na produkcijskom sandučetu. Upravljanje API kvotama, mrežnim tajmautima, porukama sa atipičnom MIME strukturom... sve su to granični slučajevi koje nespecijalizovani alat ne može da obradi.

A šta ako nešto krene naopako na pola puta? Bez mehanizma za backup i povratak na prethodno stanje, gubite podatke bez mogućnosti oporavka.

Problem je dobro poznat administratorima koji upravljaju migracijama velikog obima. Razumeti zašto su datumi pokvareni jedno je. Ispraviti čisto 15.000 emailova uz očuvanje svake strukture poruke sasvim je drugo. Za dublju analizu, članak Da li se datumi emailova mogu ispraviti posle migracije? detaljno opisuje različite pristupe i njihova ograničenja.

Kako Redate.io obrađuje ovaj specifičan slučaj

Redate.io je dizajniran tačno za ovakve situacije. Motor za analizu identifikuje emailove čiji INTERNALDATE ne odgovara datumu u zaglavljima poruke, bilo da je reč o POP-na-IMAP prelasku, migraciji između IMAP servera ili ručnom prenosu lokalnih arhiva.

Višestepeni analitički cevovod inspektuje lanac zaglavlja svake poruke, proverava usklađenost sa RFC standardom i rekonstruiše metapodatke datuma bez menjanja sadržaja poruke: ni tekst, ni prilozi, ni MIME struktura, ni eventualni digitalni potpisi nisu dirnuti. Svaki ispravljen email se proverava pojedinačno pre validacije.

Originali se čuvaju u vidljivom backup folderu 30 dana. Ako nešto ne odgovara, možete da vratite prethodno stanje.

Inicijalni sken je besplatan: Redate.io analizira Vaše sanduče, identifikuje pogođene emailove i prikazuje tačan broj pre nego što donesete bilo kakvu odluku. Nikakvih obaveza na slepo.

Redate.io se direktno povezuje na Vaša sandučeta putem Google Workspace (domensko delegiranje), Microsoft 365 (Azure AD) ili direktnog IMAP-a. Bez lokalne instalacije. Bez ručnog izvoza .pst fajlova.

Za administratore koji upravljaju više sandučića i žele uvid u iskustva sa ovakvim slučajevima, članak Kako MSP ispravlja datume emailova klijenata je dobra dopunska literatura. A za specifičnosti ispravke u Thunderbirdu, koji ima sopstveno ponašanje pri POP/IMAP prelasku, pogledajte Thunderbird: pogrešan datum posle migracije.

Ako tek treba da uradite migraciju: kako preduprediti problem

Ako još niste preneli lokalne arhive na IMAP server, ili planirate dalji prelaz POP naloga u Vašoj organizaciji, evo šta treba da imate na umu.

• Proverite da li Vaš email klijent podržava eksplicitno prosleđivanje datuma u APPEND komandi. Thunderbird, recimo, imao je promenljivo ponašanje po ovom pitanju u zavisnosti od verzije.
• Prvo napravite test na validacionom nalogu sa 50-100 reprezentativnih poruka: stari emailovi, sa prilozima, potpisani emailovi. Proverite prikazane datume u različitim klijentima.
• Planirajte ispravku pre nego što krajnji korisnici počnu da rade na migriranom sandučetu. Ispravljanje datuma na aktivnom sandučetu složenije je nego na praznom sandučetu neposredno nakon migracije.
• Dokumentujte broj emailova pre i posle migracije. To je jedini način da otkrijete tihe gubitke podataka.

Za kompletnu kontrolnu listu stavki koje treba proveriti pre i posle migracije, članak Kontrolna lista migracije emaila: sprečavanje problema sa datumima pokriva sve slučajeve.

Vaši stari emailovi prikazuju današnji datum nakon prelaza sa POP na IMAP? Pokrenite besplatan sken na Redate.io da izmerite obim problema i ispravite metapodatke datuma bez dodirivanja sadržaja Vaših poruka.