POP na IMAP: stari emailovi datiraju od danas

Klasični scenarij ponedjeljkom ujutro

Upravo ste prebacili email račun s POP3 na IMAP. Konfiguracija je bila jednostavna, hosting pružatelj Vas je proveo kroz sve korake, sve je prošlo glatko. Sve dok niste ponovo otvorili sandučić. Vaši emailovi iz 2019., 2021., arhive od prošle godine... svi prikazuju isti datum: danas. Ponekad čak i isti sat, s razlikom od nekoliko sekundi.

To nije greška Vašeg email klijenta. To nije problem s vremenskom zonom. To je očekivano ponašanje IMAP protokola, i pogađa svakoga tko lokalno pohranjene emailove prenosi na server ovom metodom.

POP3 i IMAP: temeljna razlika u pohrani

Da biste razumjeli zašto se problem pojavljuje, morate prvo razumjeti kako POP3 funkcionira, i po čemu se radikalno razlikuje od IMAP-a.

S POP3-om, server služi samo kao privremeni poštanski sandučić. Vaš klijent (Outlook, Thunderbird, Apple Mail) se spoji, preuzme poruke, a zatim ih briše sa servera (ili ostavlja, ovisno o konfiguraciji). Emailovi potom žive isključivo lokalno: u .pst datoteci za Outlook, u lokalnom profilu Thunderbirda, u bazi podataka na Vašem tvrdom disku.

S IMAP-om je obrnuto: emailovi žive na serveru. Vaš klijent samo prikazuje ono što je pohranjeno na daljinu. Odatle i besprijekorna sinkronizacija između svih Vaših uređaja.

Problem nastaje u prijelazu između ta dva protokola. Kada lokalne POP emailove prenosite na IMAP server.

IMAP APPEND: naredba koja sve mijenja

Kada Vaš email klijent prenosi lokalnu poruku na IMAP server, koristi naredbu IMAP APPEND. Ta naredba govori serveru: "pohrani ovu poruku u taj folder".

Server prima poruku, sprema je i dodjeljuje joj vremensku oznaku. Ta vremenska oznaka je INTERNALDATE. To je centralni metapodatak IMAP-a: označava kada je poruka položena na server. I prema zadanim postavkama, ako klijent ne navede eksplicitno datum u naredbi APPEND, server koristi... trenutni trenutak.

Drugim riječima: nije važno što poruka u zaglavljima sadrži datum iz 2018., ako nitko serveru ne kaže "ovaj email je iz 2018.", server zaključuje da je upravo položen i dodjeljuje mu današnji INTERNALDATE.

(Inače, ako ste ikad pogledali sirova zaglavlja emaila, vidjeli ste redak Date: usred desetak drugih redaka Received:. To polje Date:, definirano RFC 2822 standardom, sadrži pravi datum slanja. Ali IMAP INTERNALDATE je zasebni metapodatak, pohranjen na strani servera, koji nema nikakve veze sa sadržajem same poruke.)

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

Kod klasične migracije s jednog IMAP servera na drugi (BitTitan, CloudM, imapsync itd.), problem je nešto drugačiji. Alat za migraciju kopira poruke s jednog servera na drugi, i u tom slučaju može (teorijski) prenijeti originalni INTERNALDATE na odredišni server putem naredbe APPEND. Problem tamo nastaje jer neki alati dodaju zaglavlje Received: s datumom migracije, što remeti prikaz u klijentima poput Outlooka.

U Vašem slučaju, polazite od isključivo lokalnih podataka. Nema izvornog INTERNALDATE-a koji bi se mogao kopirati. Datoteka .pst ili profil Thunderbirda pohranjuje poruke u vlastitom vlasničkom formatu, s vlastitim internim metapodacima. Kada email klijent učita te poruke kako bi ih prenio na IMAP server, rekonstruira APPEND naredbu iz sadržaja poruke. I u većini slučajeva, ne prenosi eksplicitni datum.

Rezultat: IMAP server prima stotine ili tisuće poruka u minutama koje slijede, i svima dodjeljuje isti vremenski raspon: sada.

Upravo zato se problem trenutno širi na sve Vaše uređaje. Vaš mobitel, tablet, drugi računar: svi se spajaju na isti IMAP server i vide točno istu stvar. Korekcija na strani klijenta nije moguća.

Koji klijent prikazuje što, i zašto

Svi email klijenti ne reagiraju jednako. To je nešto što mnogi IT administratori otkriju tek naknadno.

Outlook (u novijim verzijama, posebno od nadogradnji 2023.-2024.) koristi INTERNALDATE sa servera za stupac "Primljeno". Prikazuje dakle datum prijenosa, a ne originalni datum slanja. Za više informacija o tom specifičnom ponašanju Outlooka, pogledajte članak Outlook: datum primitka IMAP migracije vs datum slanja.

Gmail / Google Workspace i Thunderbird imaju nešto nijansiranije ponašanje. Gmail, primjerice, ponekad može koristiti polje Date: iz zaglavlja poruke za prikaz, što stvara dojam da je sve uredu... sve dok ne pokušate sortirati po datumu i shvatite da je redoslijed potpuno nasumičan.

Apple Mail obično prikazuje datum izvučen iz zaglavlja Date:, ali sortiranje i pretraga u pozadini koriste INTERNALDATE. Tako Vaši emailovi mogu vizualno "izgledati" ispravno datirani, ali funkcionalnost sortiranja više ne radi ispravno. Za detalje o ponašanju Apple Maila, pogledajte Apple Mail: krivi datum nakon migracije.

Dobra vijest: originalni datum je netaknut

Zaglavlje Date: svakog emaila, ono koje sadrži pravi datum slanja (ili primitka), nije dirnuto. Još uvijek je tamo, u tijelu poruke. To je ono što vidite kada otvorite email i pogledate detalje.

Ono što je IMAP server "pokvarim", jedino je INTERNALDATE, taj metapodatak izvana poruke. Sama poruka je netaknuta.

To je ono što korekciju čini mogućom. I to objašnjava zašto problem može neko vrijeme proći nezapaženo: emailovi izgledaju ispravno kad ih otvarate jedan po jedan. Tek kada pogledate popis sandučića sortiran po datumu, problem postaje vidljiv. Emailovi iz 2019. pojavljuju se na vrhu kao da su upravo stigli. Svi s istim datumom.

Problem razmjera: 3.000 emailova nije isto što i 3

Možda pomišljate: "Mogu ih obrisati i ponovo uvesti, ovaj put ispravno." Na 5 ili 10 testnih emailova, da, funkcionira. Na sandučiću s 8.000 poruka, ugniježđenim mapama, velikim privicima, S/MIME potpisanim emailovima i nitima razgovora koje sežu do 2015.... to je druga priča.

Skript napisan u kući koji radi na testnom uzorku od 50 emailova može lako stvoriti duplikate, izgubiti privitke ili pokvariti niti razgovora na produkcijskom sandučiću. Upravljanje API kvotama, mrežnim vremenskim ograničenjima, porukama s atipičnom MIME strukturom... sve su to rubni slučajevi koje nespecijalizirani alat ne pokriva.

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

Problem je dobro poznat administratorima koji upravljaju migracijama velikog obujma. Razumjeti zašto su datumi pokvareni je jedna stvar. Ispravno ispraviti 15.000 emailova uz očuvanje svake strukture poruke, to je nešto sasvim drugo. Za dublji uvid u tu temu, članak Mogu li se datumi emailova ispraviti nakon migracije? detaljno opisuje različite pristupe i njihova ograničenja.

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

Redate.io je dizajniran upravo za ovakve situacije. Njegov analitički mehanizam identificira emailove čiji INTERNALDATE ne odgovara datumu sadržanom u zaglavljima poruke, bilo da se radi o POP-na-IMAP migraciji, migraciji između IMAP servera ili ručnom prijenosu lokalnih arhiva.

Višestupanjski analitički sustav inspektira lanac zaglavlja svake poruke, provjerava RFC usklađenost i rekonstruira metapodatke datuma bez mijenjanja sadržaja poruke: ni teksta, ni privitaka, ni MIME strukture, ni eventualnih digitalnih potpisa. Svaki ispravljeni email se individualno verificira prije potvrde.

Originali se čuvaju u vidljivoj sigurnosnoj mapi 30 dana. Ako Vam nešto ne odgovara, možete vratiti na prethodno stanje.

Početno skeniranje je besplatno: Redate analizira Vaš sandučić, identificira zahvaćene emailove i daje Vam točan broj prije nego što se odlučite za bilo što. Bez slijepog preuzimanja obveze.

Redate.io se spaja izravno na Vaše sandučiće putem Google Workspacea (delegacija domene), Microsoft 365 (Azure AD) ili izravno putem IMAP-a. Bez lokalne instalacije. Bez .pst datoteka koje biste morali ručno prebacivati.

Za administratore koji upravljaju višestrukim sandučićima i žele povratnu informaciju o ovakvim slučajevima, članak MSP: ispravak datuma emailova kod klijenata dobro je dopunsko štivo. A za specifičnosti korekcije u Thunderbirdu, koji ima vlastito ponašanje kod POP/IMAP prijelaza, pogledajte Thunderbird: krivi datum nakon migracije.

Ako Vas tek čeka: kako predvidjeti problem

Ako još niste prenijeli lokalne arhive na IMAP server, ili ako planirate daljnje migracije POP računa u svojoj organizaciji, evo što treba imati na umu.

• Provjerite podržava li Vaš email klijent eksplicitno slanje datuma u naredbi APPEND. Thunderbird, primjerice, imao je varijabilno ponašanje ovisno o verziji po tom pitanju.
• Prvo napravite test na validacijskom računu s 50-100 reprezentativnih poruka: stari emailovi, s privicima, potpisani emailovi. Provjerite prikazane datume u različitim klijentima.
• Planirajte korekciju prije nego što krajnji korisnici počnu raditi na migriranom sandučiću. Ispravljanje datuma na aktivnom sandučiću složenije je nego na svježem sandučiću nakon migracije.
• Dokumentirajte broj emailova prije i nakon migracije. To je jedini način za otkrivanje tihih gubitaka.

Za potpuni kontrolni popis točaka koje treba provjeriti prije i nakon migracije, članak Kontrolni popis za migraciju emailova: spriječite probleme s datumima pokriva sve slučajeve.

Stari emailovi prikazuju današnji datum nakon prijelaza s POP na IMAP? Pokrenite besplatno skeniranje na Redate.io kako biste izmjerili opseg problema i ispravili metapodatke datuma bez dodirivanja sadržaja Vaših poruka.