Migrace cPanel: chybná data e-mailů

Pondělní ráno, které bolí

Právě jste dokončili migraci sdíleného hostingu cPanel do Google Workspace nebo Microsoft 365. Operace proběhla hladce, schránky jsou dostupné, uživatelé se přihlašují. Pak, kolem 9:15, přijde první ticket: "Staré e-maily mi zobrazují všechny stejné datum, to z minulého víkendu." Pak druhý. Pak deset.

Nejde o ojedinělou chybu. Je to přímý důsledek způsobu, jakým migrace z cPanel zacházejí (nebo spíše nezacházejí) s datovými metadaty e-mailů.

cPanel, Roundcube, Horde: specifický kontext IMAP

Sdílený hosting cPanel je linuxový server, na kterém běží IMAP server (obvykle Dovecot) s Roundcube nebo Horde jako webmailovým rozhraním. Nic neobvyklého. Ale tento kontext má svá specifika, která dělají migrace na podnikové platformy složitějšími, než se na první pohled zdá.

Schránky na cPanel zpravidla shromažďují e-maily po léta, někdy celé desetiletí. Zákazník, který měl svou doménu u sdíleného hostingu od roku 2013, může mít velmi hluboké archivy. Tento objem, kombinovaný s tím, jak je migrace provedena, vytváří příznivé podmínky pro problém s daty.

Nástroje používané pro tyto migrace jsou většinou buď nativní nástroj cPanel ("Migrace" ve WHM), nebo imapsync spouštěný z příkazové řádky hostitelem či IT dodavatelem, případně populární nástroje jako GSMMO pro migraci do Google Workspace.

Proč jsou data po migraci cPanel poškozena

Pro pochopení problému je třeba rozlišovat dva různé koncepty: hlavičku Date: e-mailu a INTERNALDATE v IMAP.

Hlavička Date: je zapsána v surových datech zprávy v okamžiku odeslání, v souladu s RFC 2822. Udává, kdy byl e-mail napsán a odeslán. Tato hlavička se nikdy nemění, pokud se se zprávou záměrně nemanipuluje.

INTERNALDATE je metadata, která IMAP server přiřazuje každé uložené zprávě. Je oddělena od obsahu zprávy. Když e-mail normálně dorazí na server, INTERNALDATE se nastavuje z hlaviček Received: zprávy, nebo z data doručení, pokud je zpráva vložena přímo. Tuto hodnotu Outlook, Thunderbird a většina e-mailových klientů používá k řazení zpráv.

Při migraci IMAP se zprávy kopírují z jednoho serveru na druhý. Problém spočívá v tom, že migrační nástroj musí každou zprávu na cílovém serveru znovu vytvořit. A u mnoha nástrojů odpovídá INTERNALDATE nově vytvořené zprávy datu migrace, nikoli původnímu datu zprávy. Zároveň je na začátek řetězce hlaviček přidána hlavička Received: orazítkovaná datem migrace, což ještě více mate e-mailové klienty, které se na ni odkazují při výpočtu zobrazeného data.

Výsledek: e-mail z roku 2019 dorazí do Google Workspace s INTERNALDATE nastaveným na den migrace a hlavičkou Received: s včerejším razítkem. Outlook ho zobrazí v doručené poště, jako by právě přišel. Celá chronologie archívu je zničena.

Migrační nástroj WHM / cPanel

Nástroj integrovaný ve WHM pro migraci účtů cPanel na jinou platformu generuje tento problém téměř systematicky, pokud je cílem externí IMAP server (Google Workspace, Microsoft 365). Kopíruje obsah složek Maildir na nový server přes IMAP APPEND bez zachování původního INTERNALDATE. Každá zpráva tak dostane časové razítko z okamžiku operace.

imapsync a ruční migrace z cPanel

imapsync je výkonný nástroj, ale jeho výchozí chování ne vždy zachovává data. Bez správných parametrů (a správné verze) může klidně zkopírovat 40 000 zpráv a všem přiřadit datum spuštění skriptu. (Mimochodem, pokud jste někdy procházeli logy imapsync řádek po řádku, abyste diagnostikovali problém s daty v schránce s 25 000 zprávami, víte, že to není zážitek, který by se člověk chtěl opakovat.)

Přesněji řečeno, imapsync disponuje volbami pro zachování data, ale tyto volby fungují různě v závislosti na zdrojovém a cílovém serveru a jejich účinnost není zaručena ve všech konfiguracích cPanel / Dovecot.

GSMMO a spotřebitelské nástroje

Google Workspace Migration for Microsoft Outlook (GSMMO) je určen pro migraci z Outlooku, nikoli z holého IMAP serveru. Pokud je použit pro migraci z cPanel (přes IMAP účet nakonfigurovaný v Outlooku), data procházejí stejným zpracováním: INTERNALDATE v Google Workspace se nastaví na datum migrace. Problém GSMMO a data e-mailů je mimochodem dokumentován samostatně, natolik je rozšířený.

Které e-mailové klienty jsou postiženy?

Poškození dat se projevuje různě v závislosti na použitém klientovi.

Outlook je nejvíce postižený klient. Jako hlavní kritérium řazení složek používá INTERNALDATE (nebo hlavičku Received: z migrace). Po špatně provedené migraci cPanel může schránka v Outlooku zobrazovat tisíce archivovaných e-mailů s datem migračního víkendu. Oprava dat imapsync v Outlooku patří k nejčastěji požadovaným opravám.

Gmail (Google Workspace) obvykle zobrazuje datum z hlavičky Date: v seznamu e-mailů, ale řazení může být přesto ovlivněno INTERNALDATE v určitých situacích. Uživatelé hlásí nepravidelné chování při vyhledávání a řazení podle data.

Apple Mail a Thunderbird mají složitější chování, ale ani jeden není vůči tomuto problému imunní, zvláště když je migrační hlavička Received: přítomna na začátku řetězce.

Dobrá zpráva: původní datum je stále přítomno

To je technický detail, který mění vše. Původní hlavička Date: zprávy je zapsána v surových datech e-mailu. Migrace se jí nedotkne. Když otevřete postižený e-mail a podíváte se na surové hlavičky (v Gmailu: "Zobrazit originál", v Outlooku: Soubor > Vlastnosti), uvidíte původní Date: v nedotčené podobě, za nímž následuje jedna nebo více hlaviček Received:, přičemž první nese datum migrace.

Tato informace je vždy přítomna. Lze ji využít k opravě metadat. Přesně to dělá opravný engine Redate.io.

Proč je "opravit si to sami" riskantnější, než to vypadá

Pokušení je silné. Problém se zdá jednoduchý: přečíst původní datum, opravit metadata, přejít na další. Ale mezi pochopením mechanismu a opravou 12 000 e-mailů v produkci bez ztráty jediného je propastný rozdíl.

Několik skutečností, se kterými domácí skripty zpravidla nepočítají:

E-maily podepsané S/MIME nebo šifrované PGP: jakákoli změna struktury zprávy zneplatní kryptografický podpis. E-mail, který před opravou procházel ověřením podpisu, po ní neprojde. Uživatelé v regulatorně citlivých prostředích (advokátní kancelář, finanční sektor, zdravotnictví) na to přijdou v nejhorší možnou chvíli.
Non-ASCII hlavičky a kódování RFC 2047: schránky cPanel hromadí e-maily z mnoha různých e-mailových klientů. Některé hlavičky obsahují znaky kódované podle RFC 2047. Špatně napsaný skript, který hlavičky rekonstruuje, může tato kódování nepozorovaně poškodit.
Vnořené MIME struktury: e-mail se třemi přílohami a alternativním HTML tělem má komplexní strukturu multipart. Sebemenší chyba na hranicích MIME zprávu znečitelní, nebo hůř: přílohy zmizí bez chybového hlášení.
API kvóty a rate limiting: Google Workspace i Microsoft 365 mají přísné limity na počet IMAP operací za minutu. Skript, který správně neimplementuje exponenciální backoff, vyvolá chyby 429 ve tři hodiny ráno a vy se probudíte s napůl dokončenou migrací, aniž víte přesně, kde se zastavila.
Žádný rollback: pokud se něco pokazí uprostřed procesu, k jakému stavu se vrátíte? Jsou originály ještě na místě? Máte duplikáty? Redate.io uchovává originály v viditelné zálohovací složce po dobu 30 dnů, právě proto, abyste se nikdy nedostali do takové situace.

Skript, který funguje na 50 testovacích e-mailech ve vývojovém prostředí, nemusí nutně fungovat na 18 000 zprávách produkční schránky zděděné z cPanel hostingu od roku 2011.

Jak Redate.io opravuje data po migraci cPanel

Redate.io se připojí přímo k cílové schránce (Google Workspace přes delegaci domény, Microsoft 365 přes Azure AD nebo přímý IMAP server) a začne bezplatným skenem pro identifikaci e-mailů, jejichž datová metadata jsou v rozporu s původní hlavičkou Date:.

Víceúrovňový analytický pipeline pak aplikuje porovnávání vzorů na signatury hlaviček Received:, aby identifikoval ty, které byly vloženy migračními nástroji (a odlišil je od legitimních hlaviček). Cílená oprava metadat probíhá bez změny obsahu zprávy: text, přílohy, původní hlavičky - vše zůstává nedotčeno. Každý opravený e-mail je individuálně ověřen před potvrzením operace.

Pro migrace z cPanel konkrétně engine rozpoznává typické signatury migrací Dovecot-na-IMAP a skriptů imapsync, včetně běžných variant konfigurací u francouzských a evropských sdílených hostingů.

Konkrétní návody podle cílové platformy

Podle cílové platformy vaší migrace z cPanel popisují následující průvodci přesné kroky:

Migrovali jste z cPanel a uživatelé vidí nesprávná data? Spusťte bezplatný sken na Redate.io a zjistěte přesně, kolik e-mailů je postiženo, bez jakýchkoli změn bez Vašeho souhlasu.

Chybná data e-mailů po migraci cPanel / Roundcube