cPanel migrācija: bojāti datumi

Pirmdienas rīts, kas sāp

Jūs tikko pabeidzāt migrāciju no koplietojamā cPanel hostinga uz Google Workspace vai Microsoft 365. Viss noritēja gludi, pastkastes ir pieejamas, lietotāji pieslēdzas. Tad ap pulksten 9:15 ienāk pirmais pieprasījums: "Mani vecie e-pasti visi rāda vienu un to pašu datumu - pagājušā nedēļas nogale." Tad otrs. Tad desmit.

Tā nav atsevišķa kļūda. Tā ir tieša sekas tam, kā cPanel migrācijas rīki apstrādā (precīzāk - neapstrādā) e-pastu datumu metadatus.

cPanel, Roundcube, Horde: īpašs IMAP konteksts

cPanel koplietojamais hosting nozīmē Linux serveri, uz kura darbojas IMAP serveris (parasti Dovecot) ar Roundcube vai Horde kā webmail saskarni. Nav nekā eksotiska. Taču šim kontekstam ir dažas īpatnības, kuras padara migrāciju uz enterprise platformām sarežģītāku, nekā šķiet.

Pirmkārt, cPanel pastkastes bieži uzkrāj e-pastus gadiem ilgi, dažkārt veselu desmitgadi. Klients, kurš mitinājis savu domēnu pie koplietojamā hostinga kopš 2013. gada, var būt uzkrājis ļoti dziļus arhīvus. Šis apjoms kombinācijā ar migrācijas metodi rada labvēlīgu augsni datumu problēmai.

Otrkārt, šīm migrācijām izmantotie rīki parasti ir vai nu WHM iebūvētais migrācijas rīks, vai imapsync, ko palaiž komandrindā hosteris vai IT pakalpojumu sniedzējs, vai arī tādi patērētāju risinājumi kā GSMMO migrācijai uz Google Workspace.

Kāpēc datumi tiek bojāti pēc cPanel migrācijas

Lai saprastu problēmu, jānošķir divi atsevišķi jēdzieni: e-pasta galvene Date: un IMAP INTERNALDATE.

Galvene Date: tiek ierakstīta ziņojuma neapstrādātajā saturā brīdī, kad tas tiek nosūtīts, saskaņā ar RFC 2822. Tā norāda, kad e-pasts tika sastādīts un nosūtīts. Šī galvene nekad nemainās, ja vien ziņojums netiek apzināti modificēts.

INTERNALDATE savukārt ir metadatu vērtība, ko IMAP serveris asociē ar katru saglabāto ziņojumu. Tā ir atdalīta no ziņojuma satura. Kad e-pasts ierodoties normāli nonāk serverī, INTERNALDATE tiek noteikts pēc ziņojuma Received: galvenēm vai iesniegšanas datuma. Tieši šo vērtību Outlook, Thunderbird un lielākā daļa e-pasta klientu izmanto ziņojumu kārtošanai.

IMAP migrācijas laikā ziņojumi tiek kopēti no viena servera uz otru. Problēma: migrācijas rīkam ir jāizveido katrs ziņojums galamērķa serverī. Un daudziem rīkiem jaunizveidotā ziņojuma INTERNALDATE atbilst migrācijas datumam, nevis ziņojuma oriģinālajam datumam. Vienlaikus galvenes virknes augšgalā tiek pievienota ar migrācijas datumu iezīmēta Received: galvene, kas vēl vairāk maldina e-pasta klientus, kuri to izmanto, aprēķinot attēlojamo datumu.

Rezultāts: 2019. gadā sūtīts e-pasts nonāk Google Workspace ar INTERNALDATE, kas iestatīts uz migrācijas dienu, un Received: galveni ar vakardienas datumu. Outlook iesūtnē to parāda tā, it kā tas būtu tikko saņemts. Viss arhīva hronoloģiskais kārtojums ir iznīcināts.

WHM / cPanel migrācijas rīks

WHM iebūvētais rīks cPanel kontu migrācijai uz citu platformu šo problēmu rada gandrīz sistemātiski, kad galamērķis ir ārējs IMAP serveris (Google Workspace, Microsoft 365). Tas kopē Maildir saturu uz jauno serveri, nesamglabājot oriģinālo INTERNALDATE. Rezultātā katrs ziņojums saņem operācijas brīža laikspiedolu.

imapsync un manuālās migrācijas no cPanel

imapsync ir jaudīgs rīks, taču tā noklusētā uzvedība ne vienmēr saglabā datumus. Bez pareiziem parametriem (un pareizas versijas) tas var ļoti labi nokopēt 40 000 ziņojumus, piešķirot tiem visiem skripta izpildes datumu. (Starp citu, ja jūs kādreiz esat skatījuši imapsync žurnālfailus rindā pēc rindas, diagnosticējot datumu problēmu pastkastē ar 25 000 ziņojumiem, jūs zināt, ka tā ir pieredze, ko nevēlas atkārtot.)

Precīzāk sakot, imapsync ir opcijas datuma saglabāšanas mēģinājumam, taču šīs opcijas dažādi mijiedarbojas atkarībā no avota un galamērķa servera, un to efektivitāte nav garantēta visās cPanel / Dovecot konfigurācijās.

GSMMO un patērētāju rīki

Google Workspace Migration for Microsoft Outlook (GSMMO) ir paredzēts migrācijai no Outlook, nevis no tīra IMAP servera. Kad to izmanto migrācijai no cPanel (izmantojot Outlook konfigurētu IMAP kontu), datumi cieš to pašu: INTERNALDATE Google Workspace tiek iestatīts uz migrācijas datumu. GSMMO un e-pastu datumu problēma ir dokumentēta atsevišķi, jo tā ir ļoti izplatīta.

Kuri e-pasta klienti ir ietekmēti?

Datumu bojājumi neizpaužas vienādi atkarībā no izmantotā klienta.

Outlook ir visvairāk ietekmētais klients. Tas izmanto INTERNALDATE (vai migrācijas Received: galveni) kā galveno kārtošanas kritēriju mapēs. Pēc slikti veiktas cPanel migrācijas pastkaste Outlook varētu rādīt tūkstošiem arhivētu e-pastu ar migrācijas nedēļas nogales datumu. imapsync datumu labošana Outlook ir viena no biežāk pieprasītajām korekcijām.

Gmail (Google Workspace) parasti parāda datumu no Date: galvenes e-pastu sarakstā, taču kārtošanu tāpat var ietekmēt INTERNALDATE noteiktos gadījumos. Lietotāji ziņo par neregulāru uzvedību meklēšanā un kārtošanā pēc datuma.

Apple Mail un Thunderbird uzvedas niansētāk, taču neviens no tiem nav pasargāts no problēmas, īpaši kad migrācijas Received: galvene atrodas ķēdes sākumā.

Labā ziņa: oriģinālais datums ir neskarts

Šī ir tehniskā detaļa, kas maina visu. Ziņojuma oriģinālā Date: galvene ir ierakstīta e-pasta neapstrādātajā saturā. Migrācija to neskar. Kad atverat ietekmētu e-pastu un aplūkojat neapstrādātās galvenes (Gmail: "Rādīt oriģinālu", Outlook: Fails > Rekvizīti), redzat neskarto oriģinālo Date:, kam seko viena vai vairākas Received: galvenes, no kurām pirmā nes migrācijas datumu.

Šī informācija vienmēr ir klāt. To var izmantot metadatu labošanai. Tieši to dara Redate.io labošanas dzinējs.

Kāpēc "labot pašam" ir riskantāk, nekā šķiet

Kārdinājums ir liels. Problēma šķiet vienkārša: nolasīt oriģinālo datumu, izlabot metadatus, turpināt ar nākamo. Taču starp mehānisma izprašanu un 12 000 e-pastu labošanu ražošanas vidē, nezaudējot nevienu, ir ievērojama plaisa.

Dažas realitātes, ko mājas skripti parasti neņem vērā:

S/MIME parakstīti vai PGP šifrēti e-pasti: jebkura ziņojuma struktūras modifikācija padara kriptogrāfisko parakstu nederīgu. E-pasts, kas pirms labošanas nokārtoja paraksta pārbaudi, to nenokārtos pēc. Lietotāji ar normatīvo atbilstību (advokātu biroji, finanšu sektors, veselības aprūpe) šo problēmu atklāj visnepiemērotākajā brīdī.
Ne-ASCII galvenes un RFC 2047 kodējums: cPanel pastkastes gadiem uzkrāj e-pastus no ļoti dažādiem e-pasta klientiem. Dažas galvenes satur RFC 2047 kodētus rakstzīmes. Nepareizi uzrakstīts skripts, kas atjauno galvenes, var šos kodējumus sabojāt neredzami.
Ligzdotas MIME struktūras: e-pastam ar trim pielikumiem un alternatīvu HTML pamattekstu ir sarežģīta multipart struktūra. Mazākā kļūda MIME robežās padara ziņojumu nelasāmu vai, vēl sliktāk, pielikumi pazūd bez kļūdas ziņojuma.
API kvota un ātruma ierobežošana: Google Workspace un Microsoft 365 uzliek stingrus ierobežojumus IMAP operāciju skaitam minūtē. Skripts, kas nepareizi implementē eksponenciālo atkāpšanos, no rīta pulksten 3 izraisa 429 kļūdas, un jūs pamostaties ar puspabeigtu migrāciju, kur nav skaidrs, kur tā apstājusies.
Atcelšana nav iespējama: ja kaut kas noiet greizi pusceļā, kādā stāvoklī atgriežaties? Vai oriģināli vēl ir klāt? Vai jums ir dublikāti? Redate.io saglabā oriģināļus redzamā rezerves mapē 30 dienas, tieši lai nekad nenonāktu šādā situācijā.

Skripts, kas darbojas uz 50 testa e-pastiem izstrādes vidē, ne vienmēr darbosies uz 18 000 ziņojumiem ražošanas pastkastē, kas mantota no cPanel hostinga kopš 2011. gada.

Kā Redate.io labo datumus pēc cPanel migrācijas

Redate.io savienojas tieši ar galamērķa pastkasti (Google Workspace ar domēna deleģēšanu, Microsoft 365 ar Azure AD, vai tiešu IMAP serveri) un sāk ar bezmaksas skenēšanu, lai identificētu e-pastus, kuru datumu metadati neatbilst oriģinālajai Date: galvenei.

Daudzpakāpju analīzes konveijers pēc tam veic atbilstību meklēšanu pret Received: galvenes parakstiem, lai identificētu tos, ko ieviesuši migrācijas rīki (un atšķirtu tos no likumīgām galvenēm). Mērķtiecīga metadatu korekcija tiek veikta, nemainot ziņojuma saturu: teksts, pielikumi, oriģinālās galvenes - viss paliek neskarts. Katrs izlabotais e-pasts tiek individuāli pārbaudīts, pirms operācija tiek apstiprināta.

Migrācijām no cPanel specifika: dzinējs atpazīst tipiskos Dovecot-uz-IMAP migrāciju un imapsync skriptu parakstus, tostarp izplatītos konfigurāciju variantus Eiropas koplietojamo hostingu sniedzēju vidū.

Specifiski ceļveži atkarībā no galamērķa

Atkarībā no jūsu cPanel migrācijas galamērķa platformas, šie ceļveži apraksta konkrētas darbības:

Migrējāt no cPanel un lietotāji redz nepareizus datumus? Palaidiet bezmaksas skenēšanu Redate.io, lai noskaidrotu precīzu ietekmēto e-pastu skaitu bez jebkādām izmaiņām pirms jūsu apstiprinājuma.

Nepareizi e-pastu datumi pēc cPanel migrācijas