cPanel-siirto: väärät sähköpostipäivä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-siirrot 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 siirroista 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ä siirtotapaan luo otollisen maaperän päivämääräongelmille.

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

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

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-siirrossa viestit kopioidaan palvelimelta toiselle. Ongelma: siirtotyökalun täytyy luoda jokainen viesti kohdepalvelimella. Ja monilla työkaluilla uuden viestin INTERNALDATE vastaa siirtohetkeä, ei viestin alkuperäistä päivämäärää. Lisäksi siirtopä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 siirtopä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-siirtotyö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-siirtoon (Outlookiin konfiguroidun IMAP-tilin kautta), päivämäärät kärsivät saman kohtalon: INTERNALDATE Google Workspacessa asettuu siirtopä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 siirron Received:-otsikkoa) ensisijaisena lajittelukriteerinä kansioissa. Huonosti hoidetun cPanel-siirron jälkeen Outlook-postilaatikko voi näyttää tuhansia arkistoituja sähköposteja siirtoviikonlopun 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 siirron 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. Siirto 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 siirtopä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 siirron 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 ei poista alkuperäisiä koskaan: ne säilyvät näkyvässä varmuuskopiointikansiossa, kunnes poistat ne itse.

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-siirron jälkeen

Redate.io yhdistää suoraan kohdepostilaatikkoon (Google Workspace domain-delegoinnin kautta, Microsoft 365:ssä oman Microsoft-tilin kirjautumisen 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 siirtotyö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-siirroissa erityisesti moottori tunnistaa Dovecot-to-IMAP-siirroille ja imapsync-skripteille tyypilliset signatuurit, mukaan lukien yleisten jaettujen isännöintitarjoajien käyttämät konfiguraatiovariantit.

Kohdealustan mukaiset oppaat

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

• Korjaa imapsync-siirron päivämäärät Gmailissa
• Korjaa imapsync-siirron päivämäärät Microsoft 365:ssä
• Korjaa imapsync-siirron päivämäärät Google Workspacessa
• Päivämäärien korjaus Google Workspace -siirron jälkeen
• Sähköpostipäivien korjaus Microsoft 365 -siirron jälkeen

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.