Prechod POP na IMAP: staré emaily datované dnes

Klasický scenár v pondelok ráno

Práve ste prepli e-mailový účet z POP3 na IMAP. Konfigurácia bola jednoduchá, poskytovateľ vás previedol celým procesom, všetko prebehlo hladko. Až kým ste znova neotvorili doručenú poštu. Emaily z roku 2019, 2021, archívy z minulého roka... všetky zobrazujú rovnaký dátum: dnes. Niekedy dokonca rovnaký čas, s rozdielom pár sekúnd.

Nie je to chyba vášho e-mailového klienta. Ani problém s časovým pásmom. Je to očakávané správanie protokolu IMAP, ktoré postihne každého, kto nahrá lokálne uložené emaily na server touto metódou.

POP3 vs. IMAP: zásadný rozdiel v ukladaní

Aby sme pochopili, prečo k problému dochádza, treba najprv pochopiť, ako funguje POP3 a v čom sa radikálne líši od IMAP.

Pri POP3 slúži server iba ako dočasná schránka. Váš klient (Outlook, Thunderbird, Apple Mail) sa pripojí, stiahne správy a podľa nastavenia ich zo servera vymaže alebo ponechá. Emaily potom žijú výlučne lokálne: v súbore .pst pri Outlooku, v lokálnom profile Thunderbirdu, v databáze na pevnom disku.

Pri IMAP je to naopak: emaily sú uložené na serveri. Klient iba zobrazuje, čo je uložené vzdialene. Odtiaľ pochádza transparentná synchronizácia medzi všetkými zariadeniami.

Problém nastáva pri prechode medzi týmito dvoma protokolmi - konkrétne vtedy, keď nahrávate staré lokálne POP emaily na IMAP server.

IMAP APPEND: príkaz, ktorý mení všetko

Keď e-mailový klient nahrá lokálnu správu na IMAP server, použije príkaz IMAP APPEND. Tento príkaz hovorí serveru: "ulož túto správu do daného priečinka".

Server správu prijme, uloží a priradí jej časovú pečiatku. Táto pečiatka sa nazýva INTERNALDATE. Je to centrálna metadáta IMAP: udáva, kedy bola správa uložená na server. A ak klient pri príkaze APPEND výslovne neuviedol dátum, server použije... aktuálny čas.

Inými slovami: nezáleží na tom, či správa v hlavičkách obsahuje dátum z roku 2018. Ak nikto serveru nepovie "tento e-mail je z roku 2018", server usúdi, že bol nahraný práve teraz, a priradí mu dnešný INTERNALDATE.

(Mimochodom, ak ste niekedy pozerali surové hlavičky emailu, videli ste riadok Date: uprostred tucta riadkov Received:. Toto pole Date:, definované v RFC 2822, obsahuje skutočný dátum odoslania. IMAP INTERNALDATE je ale samostatná metadáta uložená na strane servera, ktorá nemá nič spoločné s obsahom samotnej správy.)

Prečo je to iné ako migrácia IMAP-na-IMAP

Pri klasickej migrácii z jedného IMAP servera na druhý (pomocou BitTitan, CloudM, imapsync atď.) je problém trochu odlišný. Migračný nástroj kopíruje správy medzi servermi a v takom prípade môže (teoreticky) preniesť pôvodný INTERNALDATE na cieľový server cez príkaz APPEND. Tam nastáva problém inak: niektoré nástroje pridajú hlavičku Received: s dátumom migrácie, čo spôsobí zmätok pri zobrazení v klientoch ako Outlook.

V tomto prípade vychádzate z čisto lokálnych dát. Žiadny zdrojový INTERNALDATE na kopírovanie neexistuje. Súbor .pst alebo profil Thunderbirdu ukladá správy vo vlastnom proprietárnom formáte s vlastnými internými metadátami. Keď e-mailový klient tieto správy načíta a nahrá ich na IMAP server, zostaví príkaz APPEND z obsahu správy. A vo väčšine prípadov neprenáša žiadny explicitný dátum.

Výsledok: IMAP server prijme stovky či tisíce správ v priebehu niekoľkých minút a všetkým priradí rovnaké časové okno: teraz.

Práve preto sa problém okamžite prejaví na všetkých zariadeniach. Váš telefón, tablet, druhý počítač - všetky sa pripájajú k rovnakému IMAP serveru a vidia presne to isté. Na strane klienta nie je možná žiadna oprava.

Ktorý klient zobrazuje čo a prečo

Nie všetci e-mailoví klienti reagujú rovnako. To je niečo, čo mnohí IT admini zistia až spätne.

Outlook (v novších verziách, najmä od aktualizácií v rokoch 2023-2024) používa INTERNALDATE zo servera pre stĺpec "Prijaté". Zobrazuje teda dátum nahratia, nie pôvodný dátum odoslania. Viac o tomto špecifickom správaní Outlooku nájdete v článku Outlook: dátum prijatia IMAP vs dátum odoslania.

Gmail / Google Workspace a Thunderbird sa správajú trochu odlišne. Gmail napríklad niekedy môže použiť pole Date: z hlavičky správy na zobrazenie, čo môže vyvolať dojem, že všetko je v poriadku... kým sa nepokúsite triediť podľa dátumu a nezistíte, že poradie je úplne náhodné.

Apple Mail zvyčajne zobrazuje dátum extrahovaný z hlavičky Date:, ale triedenie a vyhľadávanie v pozadí používajú INTERNALDATE. Vaše emaily teda môžu vizuálne "vyzerať" správne, ale funkcia triedenia prestane správne fungovať. Podrobnosti o správaní Apple Mail nájdete v článku Apple Mail: nesprávny dátum po migrácii.

Dobrá správa: pôvodný dátum je neporušený

Hlavička Date: každého emailu, tá, ktorá obsahuje skutočný dátum odoslania (alebo prijatia), nebola dotknutá. Stále je tam, v tele správy. Vidíte ju, keď otvoríte email a pozriete si jeho detaily.

To, čo IMAP server "pokazil", je výlučne INTERNALDATE - táto metadáta existujúca externe mimo správy. Samotná správa je neporušená.

Práve to umožňuje opravu. A tiež vysvetľuje, prečo môže problém chvíľu ujsť pozornosti: emaily sa pri jednotlivom otvorení zdajú správne. Len pri pohľade na zoznam doručenej pošty zoradenej podľa dátumu sa problém stane viditeľným. Emaily z roku 2019 sa objavia navrchu, akoby práve prišli. Všetky s rovnakým dátumom.

Problém rozsahu: 3 000 emailov je niečo iné ako 3

Možno si hovoríte: "Jednoducho to vymažem a znova naimportujem, tentoraz správne." Na 5 alebo 10 testovacích emailoch? Áno, funguje to. Na schránke s 8 000 správami s vnorenou štruktúrou priečinkov, veľkými prílohami, podpísanými S/MIME emailmi a e-mailovými vláknami siahajúcimi do roku 2015... to je úplne iná situácia.

Domáci skript, ktorý funguje na testovacej dávke 50 emailov, môže pri produkčnej schránke pokojne vytvoriť duplikáty, stratiť prílohy alebo rozbiť konverzačné vlákna. Správa kvót API, výpadky siete, správy s atypickými MIME štruktúrami... to sú okrajové prípady, s ktorými nešpecializovaný nástroj jednoducho neporadí.

A čo ak sa niečo pokazí v polovici? Bez zálohovacieho mechanizmu a možnosti vrátenia späť strácate dáta bez možnosti ich obnovenia.

Tento problém dobre poznajú admini, ktorí sa zaoberajú objemnými migráciami. Pochopiť, prečo sú dátumy pokazené, je jedna vec. Správne opraviť 15 000 emailov pri zachovaní každej štruktúry správy je vec druhá. Viac o tomto téme nájdete v článku Ako opraviť dátumy emailov po migrácii, kde sú podrobne rozobraté rôzne prístupy a ich obmedzenia.

Ako Redate.io rieši tento konkrétny prípad

Redate.io bol navrhnutý presne pre tento typ situácie. Jeho analytický engine identifikuje emaily, kde INTERNALDATE nezodpovedá dátumu v hlavičkách správy - bez ohľadu na to, či ide o prechod POP na IMAP, migráciu medzi IMAP servermi alebo manuálne nahrávanie lokálnych archívov.

Viacfázový analytický pipeline skúma reťazec hlavičiek každej správy, overuje súlad s RFC a rekonštruuje metadáta dátumu bez zmeny obsahu správy: ani text, ani prílohy, ani štruktúra MIME, ani prípadné digitálne podpisy sa nemenia. Každý opravený email je pred potvrdením overený individuálne.

Originály sú po dobu 30 dní uchovávané v viditeľnom záložnom priečinku. Ak sa niečo nezdá, môžete obnoviť pôvodný stav.

Úvodný sken je bezplatný: Redate.io analyzuje vašu schránku, identifikuje dotknuté emaily a oznámi vám presný počet ešte predtým, ako sa rozhodnete. Žiadne záväzky naslepo.

Redate.io sa pripája priamo k schránkam cez Google Workspace (delegovanie domény), Microsoft 365 (Azure AD) alebo priamy IMAP. Žiadna lokálna inštalácia. Žiadne manuálne manipulovanie so súbormi .pst.

Pre adminom, ktorí spravujú viacero schránok a hľadajú praktické skúsenosti s týmto typom prípadov, je článok MSP: oprava dátumov e-mailov klientov po migrácii vhodným doplnkovým čítaním. A pre špecifiká opravy v Thunderbirde, ktorý má pri prechode POP/IMAP vlastné správanie, pozrite Thunderbird: nesprávny dátum po migrácii.

Ak to ešte len plánujete: ako predísť problému

Ak ste ešte nenahrali lokálne archívy na IMAP server, alebo ak plánujete ďalšie migrácie POP účtov vo vašej organizácii, tu je niekoľko vecí, ktoré treba mať na pamäti.

• Overte, či váš e-mailový klient podporuje explicitné zadanie dátumu v príkaze APPEND. Thunderbird napríklad mal v závislosti od verzie v tomto bode rôzne správanie.
• Najprv otestujte na validačnom účte so 50-100 reprezentatívnymi správami: staré emaily, emaily s prílohami, podpísané emaily. Overte zobrazené dátumy v rôznych klientoch.
• Naplánujte opravu skôr, ako koncoví používatelia začnú pracovať s migrovanou schránkou. Oprava dátumov na aktívnej schránke je zložitejšia ako na čerstvo migrovanej prázdnej schránke.
• Zdokumentujte počet emailov pred migráciou aj po nej. Len tak môžete odhaliť tichú stratu dát.

Komplexný zoznam bodov na kontrolu pred migráciou aj po nej nájdete v článku Checklist migrácie emailov: predchádzanie problémom s dátumami, ktorý pokrýva všetky typy prípadov.

Vaše staré emaily zobrazujú dnešný dátum po prechode z POP na IMAP? Spustite bezplatný sken na Redate.io a zistite rozsah problému - dátumy budú opravené bez akéhokoľvek zásahu do obsahu vašich správ.