cPanel migracija: klaidingos el. laiškų datos

Pirmadienio rytas, kuris skauda

Ką tik baigėte migraciją iš bendro hostingo cPanel į Google Workspace arba Microsoft 365. Viskas atrodė gerai: pašto dėžutės pasiekiamos, vartotojai prisijungia. Tada, apie 9:15, ateina pirmas pranešimas: „Visi mano seni laiškai rodo tą pačią datą - praėjusio savaitgalio." Po to antras. Po to dešimt.

Tai ne pavienė klaida. Tai tiesioginė pasekmė to, kaip cPanel migracijos įrankiai tvarko (o tiksliau - netvarko) el. laiškų datos metaduomenis.

cPanel, Roundcube, Horde: konkretus IMAP kontekstas

Bendro naudojimo cPanel prieglobos aplinka - tai Linux serveris, kuriame veikia IMAP serveris (paprastai Dovecot) su Roundcube arba Horde kaip webmail sąsaja. Nieko egzotiško. Bet šis kontekstas turi keletą ypatumų, dėl kurių migracijos į įmonių platformas tampa sudėtingesnės, nei atrodo iš pirmo žvilgsnio.

Visų pirma, cPanel pašto dėžutės linkusios kaupti el. laiškus metų metais, kartais dešimtmetį. Klientas, kuris savo domeną talpina bendroje prieglobos aplinkoje nuo 2013 metų, gali turėti labai gilius archyvus. Šis kiekis, kartu su tuo, kaip vykdoma migracija, sukuria derlingą dirvą datos problemai.

Be to, šioms migracijoms naudojami įrankiai dažniausiai yra vienas iš šių: gimtasis cPanel įrankis (WHM funkcija "Migrations"), imapsync, vykdomas iš komandinės eilutės prieglobos paslaugų teikėjo ar IT konsultanto, arba masinio naudojimo sprendimai, pavyzdžiui, GSMMO, migruojant į Google Workspace.

Kodėl datos tampa neteisingos po cPanel migracijos

Norint suprasti problemą, reikia suvokti dvi skirtingas sąvokas: el. laiško antraštę Date: ir IMAP INTERNALDATE.

Date: antraštė įrašoma į pradinį laiško turinį siuntimo metu, pagal RFC 2822. Ji fiksuoja, kada laiškas buvo sukurtas ir išsiųstas. Ši antraštė nesikeičia, jei kas nors sąmoningai nepakeičia laiško.

INTERNALDATE, priešingai, yra metaduomenys, kuriuos IMAP serveris priskiria kiekvienam saugomam laiškui. Jie atskiri nuo pačio laiško turinio. Kai el. laiškas pasiekia serverį normaliai, INTERNALDATE nustatoma pagal Received: antraštes arba pagal įkėlimo laiko žymą, jei laiškas pateikiamas tiesiogiai. Tai reikšmė, kurią Outlook, Thunderbird ir dauguma pašto programų naudoja laiškams rūšiuoti.

IMAP migracijos metu laiškai kopijuojami iš vieno serverio į kitą. Problema: migracijos įrankis turi sukurti kiekvieną laišką paskirties serveryje. Ir daugeliui įrankių naujai sukurto laiško INTERNALDATE nustatoma pagal migracijos datą, o ne pagal pradinio laiško datą. Be to, Received: antraštė su migracijos data pridedama į antraščių grandinę, kas dar labiau klaidina pašto programas, kurios šią antraštę naudoja rodomai datai apskaičiuoti.

Rezultatas: 2019 metų laiškas atsiduria Google Workspace su INTERNALDATE, nustatyta migracijos dienai, ir Received: antrašte, pažymėta vakar. Outlook jį rodo gautuosiuose taip, tarsi jis būtų ką tik atėjęs. Visa archyvo laiko juosta yra sugriauta.

WHM / cPanel migracijos įrankis

Į WHM įmontuotas įrankis, skirtas cPanel paskyroms migruoti į kitą platformą, šią problemą sukuria beveik sistemingai, kai paskirties vieta yra išorinis IMAP serveris (Google Workspace, Microsoft 365). Jis kopijuoja Maildir turinį į naują serverį, neišsaugodamas pradinės INTERNALDATE. Kiekvienas laiškas gauna operacijos laiko žymą.

imapsync ir rankinės migracijos iš cPanel

imapsync yra galingas įrankis, bet jo numatytasis veikimas ne visada išsaugo datas. Nenaudojant tinkamų parametrų (ir tinkamos versijos), jis gali lengvai nukopijuoti 40 000 laiškų ir kiekvienam iš jų priskirti scenarijaus vykdymo datą. (Jei kada nors teko peržiūrėti imapsync žurnalus eilutė po eilutės, diagnozuojant datos problemą 25 000 laiškų pašto dėžutėje, žinote, kad tai patirtis, kurios nenorėsite kartoti.)

Tiksliau tariant, imapsync turi parinktis, skirtas bandymui išsaugoti datas, bet šios parinktys skirtingai sąveikauja atsižvelgiant į šaltinio ir paskirties serverius, ir jų veiksmingumas nėra garantuotas visose cPanel / Dovecot konfigūracijose.

GSMMO ir masinio naudojimo įrankiai

Google Workspace Migration for Microsoft Outlook (GSMMO) skirtas migruoti iš Outlook, o ne iš paprasto IMAP serverio. Kai jis naudojamas migruoti iš cPanel (per IMAP paskyrą, sukonfigūruotą Outlook programoje), datoms taikomas tas pats: INTERNALDATE Google Workspace nustatoma migracijos datai. GSMMO el. laiškų datos problema yra iš tikrųjų dokumentuota atskirai, tokia ji dažna.

Kurios pašto programos yra paveiktos?

Klaidingos datos rodomos ne vienodai visose pašto programose.

Outlook yra labiausiai paveiktas. Jis naudoja INTERNALDATE (arba migracijos Received: antraštę) kaip pagrindinį rūšiavimo raktą aplankuose. Po netvarkingai atliktos cPanel migracijos Outlook pašto dėžutė gali rodyti tūkstančius archyvuotų laiškų su migracijos savaitgalio data. Imapsync migracijos datų pataisymas Outlook programoje yra vienas iš dažniausiai prašomų pataisymų.

Gmail (Google Workspace) laiškų sąraše paprastai rodo datą iš Date: antraštės, bet rūšiavimą kai kuriais atvejais gali paveikti ir INTERNALDATE. Vartotojai praneša apie neįprastą veikimą ieškant ir rūšiuojant pagal datą.

Apple Mail ir Thunderbird veikia nevienodai, bet nė vienas nėra apsaugotas, ypač kai migracijos Received: antraštė yra viršuje antraščių grandinėje.

Gera žinia: pradinė data tebėra

Tai techninė detalė, kuri pakeičia visą vaizdą. Pradinė Date: antraštė yra įrašyta į pradinį laiško turinį. Migracija jos nepaliečia. Kai atidarote paveiktą laišką ir pažiūrite pradines antraštes (Gmail: "Show original", Outlook: File > Properties), matote nepakitusią pradinę Date: antraštę, po kurios seka viena ar daugiau Received: antraščių, kur pirmoji nurodo migracijos datą.

Ta informacija tebėra. Ją galima naudoti metaduomenims pataisyti. Tai tiksliai tai, ką daro Redate.io taisymo variklis.

Kodėl "pasidaryti pačiam" yra rizikingiau, nei atrodo

Pagunda yra reali. Problema atrodo paprasta: perskaityti pradinę datą, pataisyti metaduomenis, tęsti darbą. Bet yra didelis skirtumas tarp mechanizmo supratimo ir 12 000 gamybinių el. laiškų pataisymo, neprarandant nė vieno.

Kelios realijos, kurių savarankiškai parašyti scenarijai paprastai neįvertina:

Scenarijus, kuris veikia su 50 testinių laiškų kūrimo aplinkoje, nebūtinai atlaikys 18 000 laiškų gamybinėje pašto dėžutėje, paveldėtoje iš cPanel paskyros, veikiančios nuo 2011 metų.

Kaip Redate.io pataiso datas po cPanel migracijos

Redate.io prisijungia tiesiai prie paskirties pašto dėžutės (Google Workspace, Microsoft 365 su paprastu prisijungimu arba tiesioginiu IMAP) ir pradeda nemokamu nuskaitymu, siekiant nustatyti laiškus, kurių datos metaduomenys neatitinka pradinės Date: antraštės.

Daugiapakopis analizės procesas tuomet nustato, kurie el. laiškai turi neatitikimą tarp rodomos datos ir pradinės Date: antraštės, nesvarbu, koks įrankis buvo naudotas migracijai. Tikslinis metaduomenų taisymas taikomas nekeičiant laiško turinio: teksto, priedų, pradinių antraščių, visko, kas išlieka nepakitusio. Kiekvienas pataisytas laiškas patikrinamas atskirai prieš operacijos patvirtinimą.

Konkrečiai cPanel migracijoms, variklis nustato neatitikimus, būdingus Dovecot-IMAP migracijoms ir imapsync scenarijams, nepriklausomai nuo prieglobos paslaugų teikėjo naudojamos konfigūracijos.

Konkretūs vadovai pagal paskirties platformą

Atsižvelgiant į tai, kur nukeliavo jūsų cPanel migracija, šie vadovai apima tikslius žingsnius:

Migravote iš cPanel ir jūsų vartotojai mato neteisingas datas? Paleiskite nemokamą nuskaitymą Redate.io, kad sužinotumėte, kiek tiksliai laiškų yra paveikta, nedarant jokių pakeitimų, kol jų nepatvirtinsite.