Selitev cPanel: napačni datumi e-pošte

Ponedeljkovo jutro, ki zaboli

Pravkar ste zaključili selitev iz skupnega gostovanja cPanel v Google Workspace ali Microsoft 365. Vse je šlo gladko, nabiralne škatle so dostopne, uporabniki se prijavljajo. Nato, okoli 9:15, prispe prva zahteva za pomoč: "Vsi moji stari e-poštni sporočili prikazujejo isti datum, tistega od minulega vikenda." Potem druga. Potem deset.

To ni osamljena napaka. To je neposredna posledica načina, kako selitve iz cPanel obravnavajo (ali bolje rečeno, ne obravnavajo) metapodatke datumov e-pošte.

cPanel, Roundcube, Horde: posebno okolje IMAP

Skupno gostovanje cPanel je Linux strežnik, ki poganja strežnik IMAP (ponavadi Dovecot) z Roundcube ali Horde kot vmesnikom za spletno pošto. Nič nenavadnega. Toda to okolje ima nekaj posebnosti, ki naredijo selitve na poslovne platforme bolj zahtevne, kot se zdi na prvi pogled.

Najprej, nabiralne škatle cPanel pogosto kopičijo e-pošto leta, včasih celo desetletje. Stranka, ki je imela domeno pri skupnem gostovanju od leta 2013, ima lahko zelo globoke arhive. Ta obseg, skupaj z načinom izvedbe selitve, ustvarja idealne pogoje za težavo z datumi.

Nato so tu orodja, ki se pogosto uporabljajo za te selitve: bodisi vgrajeno orodje cPanel ("Migrations" v WHM), bodisi imapsync, zagnan iz ukazne vrstice s strani gostitelja ali IT izvajalca, bodisi rešitve za širšo javnost, kot je GSMMO za selitev v Google Workspace.

Zakaj so datumi po selitvi cPanel pokvarjeni

Da razumemo težavo, moramo poznati dva ločena koncepta: glavo Date: e-poštnega sporočila in INTERNALDATE IMAP.

Glava Date: je zapisana v surovo vsebino sporočila ob pošiljanju, v skladu z RFC 2822. Pove, kdaj je bilo e-poštno sporočilo sestavljeno in poslano. Ta glava se nikoli ne spremeni, razen pri namernem poseganju v sporočilo.

INTERNALDATE pa je metapodatek, ki ga strežnik IMAP poveže z vsakim shranjenim sporočilom. Ločen je od vsebine sporočila. Ko e-poštno sporočilo normalno prispe na strežnik, se INTERNALDATE nastavi na podlagi glav Received: sporočila, oziroma na datum sprejema, če je sporočilo oddano neposredno. To vrednost Outlook, Thunderbird in večina odjemalcev e-pošte uporabljajo za razvrščanje sporočil.

Med selitvijo IMAP se sporočila kopirajo z enega strežnika na drugega. Težava je, da mora orodje za selitev ustvariti vsako sporočilo na ciljnem strežniku. In pri večini orodij je INTERNALDATE novo ustvarjenega sporočila nastavljen na datum selitve, ne na izvirni datum sporočila. Poleg tega se glava Received: z žigom časa selitve doda na vrh verige glav, kar dodatno zmede odjemalce e-pošte, ki se nanjo sklicujejo pri izračunu prikazanega datuma.

Rezultat: e-poštno sporočilo iz leta 2019 prispe v Google Workspace z INTERNALDATE, nastavljenim na dan selitve, in glavo Received: z včerajšnjim datumom. Outlook ga prikazuje v nabiralni škatli, kot da je pravkar prišlo. Celotna kronologija arhiva je uničena.

Orodje za selitev WHM / cPanel

Vgrajeno orodje WHM za selitev računov cPanel na drugo platformo povzroča to težavo skoraj sistematično, ko je cilj zunanji strežnik IMAP (Google Workspace, Microsoft 365). Vsebino Maildir kopira na novi strežnik prek IMAP APPEND brez ohranitve izvirnega INTERNALDATE. Vsako sporočilo tako dobi časovni žig trenutka operacije.

imapsync in ročne selitve iz cPanel

imapsync je zmogljivo orodje, toda njegovo privzeto obnašanje ne ohrani vedno datumov. Brez pravih parametrov (in prave različice) lahko brez težav kopira 40.000 sporočil in jim vsem dodeli datum izvajanja skripta. (Mimogrede, če ste kdaj prebrskal dnevnike imapsync vrstico po vrstico, da bi diagnosticirali težavo z datumi na nabiralni škatli s 25.000 sporočili, veste, da gre za izkušnjo, ki je ne iščete ponoviti.)

Da bomo natančni, imapsync ima možnosti za poskus ohranitve datuma, a te možnosti se različno obnašajo glede na izvorne in ciljne strežnike, in njihova učinkovitost ni zagotovljena pri vseh konfiguracijah cPanel / Dovecot.

GSMMO in orodja za širšo javnost

Google Workspace Migration for Microsoft Outlook (GSMMO) je zasnovan za selitev iz Outlooka, ne iz golega strežnika IMAP. Ko se uporablja za selitev iz cPanel (prek računa IMAP, konfiguriranega v Outlooku), datumi doživijo enako usodo: INTERNALDATE v Google Workspace je nastavljen na datum selitve. Težava GSMMO z datumi e-pošte je sicer dokumentirana ločeno, toliko je razširjena.

Kateri odjemalci e-pošte so prizadeti?

Poškodba datumov se ne kaže enako pri vsakem odjemalcu.

Outlook je najbolj prizadet odjemalec. Uporablja INTERNALDATE (ali glavo Received: iz selitve) kot glavno merilo razvrščanja za mape. Po slabo izvedeni selitvi cPanel lahko nabiralna škatla v Outlooku prikazuje tisoče arhiviranih e-poštnih sporočil z datumom vikenda selitve.

Gmail (Google Workspace) ponavadi prikazuje datum iz glave Date: na seznamu e-pošte, toda razvrščanje je vseeno lahko prizadeto z INTERNALDATE, odvisno od primera. Uporabniki poročajo o nepredvidljivem obnašanju pri iskanju in razvrščanju po datumu.

Apple Mail in Thunderbird imata bolj niansirana vedenja, toda nobeden od njiju ni imun na težavo, zlasti ko je glava Received: iz selitve prisotna na vrhu verige.

Dobra novica: izvirni datum je vedno tam

To je tehnična podrobnost, ki vse spremeni. Izvirna glava Date: sporočila je zapisana v surovo vsebino e-pošte. Selitev je ne dotakne. Ko odprete prizadeto e-poštno sporočilo in si ogledate surove glave (v Gmailu: "Prikaži original", v Outlooku: Datoteka > Lastnosti), vidite neokrnjeni izvirni Date:, ki mu sledijo ena ali več glav Received:, od katerih prva nosi datum selitve.

Ta informacija je vedno prisotna. Izkoristiti jo je mogoče za popravek metapodatkov. Natanko to počne korekcijski mehanizem Redate.io.

Zakaj je "sam popraviti" bolj tvegano, kot se zdi

Skušnjava je velika. Težava se zdi preprosta: preberi izvirni datum, popravi metapodatke, nadaljuj. A med razumevanjem mehanizma in popravljanjem 12.000 e-poštnih sporočil v produkciji brez izgube enega samega je precejšnja razlika.

Nekaj realnosti, ki jih domači skripti praviloma ne predvidijo:

Sporočila, podpisana z S/MIME ali šifrirana s PGP: vsaka sprememba strukture sporočila razveljavi kriptografski podpis. E-poštno sporočilo, ki je prestalo preverjanje podpisa pred popravkom, tega morda ne bo po njem. Uporabniki v regulatornem okolju (odvetniške pisarne, finančni sektor, zdravstvo) odkrijejo to težavo v najslabšem trenutku.
Glave brez ASCII in kodiranje RFC 2047: nabiralne škatle cPanel kopičijo leta e-pošte iz najrazličnejših odjemalcev. Nekatere glave vsebujejo znake, kodirane po RFC 2047. Slabo napisan skript, ki rekonstruira glave, lahko ta kodiranja nevidno pokvari.
Ugnezdene strukture MIME: e-poštno sporočilo s tremi prilogami in alternativnim HTML telesom ima kompleksno strukturo multipart. Najmanjša napaka pri mejnikih MIME naredi sporočilo neberljivo, ali pa, kar je še huje, priloge izginejo brez sporočila o napaki.
Kvote API in omejevanje hitrosti: Google Workspace in Microsoft 365 vsiljujeta stroge omejitve na število operacij IMAP na minuto. Skript, ki ne implementira pravilno eksponentnega odlaganja, sproži napake 429 ob 3h zjutraj, vi pa se zbudite s selitev, ki je na pol končana in za katero ne veste točno, kje se je ustavila.
Povrnitev ni možna: če gre kaj narobe sredi procesa, v katero stanje se vrnete? So originali še tam? Imate podvojene vnose? Redate.io hrani originale v vidni varnostni kopiji 30 dni, natanko zato, da se nikoli ne znajdete v tej situaciji.

Skript, ki deluje na 50 testnih e-poštnih sporočilih v razvojnem okolju, ne bo nujno deloval na 18.000 sporočilih produkcijske nabiralne škatle, podedovane iz gostovanja cPanel od leta 2011.

Kako Redate.io popravi datume po selitvi cPanel

Redate.io se poveže neposredno na ciljno nabiralno škatlo (Google Workspace prek domenskega pooblastila, Microsoft 365 prek Azure AD, ali neposredni strežnik IMAP) in začne z brezplačnim skeniranjem za identifikacijo e-poštnih sporočil, katerih metapodatki datuma so neskladni z izvirno glavo Date:.

Večstopenjski analitični cevovod nato izvede ujemanje vzorcev na podpisih glav Received:, da prepozna tiste, ki so jih vnesla orodja za selitev (in jih loči od zakonitih glav). Ciljni popravek metapodatkov se izvede brez spremembe vsebine sporočila: besedilo, priloge, izvirne glave, vse ostane nedotaknjeno. Vsako popravljeno e-poštno sporočilo je preverjeno posamično, preden je operacija potrjena.

Za selitve iz cPanel posebej korekcijski mehanizem prepozna tipične podpise selitev Dovecot-v-IMAP in skriptov imapsync, vključno s pogostimi različicami konfiguracije pri skupnih gostiteljih.

Specifični vodniki glede na vašo ciljno platformo

Glede na ciljno platformo vaše selitve cPanel opisujejo naslednji vodniki natančne korake:

Ste opravili selitev iz cPanel in vaši uporabniki vidijo napačne datume? Zaženite brezplačno skeniranje na Redate.io in ugotovite točno, koliko e-poštnih sporočil je prizadetih, brez kakršnih koli sprememb pred vašim soglasjem.

Napačni datumi e-pošte po selitvi cPanel