cPanel-migrering: feil e-postdatoer

Mandagsmorgenen ingen vil ha

Du har akkurat fullført migreringen fra et delt cPanel-webhotell til Google Workspace eller Microsoft 365. Alt gikk greit, postboksene er tilgjengelige, brukerne logger inn. Så, rundt 09:15, kommer den første supportsaken: "Alle de gamle e-postene mine viser samme dato, datoen fra forrige helg." Deretter en til. Så ti.

Dette er ikke en isolert feil. Det er en direkte konsekvens av hvordan cPanel-migreringer håndterer (eller rettere sagt ikke håndterer) dato-metadata i e-poster.

cPanel, Roundcube, Horde: en spesiell IMAP-kontekst

Et delt cPanel-webhotell er egentlig en Linux-server som kjører en IMAP-server (vanligvis Dovecot) med Roundcube eller Horde som webmail-grensesnitt. Ingenting eksotisk der. Men denne konteksten har noen særtrekk som gjør migreringer til enterprise-plattformer mer krevende enn de ser ut til å være.

For det første akkumulerer cPanel-postbokser ofte e-poster over mange år, noen ganger et tiår. En kunde som har hostet domenet sitt på et delt webhotell siden 2013 kan ha svært dype arkiver. Dette volumet, kombinert med måten migreringen utføres på, skaper grobunn for datoProblemet.

Videre er verktøyene som brukes til disse migreringene gjerne enten det innebygde migrasjonsverktøyet i WHM, imapsync kjørt fra kommandolinjen av webhotellet eller IT-leverandøren, eller forbrukerverktøy som GSMMO for migrering til Google Workspace.

Hvorfor datoer blir ødelagt etter cPanel-migrering

For å forstå problemet må du kjenne til to distinkte konsepter: Date:-headeren i en e-post og IMAP INTERNALDATE.

Date:-headeren er skrevet inn i selve meldingen på avsendingstidspunktet, i henhold til RFC 2822. Den angir når e-posten ble skrevet og sendt. Denne headeren endres aldri, med mindre meldingen manipuleres med vilje.

INTERNALDATE er derimot en metadata-verdi som IMAP-serveren knytter til hver lagret melding. Den er atskilt fra meldingsinnholdet. Når en e-post ankommer en server på normalt vis, settes INTERNALDATE basert på Received:-headerne i meldingen, eller etter innleveringstidspunktet hvis meldingen leveres direkte. Det er denne verdien Outlook, Thunderbird og de fleste e-postklienter bruker for å sortere meldinger.

Under en IMAP-migrering kopieres meldingene fra én server til en annen. Problemet er at migrasjonsverktøyet må opprette hver melding på destinasjonsserveren. For mange verktøy vil INTERNALDATE for den nyopprettede meldingen tilsvare datoen for migreringen, ikke den opprinnelige meldingsdatoen. I tillegg legges det til en Received:-header med migrasjonsdatoen øverst i header-kjeden, noe som forvirrer e-postklienter som bruker den til å beregne visningsdatoen.

Resultatet: en e-post fra 2019 ankommer Google Workspace med en INTERNALDATE satt til migrasjonsdagen, og en Received:-header stemplet i går. Outlook viser den i innboksen som om den nettopp kom inn. Hele kronologien i arkivet er ødelagt.

WHM / cPanel sitt migrasjonsverktøy

Det innebygde verktøyet i WHM for å migrere cPanel-kontoer til en annen plattform genererer dette problemet nærmest systematisk når destinasjonen er en ekstern IMAP-server (Google Workspace, Microsoft 365). Det kopierer Maildir-innholdet til den nye serveren via IMAP APPEND uten å bevare den opprinnelige INTERNALDATE. Hver melding får altså tidsstempel fra operasjonstidspunktet.

imapsync og manuelle migreringer fra cPanel

imapsync er et kraftig verktøy, men standardoppførselen bevarer ikke alltid datoer. Uten de riktige parametrene (og riktig versjon) kan det fint kopiere 40 000 meldinger og gi dem alle kjøretidspunktet som dato. (Og har du noen gang gått gjennom imapsync-logger linje for linje for å diagnostisere et datoproblem i en postboks med 25 000 meldinger, vet du at det er en opplevelse man ikke ønsker å gjenta.)

For å være presis: imapsync har alternativer for å forsøke å bevare dato, men disse alternativene fungerer forskjellig avhengig av kilde- og destinasjonsserver, og effektiviteten er ikke garantert på alle cPanel / Dovecot-konfigurasjoner.

GSMMO og forbrukerverktøy

Google Workspace Migration for Microsoft Outlook (GSMMO) er laget for å migrere fra Outlook, ikke fra en ren IMAP-server. Når det brukes til å migrere fra cPanel (via en IMAP-konto konfigurert i Outlook), utsettes datoene for samme behandling: INTERNALDATE på Google Workspace settes til migrasjonsdatoen. GSMMO-problemet med e-postdatoer er forresten dokumentert separat, så utbredt er det.

Hvilke e-postklienter er berørt?

Datokorrupsjonen viser seg ikke likt i alle klienter.

Outlook er den mest berørte klienten. Den bruker INTERNALDATE (eller Received:-headeren fra migreringen) som primært sorteringskriterium for mapper. Etter en dårlig håndtert cPanel-migrering kan en Outlook-postboks vise tusenvis av arkiverte e-poster med migreringshelgens dato. Se retting av imapsync-datoer i Outlook for detaljer.

Gmail (Google Workspace) viser vanligvis datoen fra Date:-headeren i e-postlisten, men sorteringen kan likevel påvirkes av INTERNALDATE i noen tilfeller. Brukere rapporterer uforutsigbar oppførsel ved søk og datosortering.

Apple Mail og Thunderbird oppfører seg noe annerledes, men ingen av dem er immune mot problemet, spesielt når Received:-headeren fra migreringen er øverst i kjeden.

Den gode nyheten: den opprinnelige datoen er fortsatt der

Dette er det tekniske detaljpunktet som endrer alt. Den opprinnelige Date:-headeren er skrevet inn i selve e-postmeldingen. Migreringen rører den ikke. Åpner du en berørt e-post og ser på råhodene (i Gmail: "Vis original", i Outlook: Fil > Egenskaper), ser du den intakte opprinnelige Date:-headeren, etterfulgt av én eller flere Received:-headere der den første bærer migrasjonsdatoen.

Denne informasjonen er alltid til stede. Den kan brukes til å rette metadataene. Det er nøyaktig det Redate.ios korreksjonsmotor gjør.

Hvorfor "fikse det selv" er mer risikabelt enn det ser ut

Fristelsen er stor. Problemet virker enkelt: les den opprinnelige datoen, rett metadataene, gå videre. Men mellom å forstå mekanismen og å rette 12 000 e-poster i produksjon uten å miste én eneste, er det en betydelig avstand.

Noen realiteter hjemmelagde skript vanligvis ikke tar høyde for:

S/MIME-signerte eller PGP-krypterte e-poster: enhver endring av meldingsstrukturen ugyldiggjør den kryptografiske signaturen. En e-post som bestod signaturverifisering før korreksjonen, gjør det ikke lenger etterpå. Brukere med regulatoriske krav (advokatfirmaer, finanssektoren, helse) oppdager dette på verst mulig tidspunkt.
Ikke-ASCII-headere og RFC 2047-koding: cPanel-postbokser samler opp år med e-poster fra svært ulike e-postklienter. Noen headere inneholder tegn kodet etter RFC 2047. Et dårlig skrevet skript som rekonstruerer headere kan korruptere disse kodingene på en usynlig måte.
Nestede MIME-strukturer: en e-post med tre vedlegg og en alternativ HTML-kropp har en kompleks multipart-struktur. Den minste feilen med MIME-grenser gjør meldingen uleselig, eller verre: vedleggene forsvinner uten feilmelding.
API-kvoter og rate limiting: Google Workspace og Microsoft 365 har strenge grenser for antall IMAP-operasjoner per minutt. Et skript som ikke implementerer eksponentiell backoff korrekt, utløser 429-feil klokken 03:00, og du våkner opp til en halvferdig migrering der du ikke vet nøyaktig hvor den stoppet.
Ingen rollback-mulighet: hvis noe går galt midtveis, hvilken tilstand går du tilbake til? Er originalene fortsatt der? Har du dubletter? Redate.io beholder originalene i en synlig sikkerhetskopieringsmappe i 30 dager, nettopp for å unngå denne situasjonen.

Et skript som fungerer på 50 teste-poster i et utviklingsmiljø vil ikke nødvendigvis fungere på 18 000 meldinger i en produksjonspostboks arvet fra et cPanel-webhotell siden 2011.

Slik retter Redate.io datoer etter cPanel-migrering

Redate.io kobler seg direkte til destinasjonspostboksen (Google Workspace via domenedelegering, Microsoft 365 via Azure AD, eller direkte IMAP-server) og starter med et gratis skann for å identifisere e-poster der dato-metadataene ikke stemmer overens med den opprinnelige Date:-headeren.

Den flerstegs analysepipelinen bruker deretter mønstergjenkjenning på Received:-header-signaturer for å identifisere de som ble introdusert av migrasjonsverktøyene (og skille dem fra legitime headere). Den målrettede metadatakorreksjonen utføres uten å endre meldingsinnholdet: tekst, vedlegg, opprinnelige headere, alt forblir intakt. Hver korrigert e-post verifiseres individuelt før operasjonen valideres.

For cPanel-migreringer spesifikt gjenkjenner motoren typiske signaturer fra Dovecot-til-IMAP-migreringer og imapsync-skript, inkludert vanlige konfigurasjonsvarianter hos europeiske delte webhoteller.

Spesifikke guider etter destinasjonsplattform

Avhengig av hvilken plattform cPanel-migreringen din gikk til, beskriver følgende guider de konkrete stegene:

Har du migrert fra cPanel og brukerne dine ser feil datoer? Start et gratis skann på Redate.io for å se nøyaktig hvor mange e-poster som er berørt, uten at noe endres før du godkjenner det.

Feil e-postdatoer etter cPanel-migrering