IMAP INTERNALDATE: zašto se datumi kvare

Tri datuma unutar svakog emaila

Svaki email sačuvan na IMAP serveru nosi najmanje tri različite vrednosti datuma. Razumevanje kako ti datumi funkcionišu, i kako klijenti elektronske pošte biraju koji od njih da prikažu, predstavlja klјuč za razumevanje zašto migracija kvari datume. Ovaj članak je detaljna tehnička analiza IMAP sistema datuma, namenjena IT administratorima i svima koji žele da razumeju osnovni uzrok problema s datumima nakon migracije.

1. Zaglavlje "Date" iz RFC 2822

Zaglavlje "Date" definisano je u RFC 2822 (Internet Message Format). Postavlja ga klijent elektronske pošte pošiljaoca u trenutku kada je poruka napisana i poslata. Ovo zaglavlje je deo samog tela poruke, putuje zajedno s porukom i nikada ga ne menjaju serveri elektronske pošte na putu isporuke. Tipično zaglavlje Date izgleda ovako:

Date: Mon, 15 Jan 2024 09:32:17 +0100

Zaglavlje Date predstavlja "datum slanja" poruke. To je najpouzdaniji datum jer se postavlja jednom i nikada se ne menja. Međutim, on odražava sat na računaru pošiljaoca, koji može biti loše podešen. U retkim slučajevima, zaglavlje Date može u potpunosti izostati (posebno kod automatizovanih sistemskih obaveštenja ili loše formiranih poruka).

2. IMAP INTERNALDATE

INTERNALDATE je definisan u RFC 3501 (protokol IMAP4rev1). To je vrednost metapodataka na strani servera koja predstavlja datum i vreme kada je poruka isporučena serveru. Za razliku od zaglavlja Date, INTERNALDATE nije deo same email poruke. Server ga čuva zasebno, kao metapodatak.

Kada se email isporučuje na standardan način (bez migracije), IMAP server postavlja INTERNALDATE na trenutno vreme u momentu isporuke. Ta vrednost se skoro poklapa sa zaglavljem Date, obično uz razliku od nekoliko sekundi ili minuta. Klijenti elektronske pošte često koriste INTERNALDATE kao "datum prijema", jer on odražava trenutak kada je server stvarno primio poruku.

Ovde postaje zanimljivo. Kada se poruka umeće putem IMAP komande APPEND (koju koriste alati za migraciju), ta komanda dozvoljava klijentu da eksplicitno navede vrednost INTERNALDATE. Dobro osmišljeni alati za migraciju koriste ovu mogućnost da bi očuvali originalni INTERNALDATE sa izvornog servera. Ali čak i kada je INTERNALDATE ispravno postavljen, problem sa zaglavljem "Received" (opisan u nastavku) i dalje može da poremeti prikazani datum u mnogim klijentima elektronske pošte.

3. Lanac zaglavlja "Received"

Svaki put kada email prođe kroz neki mail server, taj server dodaje zaglavlje "Received" na vrh poruke. Tako se stvara lanac zaglavlja Received koji beleži put koji je email prešao od pošiljaoca do primaoca. Najnovije (gornje) zaglavlje Received pokazuje poslednji server koji je obradio poruku, a najstarije (donje) pokazuje prvi.

Običan email može imati od 3 do 6 zaglavlja Received, koja dokumentuju put od izlaznog servera pošiljaoca, preko eventualnih relejnih servera, do dolaznog servera primaoca. Svako zaglavlje Received sadrži vremensku oznaku. Evo pojednostavljenog primera:

Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

Kako klijenti elektronske pošte biraju koji datum da prikažu

Outlook (desktop, web, mobilni)

Microsoft Outlook koristi kombinaciju INTERNALDATE-a i najnovijeg zaglavlja "Received" da odredi datum "Prijema" prikazan u prijemnom sandučetu. U praksi, Outlook obično daje prednost vremenskoj oznaci iz najnovijeg zaglavlja Received za kolonu "Primljeno". Kolona "Poslato" koristi zaglavlje Date. Pošto Outlook podrazumevano sortira po koloni "Primljeno", korisnici prvo vide upravo vremensku oznaku iz zaglavlja Received.

Apple Mail

Apple Mail na macOS-u i iOS-u za prikaz datuma prvenstveno koristi IMAP INTERNALDATE. Ako je INTERNALDATE tokom migracije ispravno očuvan, Apple Mail može da prikaže tačan datum, ali samo ako je INTERNALDATE eksplicitno postavljen prilikom operacije APPEND. Ako alat za migraciju nije postavio INTERNALDATE, server po podrazumevanim podešavanjima koristi vreme umetanja poruke (datum migracije). Za detalje o tome kako to utiče na korisnike Apple Maila, pogledajte Apple Mail: pogrešan datum nakon migracije.

Thunderbird

Mozilla Thunderbird nudi najviše fleksibilnosti. Može prikazivati i "Datum" (iz zaglavlja Date) i "Primljeno" (iz zaglavlja Received). Podrazumevano, Thunderbird prikazuje vrednost zaglavlja Date, što znači da datumi u Thunderbirdu mogu izgledati tačno i onda kada su pogrešni u Outlooku. Kolona "Primljeno" u Thunderbirdu i dalje prikazuje datum migracije. Pogledajte Thunderbird: pogrešan datum nakon migracije za više detalja.

Gmail veb interfejs

Gmail-ov veb klijent za primarni prikaz datuma koristi zaglavlje Date. To znači da Gmail na vebu često prikazuje tačne datume i nakon migracije. Ali IMAP INTERNALDATE na Gmail serveru je i dalje netačan, što utiče na svaki IMAP klijent koji se povezuje na taj Gmail nalog. Razlika između Gmail veba i Outlooka ili Apple Maila česti je izvor konfuzije, i upravo ona administratorima oduzima mnogo vremena prilikom rešavanja problema.

Zašto IMAP APPEND kvari datume

Šta se dešava tokom migracije

Kada alat za migraciju premešta email sa servera A na server B, taj alat se preko IMAP-a povezuje sa serverom A i preuzima izvornu poruku, a zatim se povezuje sa serverom B i koristi komandu APPEND da bi je umetnuo. Tokom tog umetanja, server B obrađuje dolazeću poruku i dodaje novo zaglavlje Received sa trenutnom vremenskom oznakom, datumom migracije. Ovo je uobičajeno ponašanje kod IMAP servera. Server tretira svaki APPEND kao novu isporuku poruke.

Rezultat: kontaminiran lanac zaglavlja

Nakon migracije, zaglavlja Received emaila izgledaju ovako:

Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

Zaglavlje Received alata za migraciju je sada najgornji unos. Svaki klijent elektronske pošte koji za prikazani datum koristi najgornje zaglavlje Received (Outlook, naročito) prikazaće "11. april 2025." umesto "15. januar 2024." Originalno zaglavlje Date i originalna zaglavlja Received i dalje su netaknuti ispod, ali se ne nalaze više na poziciji koju klijenti elektronske pošte uzimaju kao prioritetnu.

Čak i dobro upravljanje INTERNALDATE-om ne sprečava ovo

Neki alati za migraciju ispravno postavljaju INTERNALDATE tokom APPEND-a. Na primer, imapsync eksplicitno čuva INTERNALDATE izvornog servera. Ali zaglavlje Received dodaje odredišni server, a ne alat za migraciju. Alat za migraciju nema nikakvu kontrolu nad tim ponašanjem. Čak i uz savršeno očuvan INTERNALDATE, najgornje zaglavlje Received i dalje sadrži datum migracije, a klijenti kao Outlook i dalje prikazuju pogrešan datum.

Šta se, zapravo, može konkretno učiniti povodom toga?

Koji alati za migraciju dodaju zaglavlja Received

Svaki IMAP alat za migraciju uzrokuje ovaj problem, jer zaglavlje Received dodaje odredišni server, a ne sam alat. Sadržaj dodatog zaglavlja se, ipak, razlikuje od alata do alata i od servera do servera.

BitTitan MigrationWiz dodaje zaglavlje Received koje sadrži "mx.migrationwiz.com". CloudM Migrate dodaje zaglavlja koja referenciraju "cloudm.io". imapsync pokreće generičko zaglavlje Received sa odredišnog servera. GSMMO dodaje zaglavlja sa referencama na "gmailapi.google.com".

Rešenje: vraćanje tačnih datuma

Dobra vest je da tačan podatak o datumu i dalje postoji unutar svakog emaila. Originalno zaglavlje Date je netaknuto. Originalna zaglavlja Received su netaknuta. Problem je što kontaminirajuće zaglavlje leži iznad njih.

Sopstveni mehanizam za ispravku koji koristi Redate.io analizira kompletan lanac zaglavlja svakog pogođenog emaila, prepoznajući anomalije u datumima kako bi precizno identifikovao koja zaglavlja treba ispraviti, bez obzira na to koji je alat korišćen za migraciju. Višestepeni pristup analizi obuhvata i granične slučajeve koji jednostavnijim pristupima predstavljaju problem: S/MIME potpisane poruke, PGP šifrovani sadržaj, multipart/alternative strukture, probleme sa Content-Transfer-Encoding-om, ne-ASCII zaglavlja (RFC 2047), veoma velike priloge i oštećene MIME granice.

Nakon ispravke, svaki email prolazi proces provere integriteta kako bi se potvrdilo da su struktura poruke, sadržaj i prilozi u potpunosti sačuvani. Originalne poruke se premeštaju u vidljiv folder sa rezervnim kopijama u poštanskom sandučetu i tu ostaju sve dok ih klijent ne ukloni.

Da li biste mogli sami da napišete skriptu koja bi pokušala ovo da reši? Tehnički, da. Ali razlika između "radi na 95% emailova" i "radi na 100% emailova bez oštećenja i jednog jedinog" upravo je tamo gde odlaze meseci inženjerskog rada. A kada je reč o čitavom poštanskom sandučetu neke osobe, ta stopa neuspeha od 5% znači stotine tiho oštećenih poruka, bez ikakvog načina da se provere šta je zapravo pošlo po zlu.

Želite da vidite koliko emailova u Vašem poštanskom sandučetu ima pogrešne datume? Pokrenite besplatnu analizu sa Redate.io i odmah dobijte tačan broj pogođenih emailova, bez potrebe za plaćanjem.