IMAP INTERNALDATE: prečo sa dátumy pokazia

Tri dátumy v každom e-maile

Každý e-mail uložený na IMAP serveri obsahuje aspoň tri odlišné dátumové hodnoty. Pochopenie toho, ako tieto dátumy funguje a ako si e-mailový klient vyberá, ktorý z nich zobrazí, je základom pre pochopenie, prečo migrácia poškodí dátumy. Tento článok je technickou analýzou dátumového systému IMAP určenou IT administrátorom a všetkým, ktorí chcú pochopiť skutočnú príčinu problémov s dátumami po migrácii.

1. Hlavička "Date" podľa RFC 2822

Hlavička "Date" je definovaná v RFC 2822 (Internet Message Format). Nastavuje ju e-mailový klient odosielateľa v momente, keď je správa napísaná a odoslaná. Táto hlavička je súčasťou samotného tela e-mailovej správy, cestuje spolu so správou a poštové servery na ceste doručenia ju nikdy nemenia. Typická hlavička Date vyzerá takto:

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

Hlavička Date predstavuje "dátum odoslania" správy. Je najspoľahlivejším dátumom, pretože sa nastaví raz a nikdy sa nemení. Odráža však hodiny odosielateľa, ktoré môžu byť nesprávne nastavené. V zriedkavých prípadoch môže hlavička Date úplne chýbať (najmä pri automatických systémových upozorneniach alebo poškodených správach).

2. IMAP INTERNALDATE

INTERNALDATE je definovaný v RFC 3501 (protokol IMAP4rev1). Je to metaúdaj na strane servera, ktorý predstavuje dátum a čas, kedy bola správa doručená na server. Na rozdiel od hlavičky Date nie je INTERNALDATE súčasťou samotnej e-mailovej správy. IMAP server ho uchováva samostatne ako metaúdaj.

Keď je e-mail doručený bežným spôsobom (nie cez migráciu), IMAP server nastaví INTERNALDATE na aktuálny čas v momente doručenia. Tento čas sa takmer presne zhoduje s hlavičkou Date, obvykle v rozsahu sekúnd či minút. E-mailové klienty často používajú INTERNALDATE ako "dátum prijatia", pretože odráža, kedy server správu skutočne prijal.

Tu sa to začína komplikovať. Keď je správa vložená pomocou príkazu IMAP APPEND (a presne to robia migračné nástroje), príkaz APPEND umožňuje klientovi explicitne určiť hodnotu INTERNALDATE. Dobre navrhnuté migračné nástroje túto možnosť využívajú a zachovajú pôvodný INTERNALDATE zo zdrojového servera. Ale aj keď je INTERNALDATE nastavený správne, problém s hlavičkou "Received" (popísaný nižšie) môže v mnohých e-mailových klientoch stále prekryť zobrazený dátum.

3. Reťazec hlavičiek "Received"

Vždy, keď e-mail prejde poštovým serverom, tento server pripojí na začiatok správy hlavičku "Received". Tým vzniká reťazec hlavičiek Received, ktorý zaznamenáva cestu e-mailu od odosielateľa k prijímateľovi. Najnovšia (najvyššia) hlavička Received zobrazuje posledný server, ktorý správu spracoval, a najstaršia (najnižšia) zobrazuje ten prvý.

Bežný e-mail môže mať 3 až 6 hlavičiek Received, ktoré dokumentujú cestu od odosielajúceho servera cez prípadné relay servery až po prijímajúci server. Každá hlavička Received obsahuje časovú pečiatku. Zjednodušený príklad:

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

Ako si e-mailoví klienti vyberajú, ktorý dátum zobraziť

Outlook (desktop, web, mobil)

Microsoft Outlook používa kombináciu INTERNALDATE a najnovšej hlavičky "Received" na určenie dátumu "Prijaté" zobrazeného v priečinku doručenej pošty. V praxi Outlook zvyčajne dáva prednosť časovej pečiatke z najnovšej hlavičky Received pre stĺpec "Prijaté". Stĺpec "Odoslané" používa hlavičku Date. Keďže Outlook štandardne triedi podľa stĺpca "Prijaté", je to práve časová pečiatka hlavičky Received, ktorú používatelia vidia ako prvú.

Apple Mail

Apple Mail na macOS a iOS používa na zobrazenie dátumu primárne IMAP INTERNALDATE. Ak bol INTERNALDATE počas migrácie správne zachovaný, Apple Mail môže zobraziť správny dátum, ale iba za predpokladu, že bol INTERNALDATE explicitne nastavený počas operácie APPEND. Ak migračný nástroj INTERNALDATE nenastavil, server použije ako predvolenú hodnotu čas vloženia (dátum migrácie). Podrobnosti o tom, ako to ovplyvňuje používateľov Apple Mail, nájdete v článku Apple Mail wrong date after migration.

Thunderbird

Mozilla Thunderbird ponúka najväčšiu flexibilitu. Vie zobraziť aj "Date" (z hlavičky Date), aj "Received" (z hlavičiek Received). Štandardne Thunderbird zobrazuje hodnotu hlavičky Date, čo znamená, že dátumy môžu v Thunderbirde vyzerať správne, aj keď sú v Outlooku nesprávne. Stĺpec "Received" v Thunderbirde však stále zobrazuje dátum migrácie. Viac podrobností nájdete v článku Thunderbird wrong date after migration.

Webové rozhranie Gmailu

Webový klient Gmailu používa na primárne zobrazenie dátumu hlavičku Date. To znamená, že Gmail vo webovom rozhraní často zobrazuje správne dátumy aj po migrácii. IMAP INTERNALDATE na serveri Gmailu je však stále nesprávny, čo ovplyvňuje každého IMAP klienta, ktorý sa k tomuto účtu pripojí. Rozdiel medzi webovým Gmailom a Outlookom alebo Apple Mail je bežným zdrojom nejasností a stojí administrátorov veľa času pri riešení problémov.

Prečo IMAP APPEND poškodzuje dátumy

Čo sa deje počas migrácie

Keď migračný nástroj presúva e-mail zo servera A na server B, pripojí sa k serveru A cez IMAP, stiahne pôvodnú správu a potom sa pripojí k serveru B a pomocou príkazu APPEND ju vloží. Počas tohto vkladania server B spracuje prichádzajúcu správu a pridá novú hlavičku Received s aktuálnou časovou pečiatkou, teda dátumom migrácie. Ide o bežné chovanie IMAP servera pri príkaze APPEND. Server totiž považuje každý APPEND za nové doručenie správy.

Výsledok: znečistený reťazec hlavičiek

Po migrácii vypadajú hlavičky Received v e-maile takto:

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

Hlavička Received pochádzajúca z migračného nástroja je teraz na najvyššej pozícii. Každý e-mailový klient, ktorý na určenie zobrazeného dátumu používa najnovšiu hlavičku Received (najmä Outlook), zobrazí "11. apríla 2025" namiesto "15. januára 2024". Pôvodná hlavička Date a pôvodné hlavičky Received sú stále neporušené niže v reťazci, ale už nie sú na pozícii, ktorej e-mailoví klienti dávajú prednosť.

Ani správne zaobchádzanie s INTERNALDATE tomu nezabráni

Niektoré migračné nástroje nastavujú INTERNALDATE počas APPEND správne. Napríklad imapsync explicitne zachováva INTERNALDATE zo zdrojového servera. Hlavičku Received však pridáva cieľový server, nie migračný nástroj. Migračný nástroj toto chovanie nemôže ovplyvniť. Aj pri dokonalom zachovaní INTERNALDATE obsahuje najnovšia hlavička Received stále dátum migrácie a klienti ako Outlook zobrazujú stále nesprávny dátum.

Čo sa s tým vlastne dá robiť?

Ktoré migračné nástroje pridávajú hlavičky Received

Tento problém spôsobuje každý migračný nástroj pre IMAP, pretože hlavičku Received pridáva cieľový server, nie samotný migračný nástroj. Obsah pridanej hlavičky sa však líši podľa nástroja a servera.

BitTitan MigrationWiz pridáva hlavičku Received obsahujúcu "mx.migrationwiz.com". CloudM Migrate pridáva hlavičky s odkazom na "cloudm.io". imapsync vyvoláva všeobecnú hlavičku Received z cieľového servera. GSMMO pridáva hlavičky s odkazmi na "gmailapi.google.com".

Riešenie: obnovenie správnych dátumov

Dobrou správou je, že správna dátumová informácia stále existuje vnútri každého e-mailu. Pôvodná hlavička Date je neporušená. Pôvodné hlavičky Received sú neporušené. Problém je v tom, že nad nimi leží znečisťujúca hlavička.

Vlastný korekčný nástroj Redate.io analyzuje celý reťazec hlavičiek každého postihnutého e-mailu. Namiesto spoliehania sa na databázu konkrétnych migračných nástrojov identifikuje dátumové anomálie v reťazci hlavičiek, čo znamená, že funguje s akýmkoľvek migračným nástrojom. Viacstupňový analytický proces zvláda aj hraničné prípady, na ktorých zlyhávajú jednoduchšie riešenia: správy podpísané S/MIME, obsah šifrovaný PGP, štruktúry multipart/alternative, problémy s Content-Transfer-Encoding, neanglické hlavičky (RFC 2047), veľké prílohy a poškodené hranice MIME.

Po oprave prechádza každý e-mail procesom overenia integrity, ktorý potvrdí, že štruktúra správy, obsah aj prílohy zostali presne zachované. Pôvodné verzie sa presunú do viditeľného záložného priečinka v poštovej schránke, kde zostávajú, kým ich klient sám neodstráni.

Dalo by sa na to napísať skript sám? Technicky áno. Rozdiel medzi tým, že "to funguje na 95 % e-mailov", a tým, že "to funguje na 100 % e-mailov bez toho, aby sa poškodil čo i len jeden", je však presne to, čo stojí mesiace inžinierskej práce. A keď hovoríme o celej poštovej schránke niekoho iného, tých 5 % chybovosti v praxi znamená stovky tichým spôsobom poškodených správ bez možnosti overiť, čo sa vlastne stalo.

Chcete vidieť, koľko e-mailov vo vašej poštovej schránke má poškodené dátumy? Spustite bezplatnú analýzu s Redate.io a získajte okamžitý prehľad o postihnutých e-mailoch, bez potreby platby.