Migrare cPanel: emailuri cu date greșite

Luni dimineața care doare

Tocmai ați finalizat migrarea unui hosting shared cPanel spre Google Workspace sau Microsoft 365. Totul a mers bine, căsuțele sunt accesibile, utilizatorii se conectează. Apoi, pe la 9:15, cade primul tichet: "Emailurile mele vechi afișează toate aceeași dată, cea de weekendul trecut." Apoi al doilea. Apoi zece.

Nu e un bug izolat. E consecința directă a modului în care migrările de la cPanel tratează (sau mai degrabă nu tratează) metadatele de dată ale emailurilor.

cPanel, Roundcube, Horde: un context IMAP particular

Un hosting shared cPanel înseamnă un server Linux care rulează un server IMAP (de obicei Dovecot) cu Roundcube sau Horde ca interfață webmail. Nimic exotic. Dar acest context are câteva particularități care fac migrările spre platforme enterprise mai delicate decât par.

În primul rând, căsuțele cPanel acumulează adesea emailuri pe parcursul mai multor ani, uneori un deceniu. Un client care și-a găzduit domeniul la un hosting shared din 2013 poate avea arhive foarte adânci. Acest volum, combinat cu modul în care se realizează migrarea, creează un teren fertil pentru problema datelor.

Apoi, instrumentele folosite pentru aceste migrări sunt fie instrumentul nativ cPanel ("Migrations" din WHM), fie imapsync lansat în linie de comandă de către furnizorul de hosting sau prestatorul IT, fie soluții de larg consum precum GSMMO pentru migrarea spre Google Workspace.

De ce datele sunt corupte după o migrare cPanel

Pentru a înțelege problema, trebuie să asimilați două concepte distincte: antetul Date: al unui email și INTERNALDATE-ul IMAP.

Antetul Date: este înscris în corpul brut al mesajului la momentul trimiterii, conform RFC 2822. El indică când a fost redactat și trimis emailul. Acest antet nu se schimbă niciodată, cu excepția manipulărilor voluntare ale mesajului.

INTERNALDATE-ul, în schimb, este o metadată pe care serverul IMAP o asociază fiecărui mesaj stocat. El este distinct de conținutul mesajului. Când un email ajunge normal pe un server, INTERNALDATE-ul este definit pe baza antetelor Received: ale mesajului, sau la data depunerii dacă mesajul este trimis direct. Această valoare este cea pe care Outlook, Thunderbird și majoritatea clienților de email o folosesc pentru sortarea mesajelor.

La o migrare IMAP, mesajele sunt copiate de pe un server pe altul. Problema: instrumentul de migrare trebuie să creeze fiecare mesaj pe serverul de destinație. Și pentru multe instrumente, INTERNALDATE-ul mesajului nou creat corespunde datei migrării, nu datei originale a mesajului. În paralel, un antet Received: marcat cu data migrării este adăugat în fruntea lanțului de antete, ceea ce perturbă și mai mult clienții de email care se referă la el pentru a calcula data afișată.

Rezultat: un email din 2019 ajunge în Google Workspace cu un INTERNALDATE fixat la ziua migrării, și un antet Received: ștampilat ieri. Outlook îl afișează în inbox ca și cum tocmai ar fi sosit. Toată cronologia arhivei este distrusă.

Instrumentul de migrare WHM / cPanel

Instrumentul integrat în WHM pentru migrarea conturilor cPanel spre altă platformă generează această problemă aproape sistematic când destinația este un server IMAP extern (Google Workspace, Microsoft 365). Copiază conținutul directoarelor Maildir pe noul server via IMAP fără a păstra INTERNALDATE-ul original. Fiecare mesaj primește astfel marcajul temporal al momentului operației.

imapsync și migrările manuale din cPanel

imapsync este un instrument puternic, dar comportamentul său implicit nu păstrează întotdeauna datele. Fără parametrii corecți (și versiunea potrivită), poate copia 40.000 de mesaje atribuindu-le tuturor data execuției scriptului. (De altfel, dacă ați parcurs vreodată log-urile imapsync linie cu linie pentru a diagnostica o problemă de date pe o căsuță de 25.000 de mesaje, știți că e o experiență pe care nu o căutați să o repetați.)

Ca să fiu precis, imapsync dispune de opțiuni pentru a încerca să păstreze data, dar aceste opțiuni interacționează diferit în funcție de serverele sursă și destinație, iar eficacitatea lor nu este garantată pe toate configurațiile cPanel / Dovecot.

GSMMO și instrumentele de larg consum

Google Workspace Migration for Microsoft Outlook (GSMMO) este conceput pentru a migra din Outlook, nu dintr-un server IMAP simplu. Când este folosit pentru a migra din cPanel (via un cont IMAP configurat în Outlook), datele suferă același tratament: INTERNALDATE-ul pe Google Workspace este fixat la data migrării. Problema GSMMO și datele emailurilor este documentată separat, atât de des întâlnită este.

Ce clienți de email sunt afectați?

Coruperea datelor nu se manifestă la fel în funcție de clientul folosit.

Outlook este clientul cel mai afectat. Folosește INTERNALDATE-ul (sau antetul Received: de migrare) ca și criteriu principal de sortare pentru dosare. După o migrare cPanel gestionată defectuos, o căsuță în Outlook poate afișa mii de emailuri arhivate cu data weekendului de migrare. Corectarea datelor imapsync în Outlook este una dintre cele mai solicitate corecții.

Gmail (Google Workspace) afișează în general data din antetul Date: în lista de emailuri, dar sortarea poate fi totuși afectată de INTERNALDATE în anumite cazuri. Utilizatorii raportează comportamente erratice la căutare și sortare după dată.

Apple Mail și Thunderbird au comportamente mai nuanțate, dar niciunul nu este imun la problemă, mai ales când antetul Received: de migrare este prezent în fruntea lanțului.

Veste bună: data originală este încă acolo

Acesta e detaliul tehnic care schimbă totul. Antetul Date: original al mesajului este înscris în corpul brut al emailului. Migrarea nu îl atinge. Când deschideți un email afectat și priviți antetele brute (în Gmail: "Afișați originalul", în Outlook: Fișier > Proprietăți), vedeți Date:-ul original intact, urmat de unul sau mai multe antete Received: dintre care primul poartă data migrării.

Această informație este mereu prezentă. Poate fi exploatată pentru a corecta metadatele. Exact asta face motorul de corecție al Redate.io.

De ce "a corecta singur" e mai riscant decât pare

Tentația e mare. Problema pare simplă: citești data originală, corectezi metadatele, treci la următorul. Dar între a înțelege mecanismul și a corecta 12.000 de emailuri în producție fără a pierde niciunul, există o diferență considerabilă.

Câteva realități pe care scripturile improvizate nu le anticipează de obicei:

Emailuri semnate S/MIME sau criptate PGP: orice modificare a structurii mesajului invalidează semnătura criptografică. Un email care trecea verificarea de semnătură înainte de corecție nu o mai trece după. Utilizatorii cu cerințe de conformitate (cabinete de avocatură, sector financiar, sănătate) descoperă această problemă în cel mai prost moment.
Antete non-ASCII și codificarea RFC 2047: căsuțele cPanel acumulează ani de emailuri provenite de la clienți de email foarte variați. Unele antete conțin caractere codificate conform RFC 2047. Un script prost scris care reconstruiește antetele poate corupe aceste codificări în mod invizibil.
Structuri MIME imbricate: un email cu trei atașamente și un corp HTML alternativ are o structură multipart complexă. Cea mai mică eroare pe granițele MIME face mesajul ilizibil sau, mai rău: atașamentele dispar fără mesaj de eroare.
Cote API și rate limiting: Google Workspace și Microsoft 365 impun limite stricte asupra numărului de operații IMAP pe minut. Un script care nu implementează corect backoff-ul exponențial declanșează erori 429 la 3 dimineața, și vă treziți cu o migrare pe jumătate terminată fără să știți exact unde s-a oprit.
Rollback imposibil: dacă ceva merge prost la mijlocul procesului, la ce stare reveniți? Originalele sunt încă acolo? Aveți duplicate? Redate.io păstrează originalele într-un dosar de backup vizibil timp de 30 de zile, tocmai pentru a nu vă afla niciodată în această situație.

Un script care funcționează pe 50 de emailuri de test într-un mediu de dev nu va funcționa neapărat pe 18.000 de mesaje dintr-o căsuță de producție moștenită de la un hosting cPanel din 2011.

Cum corectează Redate.io datele după o migrare cPanel

Redate.io se conectează direct la căsuța de destinație (Google Workspace via delegare de domeniu, Microsoft 365 via Azure AD, sau server IMAP direct) și începe cu un scan gratuit pentru a identifica emailurile ale căror metadate de dată sunt inconsistente cu antetul Date: original.

Pipeline-ul de analiză în mai multe etape aplică apoi o potrivire de tipare asupra semnăturilor antetelor Received: pentru a le identifica pe cele introduse de instrumentele de migrare (și a le distinge de antetele legitime). Corecția țintită a metadatelor se efectuează fără alterarea conținutului mesajului: textul, atașamentele, antetele originale, totul rămâne intact. Fiecare email corectat este verificat individual înainte ca operația să fie validată.

Pentru migrările din cPanel în mod specific, motorul recunoaște semnăturile tipice ale migrărilor Dovecot-spre-IMAP și ale scripturilor imapsync, inclusiv variantele de configurare frecvente la furnizorii de hosting shared din România și Europa.

Ghiduri specifice în funcție de destinația dvs.

În funcție de platforma de destinație a migrării dvs. cPanel, ghidurile de mai jos descriu pașii exacți:

Ați migrat din cPanel și utilizatorii dvs. văd date incorecte? Lansați un scan gratuit pe Redate.io pentru a identifica exact câte emailuri sunt afectate, fără nicio modificare înainte de acordul dvs.

Emailuri cu date greșite după migrare cPanel