POP na IMAP: staré e-maily mají dnešní datum

Klasický scénář pondělního rána

Právě jste přepnuli e-mailový účet z POP3 na IMAP. Konfigurace byla jednoduchá, hosting Vás provedl každým krokem, vše proběhlo bez problémů. Pak jste znovu otevřeli doručenou poštu. E-maily z roku 2019, 2021, archivy z loňského roku... všechny zobrazují stejné datum: dnešek. Někdy dokonce stejnou hodinu, s rozdílem pár sekund.

Nejde o chybu e-mailového klienta. Nejde o problém s časovým pásmem. Jde o očekávané chování protokolu IMAP, které postihne každého, kdo nahrává lokálně uložené e-maily na server touto cestou.

POP3 vs. IMAP: zásadní rozdíl ve způsobu ukládání

Abychom pochopili, proč k problému dochází, musíme nejprve pochopit, jak funguje POP3 a v čem se zásadně liší od IMAP.

U POP3 slouží server pouze jako dočasná poštovní schránka. Váš klient (Outlook, Thunderbird, Apple Mail) se připojí, stáhne zprávy a pak je ze serveru smaže (nebo ponechá, podle nastavení). E-maily pak žijí výhradně lokálně: v souboru .pst pro Outlook, v lokálním profilu Thunderbirdu, v databázi na pevném disku.

U IMAP je to přesně naopak: e-maily žijí na serveru. Klient je pouze zobrazuje ze vzdáleného úložiště. Odtud plyne transparentní synchronizace mezi všemi zařízeními.

Problém nastává při přechodu mezi oběma protokoly, konkrétně ve chvíli, kdy nahrávate staré lokální e-maily z POP na IMAP server.

IMAP APPEND: příkaz, který mění vše

Když e-mailový klient nahraje lokální zprávu na IMAP server, použije příkaz IMAP APPEND. Tento příkaz serveru říká: „ulož tuto zprávu do příslušné složky".

Server zprávu přijme, uloží a přiřadí jí časové razítko. Tímto razítkem je INTERNALDATE. Jde o ústřední metadatum IMAP: říká, kdy byla zpráva na server doručena. A pokud klient v příkazu APPEND explicitně datum neuvede, server použije... aktuální okamžik.

Jinými slovy: nezáleží na tom, zda zpráva v hlavičkách nese datum z roku 2018. Pokud nikdo serveru neříká „tento e-mail je z roku 2018", server usoudí, že byl doručen právě teď, a přiřadí mu dnešní INTERNALDATE.

(Mimochodem, pokud jste někdy prohlíželi nezpracované hlavičky e-mailu, viděli jste řádek Date: uprostřed desítek dalších řádků Received:. Právě pole Date: definované normou RFC 2822 obsahuje skutečné datum odeslání. Ale INTERNALDATE IMAP je samostatné metadatum uložené na straně serveru, které nemá s obsahem zprávy nic společného.)

Proč je to jiné než migrace IMAP-to-IMAP

Při klasické migraci z jednoho IMAP serveru na druhý (přes BitTitan, CloudM, imapsync atd.) je problém mírně odlišný. Migrační nástroj kopíruje zprávy mezi servery a může (teoreticky) předat původní INTERNALDATE cílovému serveru prostřednictvím příkazu APPEND. Potíž tam spočívá v tom, že některé nástroje přidávají hlavičku Received: s datem migrace, což narušuje zobrazení v klientech, jako je Outlook.

Ve Vašem případě vycházíte z čistě lokálních dat. Žádný zdrojový INTERNALDATE ke zkopírování neexistuje. Soubor .pst nebo profil Thunderbirdu ukládá zprávy ve svém proprietárním formátu s vlastními interními metadaty. Když e-mailový klient tyto zprávy načítá a nahrává je na IMAP server, rekonstruuje příkaz APPEND z obsahu zprávy. A ve většině případů explicitní datum nepředá.

Výsledek: IMAP server přijme v řádu minut stovky nebo tisíce zpráv a všem přiřadí stejný časový rozsah: teď.

Přesně proto se problém okamžitě šíří na všechna Vaše zařízení. Telefon, tablet, druhý počítač, to vše se připojuje ke stejnému IMAP serveru a vidí totéž. Na straně klienta žádná oprava není možná.

Který klient zobrazuje co a proč

Ne všichni e-mailoví klienti reagují stejně. Mnozí IT admini to zjistí až zpětně.

Outlook (v novějších verzích, zejména od aktualizací v letech 2023-2024) používá pro sloupec „Přijato" INTERNALDATE ze serveru. Zobrazuje tedy datum nahrání, ne původní datum odeslání. Více o tomto chování specifickém pro Outlook najdete v článku Outlook: datum migrace IMAP vs datum odeslání.

Gmail / Google Workspace a Thunderbird se chovají o něco nuancovaněji. Gmail například může někdy používat pro zobrazení pole Date: z hlavičky zprávy, což vytváří dojem, že vše funguje správně... až do chvíle, kdy se pokusíte seřadit zprávy podle data a zjistíte, že pořadí je zcela náhodné.

Apple Mail zpravidla zobrazuje datum vytažené z hlavičky Date:, ale řazení a vyhledávání v pozadí pracují s INTERNALDATE. Vaše e-maily tak mohou vizuálně vypadat správně datované, ale funkce řazení přestane fungovat. Podrobnosti o chování Apple Mail najdete v článku Apple Mail: špatné datum po migraci.

Dobrá zpráva: původní datum je nedotčené

Hlavička Date: každého e-mailu, ta, která obsahuje skutečné datum odeslání (nebo přijetí), nebyla pozměněna. Stále je tam, uvnitř zprávy. To je datum, které vidíte, když e-mail otevřete a zobrazíte detaily.

Co IMAP server „rozbil", je výhradně INTERNALDATE, toto metadatum stojící vně samotné zprávy. Zpráva samotná je neporušená.

Právě to umožňuje opravu. A také vysvětluje, proč problém může chvíli zůstat bez povšimnutí: e-maily vypadají správně, když je otevíráte jeden po druhém. Problém se projeví teprve při pohledu na seznam doručené pošty seřazené podle data. E-maily z roku 2019 se zobrazují nahoře, jako by právě dorazily. Všechny se stejným datem.

Problém s rozsahem: 3000 e-mailů je jiná liga než 3

Možná si říkáte: „Stačí je smazat a znovu importovat, tentokrát správně." Na 5 nebo 10 testovacích e-mailech to funguje. Na schránce s 8000 zprávami, vnořenými složkami, velkými přílohami, S/MIME podepsanými e-maily a vlákny sahajícími až do roku 2015... je to úplně jiný příběh.

Domácí skript, který funguje na testovací dávce 50 e-mailů, může na produkční schránce klidně vytvářet duplicity, ztrácet přílohy nebo rozbíjet konverzační vlákna. Správa API kvót, síťových timeoutů, zpráv s atypickými MIME strukturami... to jsou okrajové případy, se kterými nespecializovaný nástroj nepočítá.

A pokud se něco pokazí v půlce procesu? Bez zálohovacího a rollback mechanismu přijdete o data bez možnosti obnovy.

Problém je dobře znám adminům spravujícím objemové migrace. Pochopit, proč jsou data poškozená, je jedna věc. Čistě opravit 15000 e-mailů při zachování struktury každé zprávy je věc druhá. Více o tomto tématu najdete v článku Lze opravit data e-mailů po migraci?, který popisuje různé přístupy a jejich limity.

Jak Redate.io řeší tento konkrétní případ

Redate.io byl navržen přesně pro tento typ situace. Jeho analytický engine identifikuje e-maily, u nichž INTERNALDATE neodpovídá datu obsaženému v hlavičkách zprávy, ať jde o migraci POP na IMAP, migraci mezi IMAP servery, nebo ruční nahrání lokálních archivů.

Víceúrovňový analytický pipeline prochází řetězec hlaviček každé zprávy, ověřuje shodu s RFC a rekonstruuje datová metadata bez zásahu do obsahu zprávy: ani text, ani přílohy, ani MIME struktura, ani případné digitální podpisy nejsou dotčeny. Každý opravený e-mail je před potvrzením individuálně ověřen.

Originály jsou po dobu 30 dnů uchovány v zálohovací složce, která je viditelná. Pokud Vám něco nevyhovuje, můžete obnovit původní stav.

Úvodní sken je zdarma: Redate analyzuje Vaši schránku, identifikuje postižené e-maily a sdělí Vám přesný počet ještě předtím, než se k čemukoli zavážete. Žádné závazky naslepo.

Redate.io se připojuje přímo k Vašim schránkám přes Google Workspace (delegace domény), Microsoft 365 (Azure AD) nebo přímý IMAP. Žádná lokální instalace. Žádné exportované soubory .pst, se kterými byste museli ručně manipulovat.

Admini spravující více schránek, kteří hledají praktické zkušenosti s tímto typem případů, ocení doplňkové čtení v článku MSP: oprava datumů e-mailů u klientů. A pro specifika opravy v Thunderbirdu, který má při přechodu POP/IMAP vlastní chování, viz Thunderbird: špatné datum po migraci e-mailů.

Pokud to teprve plánujete: jak problému předejít

Pokud jste ještě nepřenesli lokální archivy na IMAP server, nebo plánujete další migrace POP účtů ve Vaší organizaci, toto si zapamatujte.

• Ověřte, zda Váš e-mailový klient podporuje explicitní předání data v příkazu APPEND. Thunderbird měl v tomto ohledu napříč verzemi proměnlivé chování.
• Nejprve otestujte na ověřovacím účtu s 50-100 reprezentativními zprávami: staré e-maily, zprávy s přílohami, podepsané e-maily. Zkontrolujte zobrazená data v různých klientech.
• Naplánujte opravu dříve, než koncoví uživatelé začnou pracovat s migrovanou schránkou. Opravovat data v aktivní schránce je složitější než v čerstvě migrované prázdné schránce.
• Zdokumentujte počet e-mailů před migrací i po ní. Je to jediný způsob, jak odhalit tiché ztráty.

Kompletní checklist bodů k ověření před migrací i po ní najdete v článku Checklist migrace e-mailů: jak předejít problémům s daty.

Vaše staré e-maily zobrazují po přechodu z POP na IMAP dnešní datum? Spusťte bezplatný sken na Redate.io a zjistěte rozsah problému. Datová metadata budou opravena bez zásahu do obsahu Vašich zpráv.