cPanel-migrering: forkerte e-maildatoer

Mandagmorgen, der gør ondt

Du har netop afsluttet migreringen fra et delt cPanel-webhotel til Google Workspace eller Microsoft 365. Alt gik fint, postkasserne er tilgængelige, brugerne logger ind. Så, omkring kl. 9.15, falder den første supporthenvendelse ind: "Mine gamle e-mails viser alle den samme dato, fra i weekenden." Så en til. Så ti.

Det er ikke en isoleret fejl. Det er den direkte konsekvens af, hvordan cPanel-migreringer håndterer (eller rettere sagt ikke håndterer) datometadata i e-mails.

cPanel, Roundcube, Horde: en særlig IMAP-kontekst

Et delt cPanel-webhotel er en Linux-server, der kører en IMAP-server (typisk Dovecot) med Roundcube eller Horde som webmail-interface. Ikke noget eksotisk i det. Men denne kontekst har et par særtræk, der gør migreringer til enterprise-platforme mere besværlige, end de ser ud til.

For det første akkumulerer cPanel-postkasser ofte e-mails over mange år, sommetider et årti. En kunde, der har hostet sit domæne på et delt webhotel siden 2013, kan have meget dybe arkiver. Det volumen, kombineret med måden migreringen udføres på, skaber grobund for datokorruption.

Desuden er de værktøjer, der bruges til disse migreringer, ofte enten WHM's eget migrationsværktøj, imapsync kørt fra kommandolinjen af hotellet eller IT-leverandøren, eller forbrugerløsninger som GSMMO til migrering til Google Workspace.

Hvorfor datoer ødelægges efter en cPanel-migrering

For at forstå problemet skal man kende to separate begreber: Date:-headeren i en e-mail og IMAP INTERNALDATE.

Date:-headeren er indskrevet i selve beskedindholdet på afsendelsestidspunktet, i overensstemmelse med RFC 2822. Den angiver, hvornår e-mailen blev skrevet og sendt. Denne header ændres aldrig, medmindre beskeden manipuleres med vilje.

INTERNALDATE er derimod en metadata-værdi, som IMAP-serveren tilknytter hver enkelt gemt besked. Den er adskilt fra beskedens indhold. Når en e-mail ankommer normalt til en server, fastsættes INTERNALDATE ud fra beskedens Received:-headere, eller ud fra indsendelsestidspunktet hvis beskeden indsendes direkte. Det er denne værdi, Outlook, Thunderbird og de fleste e-mailklienter bruger til at sortere beskeder.

Under en IMAP-migrering kopieres beskeder fra én server til en anden. Problemet er, at migreringsværktøjet skal oprette hver besked på destinationsserveren. Og for mange værktøjer svarer INTERNALDATE for den nyoprettede besked til migreringstidspunktet, ikke til beskedens oprindelige dato. Samtidig tilføjes en Received:-header med migreringstidsstemplet øverst i header-kæden, hvilket forvirrer e-mailklienter, der benytter den til at beregne den viste dato.

Resultatet: en e-mail fra 2019 ankommer til Google Workspace med en INTERNALDATE sat til migreringsdag, og en Received:-header stemplet i går. Outlook viser den i indbakken, som om den netop er ankommet. Hele arkivets kronologi er ødelagt.

WHM / cPanel's eget migreringsværktøj

Det integrerede WHM-værktøj til at migrere cPanel-konti til andre platforme genererer dette problem næsten systematisk, når destinationen er en ekstern IMAP-server (Google Workspace, Microsoft 365). Det kopierer indholdet af Maildir-mapperne til den nye server via IMAP APPEND uden at bevare den originale INTERNALDATE. Hver besked får derfor et tidsstempel fra operationens tidspunkt.

imapsync og manuelle migreringer fra cPanel

imapsync er et kraftfuldt værktøj, men dets standardadfærd bevarer ikke altid datoer. Uden de rigtige parametre (og den rigtige version) kan det sagtens kopiere 40.000 beskeder og tildele dem alle udførelsdatoen for scriptet. (Og hvis du nogensinde har gennemgået imapsync-logs linje for linje for at diagnosticere et datoproblem i en postkasse med 25.000 beskeder, ved du, at det ikke er en oplevelse, man søger at gentage.)

For at være præcis: imapsync har muligheder for at forsøge at bevare datoen, men disse muligheder interagerer forskelligt afhængigt af kilde- og destinationsserverne, og deres effektivitet er ikke garanteret på alle cPanel/Dovecot-konfigurationer.

GSMMO og forbrugerværktøjer

Google Workspace Migration for Microsoft Outlook (GSMMO) er beregnet til at migrere fra Outlook, ikke fra en ren IMAP-server. Når det bruges til at migrere fra cPanel (via en IMAP-konto konfigureret i Outlook), undergår datoerne samme behandling: INTERNALDATE på Google Workspace fastsættes til migreringstidspunktet. Problemet med GSMMO og e-maildatoer er i øvrigt dokumenteret separat, så udbredt er det.

Hvilke e-mailklienter er berørt?

Datokorruption viser sig ikke på samme måde i alle klienter.

Outlook er den mest berørte klient. Den bruger INTERNALDATE (eller migreringsbeskedens Received:-header) som primært sorteringskriterium for mapper. Efter en dårligt håndteret cPanel-migrering kan en Outlook-postkasse vise tusindvis af arkiverede e-mails med datoen fra migreringsweekenden. Rettelse af imapsync-datoer i Outlook er en af de hyppigst efterspurgte rettelser.

Gmail (Google Workspace) viser typisk datoen fra Date:-headeren i e-maillisten, men sorteringen kan stadig påvirkes af INTERNALDATE i visse tilfælde. Brugere rapporterer uregelmæssig adfærd ved søgning og datosortering.

Apple Mail og Thunderbird opfører sig mere nuanceret, men ingen af dem er immune over for problemet, særligt når migreringsbeskedens Received:-header optræder øverst i kæden.

Den gode nyhed: den originale dato er stadig der

Det er det tekniske detalje, der ændrer alt. Den originale Date:-header er indskrevet i beskedens rå indhold. Migreringen rører den ikke. Når du åbner en berørt e-mail og ser på de rå headers (i Gmail: "Vis original", i Outlook: Filer > Egenskaber), ser du den intakte Date:-header efterfulgt af én eller flere Received:-headere, hvor den øverste bærer migreringstidsstemplet.

Den information er altid til stede. Den kan udnyttes til at rette metadata. Det er præcis, hvad Redate.io's korrektionsmotor gør.

Hvorfor "fikse det selv" er mere risikabelt, end det ser ud

Fristelsen er stor. Problemet virker ligetil: læs den originale dato, ret metadataene, gå videre til næste. Men der er en betragtelig forskel på at forstå mekanismen og at rette 12.000 e-mails i produktion uden at miste en eneste.

Nogle realiteter, som hjemmelavede scripts typisk ikke håndterer:

S/MIME-signerede eller PGP-krypterede e-mails: enhver ændring af beskedens struktur ugyldiggør den kryptografiske signatur. En e-mail, der bestod signaturbekræftelse før rettelse, gør det ikke længere bagefter. Brugere i regulerede brancher (advokatbureauer, finans, sundhed) opdager det på det værst tænkelige tidspunkt.
Ikke-ASCII-headere og RFC 2047-kodning: cPanel-postkasser akkumulerer mange års e-mails fra meget forskelligartede e-mailklienter. Visse headere indeholder tegn kodet efter RFC 2047. Et dårligt skrevet script, der genopbygger headere, kan korrupte disse kodninger på usynlig vis.
Indlejrede MIME-strukturer: en e-mail med tre vedhæftede filer og en alternativ HTML-krop har en kompleks multipart-struktur. Den mindste fejl i MIME-grænser gør beskeden ulæselig, eller endnu værre: vedhæftninger forsvinder uden fejlmeddelelse.
API-kvoter og rate limiting: Google Workspace og Microsoft 365 pålægger strenge grænser for antallet af IMAP-operationer per minut. Et script, der ikke implementerer eksponentiel backoff korrekt, udløser 429-fejl klokken 3 om natten, og du vågner op til en halvfærdig migrering, hvor du ikke ved præcis, hvor den stoppede.
Ingen rollback-mulighed: hvis noget går galt midtvejs, hvilken tilstand vender du tilbage til? Er originalerne stadig der? Har du dubletter? Redate.io bevarer originalerne i en synlig backup-mappe i 30 dage, præcis for at undgå den situation.

Et script, der virker på 50 test-e-mails i et udviklingsmiljø, vil ikke nødvendigvis fungere på 18.000 beskeder i en produktionspostkasse, der har ligget på et cPanel-webhotel siden 2011.

Hvordan Redate.io retter datoer efter cPanel-migrering

Redate.io forbinder sig direkte til destinationspostkassen (Google Workspace via domain delegation, Microsoft 365 via Azure AD, eller direkte IMAP-server) og starter med et gratis scan for at identificere e-mails, hvis datometadata er inkonsistente med den originale Date:-header.

Den flertrinede analysepipeline anvender derefter mønstergenkendelse på Received:-header-signaturer for at identificere dem, der er introduceret af migreringsværktøjer (og skelne dem fra legitime headere). Den målrettede metadatakorrektion udføres uden at ændre beskedens indhold: tekst, vedhæftninger, originale headere, alt forbliver intakt. Hver rettet e-mail verificeres individuelt, inden operationen valideres.

For migreringer fra cPanel specifikt genkender motoren de typiske signaturer fra Dovecot-til-IMAP-migreringer og imapsync-scripts, herunder de almindelige konfigurationsvarianter hos europæiske og danske delte webhoteludbydere.

Specifikke guides efter din destinationsplatform

Afhængigt af destinationsplatformen for din cPanel-migrering beskriver følgende guides de præcise trin:

Har du migreret fra cPanel, og ser dine brugere forkerte datoer? Kør et gratis scan på Redate.io for at se præcis, hvor mange e-mails der er berørt, uden at der foretages nogen ændringer, før du godkender det.

Forkerte e-maildatoer efter cPanel-migrering