cPanel-migraatio: väärät päivämäärät

Maanantaiaamu, joka sattuu

Olet juuri saanut valmiiksi cPanel-jaettuisännöinnin siirron Google Workspaceen tai Microsoft 365:een. Kaikki näyttää hyvältä: postilaatikot toimivat, käyttäjät kirjautuvat sisään. Sitten kello 9:15 ensimmäinen tiketti tulee: "Kaikissa vanhoissa sähköposteissani näkyy sama päivämäärä, viime viikonlopulta." Sitten toinen. Sitten kymmenen.

Tämä ei ole yksittäinen bugi. Se on suora seuraus siitä, miten cPanel-migraatiot käsittelevät (tai pikemminkin jättävät käsittelemättä) sähköpostien päivämäärämetadataa.

cPanel, Roundcube, Horde: erityinen IMAP-ympäristö

Jaettu cPanel-isännöinti tarkoittaa Linux-palvelinta, jossa pyörii IMAP-palvelin (yleensä Dovecot) ja Roundcube tai Horde webmail-käyttöliittymänä. Ei mitään eksoottista. Mutta tässä ympäristössä on muutama erityispiirre, jotka tekevät migraatioista enterprise-alustoille odotettua hankalampia.

Ensinnäkin cPanel-postilaatikoihin kertyy usein sähköposteja vuosien, joskus vuosikymmenen ajalta. Asiakas, joka on isännöinyt domainansa jaetulla palvelimella vuodesta 2013, voi omata hyvin syviä arkistoja. Tämä volyymi yhdistettynä migraatiotapaan luo otollisen maaperän päivämääräongelmille.

Toiseksi käytetyt siirtotyökalut ovat usein joko WHM:n sisäänrakennettu migraatiotyökalu, komentorivillä ajettava imapsync tai kuluttajatyökalut kuten GSMMO Google Workspace -migraatioon.

Miksi päivämäärät rikkoutuvat cPanel-migraatiossa

Ongelman ymmärtämiseksi täytyy käsitellä kaksi erillistä käsitettä: sähköpostin Date:-otsikko ja IMAP INTERNALDATE.

Date:-otsikko kirjoitetaan viestin raakarakenteeseen lähetyshetkellä RFC 2822:n mukaisesti. Se kertoo, milloin sähköposti laadittiin ja lähetettiin. Tämä otsikko ei koskaan muutu, ellei viestiä tarkoituksellisesti muokata.

INTERNALDATE puolestaan on metadata, jonka IMAP-palvelin liittää jokaiseen tallennettuun viestiin. Se on erillään viestin sisällöstä. Kun sähköposti saapuu normaalisti palvelimelle, INTERNALDATE asetetaan viestin Received:-otsikoiden perusteella tai suoraan tallennusajankohdan mukaan. Tätä arvoa Outlook, Thunderbird ja useimmat sähköpostiohjelmat käyttävät viestien lajitteluun.

IMAP-migraatiossa viestit kopioidaan palvelimelta toiselle. Ongelma: migraatiotyökalun täytyy luoda jokainen viesti kohdepalvelimella. Ja monilla työkaluilla uuden viestin INTERNALDATE vastaa migraatiohetkeä, ei viestin alkuperäistä päivämäärää. Lisäksi migraatiopäivällä aikaleimatttu Received:-otsikko lisätään otsikkoketjun kärkeen, mikä hämmentää entisestään niitä sähköpostiohjelmia, jotka käyttävät sitä näytettävän päivämäärän laskemiseen.

Tulos: vuodelta 2019 oleva sähköposti saapuu Google Workspaceen INTERNALDATE-arvolla migraatiopäivälle asetettuna ja eilisellä aikaleimattulla Received:-otsikolla. Outlook näyttää sen saapuneet-kansiossa kuin se olisi juuri saapunut. Koko arkistoinnin aikajärjestys tuhoutuu.

WHM/cPanel-migraatiotyökalu

WHM:n sisäänrakennettu työkalu cPanel-tilien siirtämiseen toiselle alustalle aiheuttaa tämän ongelman lähes järjestelmällisesti, kun kohde on ulkoinen IMAP-palvelin (Google Workspace, Microsoft 365). Se kopioi Maildir-sisällön uudelle palvelimelle IMAP APPEND -komennolla säilyttämättä alkuperäistä INTERNALDATE-arvoa. Jokainen viesti saa näin operaatiohetken aikaleiman.

imapsync ja manuaaliset siirrot cPanelista

imapsync on tehokas työkalu, mutta sen oletuskäyttäytyminen ei aina säilytä päivämääriä. Ilman oikeita parametreja (ja oikeaa versiota) se voi kopioida 40 000 viestiä antaen kaikille skriptin suorituspäivän. (Jos olet joskus käynyt imapsync-lokeja rivi riviltä läpi diagnosoidaksesi päivämääräongelmaa 25 000 viestin postilaatikossa, tiedät, että se on kokemus, jota ei halua toistaa.)

Tarkasti ottaen imapsync tarjoaa vaihtoehtoja päivämäärän säilyttämiseen, mutta nämä vaihtoehdot toimivat eri tavoin eri lähde- ja kohdepalvelinyhdistelmillä, eikä niiden toimivuus ole taattu kaikissa cPanel/Dovecot-konfiguraatioissa.

GSMMO ja kuluttajatyökalut

Google Workspace Migration for Microsoft Outlook (GSMMO) on suunniteltu siirtämään tietoja Outlookista, ei pelkältä IMAP-palvelimelta. Kun sitä käytetään cPanel-migraatioon (Outlookiin konfiguroidun IMAP-tilin kautta), päivämäärät kärsivät saman kohtalon: INTERNALDATE Google Workspacessa asettuu migraatiopäivälle. GSMMO:n päivämääräongelma on dokumentoitu erikseen, niin yleinen se on.

Mitkä sähköpostiohjelmat kärsivät ongelmasta?

Päivämääräkorruptio ei ilmene samalla tavalla eri ohjelmissa.

Outlook kärsii eniten. Se käyttää INTERNALDATE-arvoa (tai migraation Received:-otsikkoa) ensisijaisena lajittelukriteerinä kansioissa. Huonosti hoidetun cPanel-migraation jälkeen Outlook-postilaatikko voi näyttää tuhansia arkistoituja sähköposteja migraatioviikonlopun päivämäärällä. imapsync-siirron päivämäärien korjaus Outlookissa on yksi yleisimmistä korjauspyynnöistä.

Gmail (Google Workspace) näyttää yleensä Date:-otsikon päivämäärän sähköpostilistassa, mutta lajittelu voi silti häiriintyä INTERNALDATE-arvon takia tietyissä tilanteissa. Käyttäjät raportoivat epäsäännöllistä käyttäytymistä haussa ja päivämäärälajittelussa.

Apple Mail ja Thunderbird käyttäytyvät hieman eri tavoin, mutta kumpikaan ei ole immuuni ongelmalle, varsinkin kun migraation Received:-otsikko on otsikkoketjun kärjessä.

Hyvä uutinen: alkuperäinen päivämäärä on tallessa

Tämä on tekninen yksityiskohta, joka muuttaa kaiken. Viestin alkuperäinen Date:-otsikko on kirjoitettu sähköpostin raakarakenteeseen. Migraatio ei koske siihen. Kun avaat jonkin kärsivän sähköpostin ja katsot raakaotsikkoja (Gmailissa: "Näytä alkuperäinen", Outlookissa: Tiedosto > Ominaisuudet), näet alkuperäisen Date:-arvon ehjänä, sen jälkeen yhden tai useamman Received:-otsikon, joista ensimmäisellä on migraatiopäivämäärä.

Tämä tieto on aina läsnä. Sitä voidaan käyttää metadatan korjaamiseen. Juuri tätä Redate.io:n korjausmoottori tekee.

Miksi "korjata itse" on riskialttiimpaa kuin miltä näyttää

Houkutus on suuri. Ongelma vaikuttaa yksinkertaiselta: lue alkuperäinen päivämäärä, korjaa metadata, siirry seuraavaan. Mutta mekanismin ymmärtämisen ja 12 000 tuotantosähköpostin korjaamisen välillä ilman yhtäkään menetystä on huomattava kuilu.

Muutamia todellisuuksia, joita kotitekoiset skriptit eivät yleensä huomioi:

S/MIME-allekirjoitetut tai PGP-salatut sähköpostit: mikä tahansa muutos viestin rakenteeseen mitätöi kryptografisen allekirjoituksen. Sähköposti, joka läpäisi allekirjoitusvarmistuksen ennen korjausta, ei läpäise sitä enää jälkeen. Sääntelymääräysten piirissä olevat käyttäjät (lakitoimistot, finanssiala, terveydenhuolto) löytävät tämän ongelman pahimmalla mahdollisella hetkellä.
Ei-ASCII-otsikot ja RFC 2047 -koodaus: cPanel-postilaatikoihin kertyy vuosien ajan sähköposteja hyvin erilaisista sähköpostiohjelmista. Jotkin otsikot sisältävät RFC 2047:n mukaan koodattuja merkkejä. Huonosti kirjoitettu skripti, joka rakentaa otsikot uudelleen, voi korruptoida nämä koodaukset näkymättömästi.
Sisäkkäiset MIME-rakenteet: sähköpostilla, jossa on kolme liitettä ja vaihtoehtoinen HTML-runko, on monimutkainen multipart-rakenne. Pienin virhe MIME-rajoissa tekee viestistä lukukelvottoman, tai pahempaa: liitteet katoavat ilman virheilmoitusta.
API-kiintiöt ja nopeusrajoitukset: Google Workspace ja Microsoft 365 asettavat tiukat rajat IMAP-operaatioiden määrälle minuutissa. Skripti, joka ei toteuta eksponentiaalista peräytymistä oikein, laukaisee 429-virheitä kello kolmelta aamuyöllä, ja herät puoliksi valmiin migraation kanssa tietämättä tarkalleen, mihin se pysähtyi.
Ei rollback-mahdollisuutta: jos jotain menee pieleen kesken kaiken, mihin tilaan palataan? Ovatko alkuperäiset vielä tallessa? Onko duplikaatteja? Redate.io säilyttää alkuperäiset näkyvässä varmuuskopiointikansiossa 30 päivän ajan juuri tämän tilanteen välttämiseksi.

Skripti, joka toimii 50 testisähköpostilla kehitysympäristössä, ei välttämättä toimi 18 000 viestin tuotantopostilaatikossa, joka on peräisin cPanel-isännöinniltä vuodesta 2011.

Miten Redate.io korjaa päivämäärät cPanel-migraation jälkeen

Redate.io yhdistää suoraan kohdepostilaatikkoon (Google Workspace domain-delegoinnin kautta, Microsoft 365 Azure AD:n kautta tai suoraan IMAP-palvelimelle) ja aloittaa ilmaisella skannauksella tunnistaakseen sähköpostit, joiden päivämäärämetadata on ristiriidassa alkuperäisen Date:-otsikon kanssa.

Monivaiheinen analyysipipeline soveltaa sitten kuviovastaavuutta Received:-otsikkosignatuureihin tunnistaakseen migraatiotyökalujen lisäämät otsikot (ja erottaakseen ne aitoista otsikoista). Kohdennettu metadatakorjaus tehdään muuttamatta viestin sisältöä: teksti, liitteet, alkuperäiset otsikot, kaikki säilyy ehjänä. Jokainen korjattu sähköposti tarkistetaan yksitellen ennen toimenpiteen vahvistamista.

cPanel-migraatioissa erityisesti moottori tunnistaa Dovecot-to-IMAP-migraatioille ja imapsync-skripteille tyypilliset signatuurit, mukaan lukien yleisten jaettujen isännöintitarjoajien käyttämät konfiguraatiovariantit.

Kohdealustan mukaiset oppaat

Riippuen cPanel-migraatiosi kohdealustasta, seuraavat oppaat kuvaavat tarkat vaiheet:

Siirsitkö sähköpostit cPanelista ja käyttäjäsi näkevät väärät päivämäärät? Käynnistä ilmainen skannaus Redate.io:ssa selvittääksesi tarkalleen, kuinka monta sähköpostia on kärsivänä, ilman mitään muutoksia ennen lupaasi.

cPanel-migraatio: väärät sähköpostipäivät