Tři datumy uvnitř každého e-mailu
Každý e-mail uložený na serveru IMAP nese minimálně tři různé hodnoty data. Pochopení toho, jak tyto datumy fungují a jak si e-mailoví klienti vybírají, které zobrazí, je základem pro pochopení toho, proč migrace kazí datumy. Tento článek je hloubková technická analýza systému datumů IMAP, určená IT administrátorům a každému, kdo chce porozumět hlavní příčině problémů s datumy po migraci.
1. Hlavička "Date" RFC 2822
Hlavička "Date" je definována v RFC 2822 (formát internetových zpráv). Nastavuje ji e-mailový klient odesílatele v okamžiku sestavení a odeslání zprávy. Tato hlavička je součástí samotného těla zprávy - cestuje se zprávou a nikdy není upravována e-mailovými servery na cestě doručení. Typická hlavička Date vypadá takto:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Hlavička Date představuje "datum odeslání" zprávy. Je to nejspolehlivější datum, protože je nastaveno jednou a nikdy pozměněno. Odráží však hodiny odesílatele, které mohou být špatně nastaveny. Ve vzácných případech může hlavička Date zcela chybět (zejména u automatizovaných systémových oznámení nebo chybně formátovaných zpráv).
2. IMAP INTERNALDATE
INTERNALDATE je definován v RFC 3501 (protokol IMAP4rev1). Je to hodnota metadat na straně serveru, která představuje datum a čas doručení zprávy na server. Na rozdíl od hlavičky Date, INTERNALDATE není součástí samotného e-mailu. Je uložen samostatně serverem IMAP jako metadata.
Když je e-mail doručen normálně (ne migrován), server IMAP nastaví INTERNALDATE na aktuální čas doručení. Tato hodnota odpovídá hlavičce Date obvykle s rozdílem několika sekund nebo minut. E-mailoví klienti často používají INTERNALDATE jako "datum přijetí", protože odráží okamžik, kdy server zprávu skutečně přijal.
A tady to začíná být zajímavé. Když je zpráva vložena příkazem IMAP APPEND (což používají migrační nástroje), příkaz APPEND umožňuje klientovi explicitně specifikovat INTERNALDATE. Dobře navržené migrační nástroje tuto funkci využívají k zachování původního INTERNALDATE ze zdrojového serveru. Ale i když je INTERNALDATE správně nastaven, problém s hlavičkou "Received" (popsaný níže) může stále přepsat zobrazované datum v mnoha klientech.
3. Řetězec hlaviček "Received"
Pokaždé, když e-mail prochází e-mailovým serverem, tento server přidá hlavičku "Received" na začátek zprávy. Tím vzniká řetězec hlaviček Received, který zaznamenává cestu e-mailu od odesílatele k příjemci. Nejnovější (nahoře) ukazuje poslední server, který zprávu zpracoval, a nejstarší (dole) ukazuje první.
Běžný e-mail může mít 3 až 6 hlaviček Received, dokumentujících cestu od odchozího serveru odesílatele přes relaye až k příchozímu serveru příjemce. Každá hlavička Received obsahuje časové razítko. Zde je zjednodušený pří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
Jak si e-mailoví klienti vybírají, které datum zobrazit
Outlook (Desktop, Web, Mobile)
Microsoft Outlook používá kombinaci INTERNALDATE a nejnovější hlavičky "Received" k určení data "Přijetí" zobrazeného ve schránce. V praxi Outlook upřednostňuje časové razítko z nejnovější hlavičky Received pro sloupec "Přijato". Sloupec "Odesláno" používá hlavičku Date. Protože Outlook ve výchozím nastavení řadí podle sloupce "Přijato", je to právě časové razítko z hlavičky Received, které uživatelé vidí jako první.
Apple Mail
Apple Mail na macOS a iOS používá primárně IMAP INTERNALDATE k zobrazení data. Pokud byl INTERNALDATE správně zachován během migrace, Apple Mail může zobrazovat správné datum, ale pouze pokud byl INTERNALDATE explicitně nastaven při operaci APPEND. Pokud migrační nástroj INTERNALDATE nenastavil, server použije výchozí čas vložení (datum migrace). Pro podrobnosti o dopadu na uživatele Apple Mail viz Apple Mail: špatné datum po migraci.
Thunderbird
Mozilla Thunderbird nabízí největší flexibilitu. Může zobrazovat "Date" (z hlavičky Date) i "Přijato" (z hlaviček Received). Ve výchozím nastavení Thunderbird zobrazuje hodnotu hlavičky Date, což znamená, že datumy mohou vypadat správně v Thunderbirdu, i když jsou špatné v Outlooku. Sloupec "Přijato" v Thunderbirdu vždy zobrazuje datum migrace. Viz Thunderbird: špatné datum po migraci pro více podrobností.
Webové rozhraní Gmailu
Webový klient Gmailu používá hlavičku Date pro hlavní zobrazení data. To znamená, že Gmail web často ukazuje správné datumy i po migraci. Ale IMAP INTERNALDATE na serveru Gmail je stále nesprávný, což postihuje každého klienta IMAP, který se k tomuto účtu Gmail připojí. Rozdíl mezi webovým rozhraním Gmailu a Outlookem nebo Apple Mail je častým zdrojem zmatku a stojí administrátory mnoho hodin zbytečného hledání příčin.
Proč IMAP APPEND kazí datumy
Co se děje během migrace
Když migrační nástroj přesouvá e-mail ze Serveru A na Server B, nástroj se připojí k Serveru A přes IMAP a stáhne surovou zprávu, poté se připojí k Serveru B a použije příkaz APPEND k jejímu vložení. Během tohoto vkládání Server B zpracuje příchozí zprávu a přidá novou hlavičku Received s aktuálním časovým razítkem: datem migrace. Toto je standardní chování IMAP definované v protokolu. Server zachází s každým APPEND jako s novým doručením zprávy.
Výsledek: kontaminovaný řetězec hlaviček
Po migraci hlavičky Received e-mailu vypadají 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 z migračního nástroje je nyní nejvyšší záznam. Jakýkoli e-mailový klient, který používá nejnovější hlavičku Received k určení zobrazeného data (zejména Outlook), zobrazí "11. dubna 2025" místo "15. ledna 2024". Původní hlavička Date a původní hlavičky Received jsou stále neporušené pod ní, ale už nejsou na pozici, kterou e-mailoví klienti upřednostňují.
Ani správné zacházení s INTERNALDATE tomu nezabrání
Některé migrační nástroje správně nastavují INTERNALDATE během APPEND. Například imapsync explicitně zachovává INTERNALDATE ze zdrojového serveru. Ale hlavičku Received přidává cílový server, nikoli migrační nástroj. Migrační nástroj nemá nad tímto chováním žádnou kontrolu. I s dokonalým zachováním INTERNALDATE obsahuje nejvyšší hlavička Received stále datum migrace a klienti jako Outlook stále zobrazují špatné datum.
Zkrátka, co se s tím dá prakticky udělat?
Které migrační nástroje přidávají hlavičky Received
Všechny migrační nástroje IMAP způsobují tento problém, protože hlavičku Received přidává cílový server, nikoli nástroj samotný. Obsah přidané hlavičky se liší podle nástroje a serveru.
BitTitan MigrationWiz přidá hlavičku Received obsahující "mx.migrationwiz.com". CloudM Migrate přidá hlavičky odkazující na "cloudm.io". imapsync spustí generickou hlavičku Received z cílového serveru. GSMMO přidá hlavičky s odkazy na "gmailapi.google.com".
Oprava: obnovení správných datumů
Dobrá zpráva je, že správná informace o datu stále existuje v každém e-mailu. Původní hlavička Date je neporušená. Původní hlavičky Received jsou neporušené. Problém je v tom, že kontaminující hlavička sedí nad nimi.
Proprietární opravný engine Redate.io analyzuje kompletní řetězec hlaviček každého postiženého e-mailu s použitím porovnání podpisů z databáze stovek známých podpisů migračních nástrojů, aby přesně identifikoval, které hlavičky vyžadují opravu. Vícestupňový analytický pipeline zvládá speciální případy, u kterých jednodušší přístupy selhávají: zprávy podepsané S/MIME, šifrovaný obsah PGP, multipart/alternative struktury, problémy s Content-Transfer-Encoding, hlavičky v ne-ASCII znacích (RFC 2047), nadměrně velké přílohy a poškozené MIME hranice.
Po opravě každý e-mail projde procesem kontroly integrity, který potvrdí, že struktura, obsah a přílohy zprávy jsou zachovány beze změn. Originály jsou uchovány v záložní složce viditelné po dobu 30 dní.
Dalo by se napsat vlastní skript a pokusit se o tuto opravu? Technicky ano. Ale rozdíl mezi "funguje to na 95 % e-mailů" a "funguje to na 100 % e-mailů bez poškození jediného" představuje měsíce vývoje. A když se jedná o kompletní schránku někoho jiného, 5% míra selhání znamená stovky zpráv tiše poškozených bez možnosti ověřit, co se pokazilo.
Chcete vědět, kolik e-mailů ve Vaší schránce má špatné datumy? Spusťte bezplatnou analýzu s Redate.io pro okamžitý počet postižených e-mailů, bez nutnosti platby.