Nesprávne dátumy emailov po migrácii cPanel / Roundcube

Pondelkové ráno, ktoré bolí

Práve ste dokončili migráciu zo zdieľaného hostingu cPanel do Google Workspace alebo Microsoft 365. Všetko prebehlo hladko, schránky sú dostupné, používatelia sa prihlasujú. Potom, okolo 9:15, príde prvý tiket: "Všetky staré emaily majú rovnaký dátum, ten z minulého víkendu." Potom druhý. Potom desať.

Nie je to izolovaná chyba. Je to priamy dôsledok toho, ako migračné nástroje z cPanel narábajú (alebo skôr nenarábajú) s metadátami dátumov emailov.

cPanel, Roundcube, Horde: špecifický IMAP kontext

Zdieľaný hosting cPanel je linuxový server s IMAP serverom (väčšinou Dovecot) a rozhraním Roundcube alebo Horde. Nič exotické. Ale tento kontext má niekoľko zvláštností, ktoré robia migrácie na enterprise platformy komplikovanejšími, ako sa zdá.

Po prvé, schránky cPanel zvyknú obsahovať emaily z mnohých rokov, niekedy celej dekády. Klient, ktorý mal doménu na zdieľanom hostingu od roku 2013, môže mať veľmi hlboké archívy. Tento objem v kombinácii so spôsobom, akým sa migrácia vykonáva, vytvára ideálne podmienky pre problém s dátumami.

Po druhé, nástroje používané na tieto migrácie sú väčšinou buď natívny nástroj cPanel ("Migrations" vo WHM), alebo imapsync spustený z príkazového riadku hostiteľom či IT dodávateľom, alebo riešenia pre širokú verejnosť ako GSMMO pri migrácii do Google Workspace.

Prečo sú dátumy po migrácii z cPanel poškodené

Na pochopenie problému treba rozlíšiť dva odlišné pojmy: hlavičku Date: emailu a INTERNALDATE IMAP.

Hlavička Date: je zapísaná do surového obsahu správy v momente odoslania, v súlade s RFC 2822. Udáva, kedy bol email napísaný a odoslaný. Táto hlavička sa nikdy nemení, pokiaľ správu niekto úmyselne nemodifikuje.

INTERNALDATE je metadátum, ktoré IMAP server priradí každej uloženej správe. Je oddelené od obsahu správy. Keď email dorazí na server bežným spôsobom, INTERNALDATE sa nastaví podľa hlavičiek Received: správy, prípadne podľa dátumu uloženia. Práve túto hodnotu používajú Outlook, Thunderbird a väčšina emailových klientov na triedenie správ.

Pri IMAP migrácii sa správy kopírujú z jedného servera na druhý. Problém: migračný nástroj musí každú správu vytvoriť na cieľovom serveri. A pri mnohých nástrojoch zodpovedá INTERNALDATE novonahrané správy dátumu migrácie, nie pôvodnému dátumu správy. Zároveň sa na začiatok reťazca hlavičiek pridá hlavička Received: s časovou pečiatkou dátumu migrácie, čo ešte viac mätie emailové klienty, ktoré sa na ňu odvolávajú pri určovaní zobrazovaného dátumu.

Výsledok: email z roku 2019 dorazí do Google Workspace s INTERNALDATE nastaveným na deň migrácie a hlavičkou Received: s včerajším dátumom. Outlook ho zobrazí v doručenej pošte, akoby práve prišiel. Celá chronológia archivácie je zničená.

Migračný nástroj WHM / cPanel

Nástroj integrovaný vo WHM na migráciu cPanel účtov na inú platformu generuje tento problém takmer systematicky, keď je cieľom externý IMAP server (Google Workspace, Microsoft 365). Kopíruje obsah Maildir adresárov na nový server cez IMAP APPEND bez zachovania pôvodného INTERNALDATE. Každá správa tak dostane časovú pečiatku momentu operácie.

imapsync a manuálne migrácie z cPanel

imapsync je výkonný nástroj, ale jeho predvolené správanie nezachováva dátumy vždy správne. Bez správnych parametrov (a správnej verzie) môže pokojne skopírovať 40 000 správ a všetkým nastaviť dátum spustenia skriptu. (Mimochodom, ak ste niekedy prechádzali logy imapsync riadok po riadku pri diagnostike problému s dátumami v schránke s 25 000 správami, viete, že to je zážitok, ktorý nechcete zopakovať.)

Aby som bol presný: imapsync má voľby na pokus o zachovanie dátumu, ale tieto voľby sa správajú rôzne podľa zdrojového a cieľového servera a ich účinnosť nie je zaručená pri všetkých konfiguráciách cPanel / Dovecot.

GSMMO a nástroje pre širokú verejnosť

Google Workspace Migration for Microsoft Outlook (GSMMO) je určený na migráciu z Outlooku, nie zo surového IMAP servera. Keď sa použije na migráciu z cPanel (cez IMAP účet nakonfigurovaný v Outlooku), dátumy podstúpia rovnaké zaobchádzanie: INTERNALDATE v Google Workspace sa nastaví na dátum migrácie. Problém GSMMO s dátumami emailov je dokumentovaný samostatne, natoľko je rozšírený.

Ktoré emailové klienty sú postihnuté?

Poškodenie dátumov sa neprejavuje rovnako vo všetkých klientoch.

Outlook je najviac postihnutý klient. Používa INTERNALDATE (alebo hlavičku Received: z migrácie) ako hlavné kritérium triedenia priečinkov. Po zle zvládnutej migrácii z cPanel môže schránka v Outlooku zobrazovať tisíce archivovaných emailov s dátumom migračného víkendu. Oprava dátumov imapsync v Outlooku je jednou z najžiadanejších opráv.

Gmail (Google Workspace) zvyčajne zobrazuje dátum z hlavičky Date: v zozname emailov, ale triedenie môže byť aj tak ovplyvnené INTERNALDATE v niektorých prípadoch. Používatelia hlásia nepredvídateľné správanie pri vyhľadávaní a triedení podľa dátumu.

Apple Mail a Thunderbird majú nuansovanejšie správanie, ale ani jeden nie je imúnny voči problému, najmä keď je migračná hlavička Received: prítomná na začiatku reťazca.

Dobrá správa: pôvodný dátum je stále tam

To je technický detail, ktorý mení všetko. Pôvodná hlavička Date: správy je zapísaná v surovom obsahu emailu. Migrácia sa jej nedotkne. Keď otvoríte postihnutý email a pozriete sa na surové hlavičky (v Gmaile: "Zobraziť originál", v Outlooku: Súbor > Vlastnosti), uvidíte pôvodný Date: neporušený, za ktorým nasleduje jedna alebo viac hlavičiek Received:, pričom prvá nesie dátum migrácie.

Táto informácia je vždy prítomná. Dá sa využiť na opravu metadát. Presne to robí opravný engine Redate.io.

Prečo je "oprava vlastnými silami" rizikovejšia, ako sa zdá

Pokušenie je silné. Problém vyzerá jednoducho: prečítaj pôvodný dátum, oprav metadáta, pokračuj ďalej. Ale medzi pochopením mechanizmu a opravou 12 000 emailov v produkcii bez straty jediného je priepastný rozdiel.

Niekoľko reálnych situácií, na ktoré domáce skripty väčšinou nepomyslia:

• S/MIME podpísané alebo PGP šifrované emaily: akákoľvek úprava štruktúry správy zneplatní kryptografický podpis. Email, ktorý pred opravou prechádzal overením podpisu, po nej neprejde. Používatelia, na ktorých sa vzťahujú regulačné požiadavky (advokátske kancelárie, finančný sektor, zdravotníctvo), objavia tento problém v najhoršom možnom momente.
• Non-ASCII hlavičky a kódovanie RFC 2047: schránky cPanel hromadia roky emailov z rozličných emailových klientov. Niektoré hlavičky obsahujú znaky kódované podľa RFC 2047. Zle napísaný skript, ktorý rekonštruuje hlavičky, môže tieto kódovania neviditeľne poškodiť.
• Vnorené MIME štruktúry: email s troma prílohami a alternatívnym HTML telom má komplexnú multipart štruktúru. Najmenšia chyba v MIME hraniciach spôsobí, že správa bude nečitateľná, alebo horšie: prílohy zmiznú bez chybového hlásenia.
• API kvóty a rate limiting: Google Workspace a Microsoft 365 ukladajú prísne limity na počet IMAP operácií za minútu. Skript, ktorý správne neimplementuje exponenciálny backoff, vyvolá chyby 429 o 3:00 v noci a zobudíte sa s napoly dokončenou opravou, o ktorej presne neviete, kde sa zastavila.
• Rollback nie je možný: ak sa niečo pokazí v polovici, do akého stavu sa vrátite? Sú originály stále dostupné? Máte duplikáty? Redate.io uchováva originály vo viditeľnom záložnom priečinku po dobu 30 dní, práve preto, aby ste sa nikdy nedostali do tejto situácie.

Skript, ktorý funguje na 50 testovacích emailoch vo vývojovom prostredí, nebude nutne fungovať na 18 000 správach produkčnej schránky zdedenej z cPanel hostingu od roku 2011.

Ako Redate.io opravuje dátumy po migrácii cPanel

Redate.io sa pripojí priamo k cieľovej schránke (Google Workspace cez delegovanie domény, Microsoft 365 cez Azure AD, alebo priamy IMAP server) a začne bezplatným skanom na identifikáciu emailov, ktorých metadáta dátumu sú v rozpore s pôvodnou hlavičkou Date:.

Viacstupňový analytický pipeline následne aplikuje porovnávanie vzorov na signatúry hlavičiek Received:, aby identifikoval tie, ktoré zaviedli migračné nástroje (a odlíšil ich od legitímnych hlavičiek). Cielená oprava metadát prebieha bez zmeny obsahu správy: text, prílohy, pôvodné hlavičky, všetko zostáva neporušené. Každý opravený email je pred potvrdením operácie individuálne overený.

Pre migrácie z cPanel konkrétne engine rozpoznáva typické signatúry migrácií Dovecot-na-IMAP a imapsync skriptov, vrátane bežných konfiguračných variácií u európskych zdieľaných hostiteľov.

Špecifické návody podľa cieľovej platformy

V závislosti od cieľovej platformy vašej migrácie z cPanel opisujú nasledujúce návody presné kroky:

• Oprava dátumov migrácie imapsync v Gmaile
• Oprava dátumov migrácie imapsync v Microsoft 365
• Oprava dátumov migrácie imapsync v Google Workspace
• Dátumy emailov po migrácii do Google Workspace
• Dátumy emailov po migrácii do Microsoft 365

Migrovali ste z cPanel a vaši používatelia vidia nesprávne dátumy? Spustite bezplatný sken na Redate.io a zistite presne, koľko emailov je postihnutých, bez akýchkoľvek úprav pred vaším súhlasom.