Tri datuma unutar svakog emaila
Svaki email pohranjen na IMAP poslužitelju nosi najmanje tri zasebne vrijednosti datuma. Razumijevanje kako ti datumi funkcioniraju, i kako klijenti elektroničke pošte biraju koji prikazati, ključ je za razumijevanje zašto migracija kvari datume. Ovaj članak je detaljna tehnička analiza IMAP sustava datuma, namijenjena informatičkim administratorima i svakome tko želi razumjeti temeljni uzrok problema datuma nakon migracije.
1. Zaglavlje "Date" RFC 2822
Zaglavlje "Date" definirano je u RFC 2822 (format internetskih poruka). Postavlja ga klijent elektroničke pošte pošiljatelja u trenutku kad je poruka napisana i poslana. Ovo zaglavlje dio je tijela same poruke, putuje s porukom i nikad ga ne modificiraju poslužitelji elektroničke 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 nikad ne mijenja. Međutim, odražava sat pošiljatelja, koji može biti krivo konfiguriran. U rijetkim slučajevima, zaglavlje Date može potpuno izostajati (posebno u automatiziranim sustavskim obavijestima ili lošo oblikovanim porukama).
2. IMAP INTERNALDATE
INTERNALDATE je definiran u RFC 3501 (protokol IMAP4rev1). To je vrijednost metapodatka na strani poslužitelja koja predstavlja datum i vrijeme kad je poruka isporučena na poslužitelj. Za razliku od zaglavlja Date, INTERNALDATE nije dio same email poruke. Pohranjuje ga zasebno IMAP poslužitelj kao metapodatak.
Kad se email isporuči normalno (ne migrira), IMAP poslužitelj postavlja INTERNALDATE na trenutno vrijeme u trenutku isporuke. Ova vrijednost blisko odgovara zaglavlju Date, obično unutar nekoliko sekundi ili minuta razlike. Klijenti elektroničke pošte često koriste INTERNALDATE kao "datum primitka" jer odražava trenutak kad je poslužitelj stvarno primio poruku.
I tu postaje zanimljivo. Kad se poruka umeće putem IMAP APPEND naredbe (koju koriste migracijski alati), APPEND naredba dopušta klijentu da eksplicitno navede INTERNALDATE. Dobro dizajnirani migracijski alati koriste ovu značajku za očuvanje izvornog INTERNALDATE-a s izvornog poslužitelja. Ali čak i kad je INTERNALDATE ispravno postavljen, problem zaglavlja "Received" (opisan u nastavku) može svejedno nadjačati prikazani datum u mnogim klijentima.
3. Lanac zaglavlja "Received"
Svaki put kad email prođe kroz poslužitelj elektroničke pošte, taj poslužitelj dodaje zaglavlje "Received" na početak poruke. Time se stvara lanac zaglavlja Received koji bilježi putovanje emaila od pošiljatelja do primatelja. Najnoviji (na vrhu) prikazuje zadnji poslužitelj koji je obradio poruku, a najstariji (na dnu) prikazuje prvi.
Normalan email može imati 3 do 6 zaglavlja Received, dokumentirajući putovanje od izlaznog poslužitelja pošiljatelja preko releja do dolaznog poslužitelja primatelja. Svako zaglavlje Received uključuje vremensku oznaku. Evo pojednostavljenog primjera:
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 elektroničke pošte biraju koji datum prikazati
Outlook (Desktop, Web, Mobile)
Microsoft Outlook koristi kombinaciju INTERNALDATE-a i najnovijeg zaglavlja "Received" za određivanje datuma "Primitka" prikazanog u pristigloj pošti. U praksi, Outlook daje prednost vremenskoj oznaci najnovijeg zaglavlja Received za stupac "Primljeno". Stupac "Poslano" koristi zaglavlje Date. Kako Outlook prema zadanim postavkama sortira po stupcu "Primljeno", upravo vremensku oznaku zaglavlja Received korisnici vide prvi.
Apple Mail
Apple Mail na macOS-u i iOS-u prvenstveno koristi IMAP INTERNALDATE za prikaz datuma. Ako je INTERNALDATE ispravno sačuvan tijekom migracije, Apple Mail može prikazati ispravni datum, ali samo ako je INTERNALDATE eksplicitno postavljen tijekom APPEND operacije. Ako migracijski alat nije postavio INTERNALDATE, poslužitelj prema zadanim postavkama koristi vrijeme umetanja (datum migracije). Za detalje o utjecaju na korisnike Apple Maila, pogledajte Apple Mail: krivi datum nakon migracije.
Thunderbird
Mozilla Thunderbird nudi najviše fleksibilnosti. Može prikazivati i "Datum" (iz zaglavlja Date) i "Primljeno" (iz zaglavlja Received). Prema zadanim postavkama, Thunderbird prikazuje vrijednost zaglavlja Date, što znači da datumi mogu izgledati ispravno u Thunderbirdu čak i kad su krivi u Outlooku. Stupac "Primljeno" u Thunderbirdu uvijek prikazuje datum migracije. Pogledajte Thunderbird: krivi datum nakon migracije za više detalja.
Gmail web sučelje
Gmail web klijent koristi zaglavlje Date za svoj primarni prikaz datuma. To znači da Gmail web često prikazuje ispravne datume čak i nakon migracije. Ali IMAP INTERNALDATE na Gmail poslužitelju je svejedno netočan, što utječe na svaki IMAP klijent koji se spaja na taj Gmail račun. Razlika između Gmail weba i Outlooka ili Apple Maila čest je izvor zabune, i ona koja administratorima troši mnogo vremena na dijagnostiku.
Zašto IMAP APPEND kvari datume
Što se događa tijekom migracije
Kad migracijski alat premješta email s Poslužitelja A na Poslužitelj B, alat se spaja na Poslužitelj A putem IMAP-a i preuzima izvornu poruku, pa se spaja na Poslužitelj B i koristi APPEND naredbu za umetanje. Tijekom ovog umetanja, Poslužitelj B obrađuje dolaznu poruku i dodaje novo zaglavlje Received s trenutnom vremenskom oznakom: datumom migracije. Ovo je standardno IMAP ponašanje definirano protokolom. Poslužitelj tretira svaki APPEND kao novu isporuku poruke.
Rezultat: kontaminirani 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 migracijskog alata sada je najgornji unos. Svaki klijent elektroničke pošte koji koristi najnovije zaglavlje Received za određivanje datuma prikaza (Outlook, naročito) prikazat će "11. travnja 2025." umjesto "15. siječnja 2024." Izvorno zaglavlje Date i izvorna zaglavlja Received i dalje su netaknuta ispod, ali više nisu na poziciji koju klijenti elektroničke pošte preferiraju.
Čak ni dobro upravljanje INTERNALDATE-om ne sprječava ovo
Neki migracijski alati ispravno postavljaju INTERNALDATE tijekom APPEND-a. Na primjer, imapsync eksplicitno čuva INTERNALDATE izvornog poslužitelja. Ali zaglavlje Received dodaje odredišni poslužitelj, ne migracijski alat. Migracijski alat nema nikakvu kontrolu nad tim ponašanjem. Čak i uz savršeno očuvanje INTERNALDATE-a, najgornje zaglavlje Received i dalje sadrži datum migracije, a klijenti poput Outlooka i dalje prikazuju krivi datum.
Ukratko, što se zapravo može konkretno učiniti?
Koji migracijski alati dodaju zaglavlja Received
Svi IMAP migracijski alati uzrokuju ovaj problem jer zaglavlje Received dodaje odredišni poslužitelj, ne sam alat. Sadržaj dodanog zaglavlja varira ovisno o alatu i poslužitelju.
BitTitan MigrationWiz dodaje zaglavlje Received koje sadrži "mx.migrationwiz.com". CloudM Migrate dodaje zaglavlja koja referenciraju "cloudm.io". imapsync aktivira generičko zaglavlje Received odredišnog poslužitelja. GSMMO dodaje zaglavlja s referencama na "gmailapi.google.com".
Ispravak: obnova ispravnih datuma
Dobra vijest je da ispravna informacija o datumu i dalje postoji u svakom emailu. Izvorno zaglavlje Date je netaknuto. Izvorna zaglavlja Received su netaknuta. Problem je u tome što kontaminirajuće zaglavlje sjedi iznad njih.
Vlasnički mehanizam za ispravke Redate.io-a analizira cjelokupni lanac zaglavlja svakog pogođenog emaila, primjenjujući usporedbu potpisa na stotinama poznatih potpisa migracijskih alata za precizno identificiranje koja zaglavlja trebaju ispravak. Višestupanjski analitički cjevovod upravlja rubnim slučajevima koji onemogućuju jednostavnije pristupe: S/MIME potpisane poruke, PGP šifrirani sadržaj, multipart/alternative strukture, problemi s Content-Transfer-Encoding-om, ne-ASCII zaglavlja (RFC 2047), preveliki privici i oštećene MIME granice.
Nakon ispravka, svaki email prolazi proces provjere cjelovitosti za potvrdu da su struktura, sadržaj i privici poruke identično sačuvani. Izvornici se čuvaju u vidljivoj mapi sigurnosne kopije 30 dana.
Može li se napisati skripta za pokušaj ovog ispravka sami? Tehnički, da. Ali razlika između "radi na 95 % emailova" i "radi na 100 % emailova bez oštećenja ijednog" predstavlja mjesece razvoja. A kad je u pitanju cjelokupni sandučić nekoga, stopa neuspjeha od 5 % znači stotine poruka tiho oštećenih bez načina da se provjeri što je pošlo po krivu.
Želite znati koliko emailova u vašem sandučiću ima krive datume? Pokrenite besplatnu analizu s Redate.io za trenutni pregled broja pogođenih emailova, bez potrebe za plaćanjem.