Felaktiga e-postdatum efter cPanel-migrering

Måndagsmorgonen som gör ont

Du har precis avslutat migreringen från ett delat cPanel-webbhotell till Google Workspace eller Microsoft 365. Allt gick bra, postlådorna är tillgängliga, användarna loggar in. Sedan, runt 09:15, ramlar det in ett första ärende: "Mina gamla e-postmeddelanden visar alla samma datum, det från förra helgen." Sedan ett till. Sedan tio.

Det här är inget isolerat fel. Det är den direkta konsekvensen av hur cPanel-migreringer hanterar (eller snarare inte hanterar) e-postmeddelandenas datummetadata.

cPanel, Roundcube, Horde: en specifik IMAP-kontext

En delad cPanel-webbhotellmiljö är en Linux-server som kör en IMAP-server (vanligtvis Dovecot) med Roundcube eller Horde som webbmailgränssnitt. Inget exotiskt med det. Men den här kontexten har några egenheter som gör migreringar till företagsplattformar kluriggare än de verkar.

För det första tenderar cPanel-postlådor att samla på sig e-postmeddelanden under flera år, ibland ett decennium. En kund som haft sin domän på delat webbhotell sedan 2013 kan ha mycket djupa arkiv. Den volymen, tillsammans med hur migreringen genomförs, skapar en bördig mark för datumproblemet.

Dessutom är verktygen som används för dessa migreringar ofta antingen det inbyggda cPanel-verktyget (WHM:s funktion "Migrations"), imapsync körd från kommandoraden av webbhotellet eller IT-konsulten, eller konsumentlösningar som GSMMO för migrering till Google Workspace.

Varför datum blir felaktiga efter en cPanel-migrering

För att förstå problemet måste du förstå två olika begrepp: Date:-headern i ett e-postmeddelande och IMAP INTERNALDATE.

Date:-headern skrivs in i själva meddelandets råtext vid sändningstillfället, enligt RFC 2822. Den registrerar när e-postmeddelandet skrevs och skickades. Den här headern ändras aldrig om inte någon avsiktligt ändrar meddelandet.

INTERNALDATE är däremot en metadataegenskap som IMAP-servern kopplar till varje lagrat meddelande. Den är fristående från själva meddelandeinnehållet. När ett e-postmeddelande anländer normalt till en server hämtas INTERNALDATE från Received:-headrarna, eller från leveranstidpunkten om meddelandet lämnas in direkt. Det är detta värde som Outlook, Thunderbird och de flesta e-postklienter använder för att sortera meddelanden.

Under en IMAP-migrering kopieras meddelanden från en server till en annan. Problemet: migreringsverktyget måste skapa varje meddelande på målservern. Och för många verktyg sätts INTERNALDATE för det nyskapade meddelandet till migreringsdatumet, inte det ursprungliga meddelandedatumet. Dessutom läggs en Received:-header med migreringsdatumet till i början av headerkedjan, vilket ytterligare förvirrar e-postklienter som förlitar sig på den för att beräkna visningsdatumet.

Resultatet: ett e-postmeddelande från 2019 hamnar på Google Workspace med en INTERNALDATE satt till migreringsdagen, och en Received:-header stämplad igår. Outlook visar det i inkorgen som om det just anlänt. Hela arkivtidslinjen förstörs.

WHM:s / cPanels migreringsverktyg

Verktyget som är inbyggt i WHM för att migrera cPanel-konton till en annan plattform ger nästan systematiskt upphov till det här problemet när målet är en extern IMAP-server (Google Workspace, Microsoft 365). Det kopierar Maildir-innehåll till den nya servern utan att bevara den ursprungliga INTERNALDATE. Varje meddelande får tidsstämpeln för operationen.

imapsync och manuella migreringar från cPanel

imapsync är ett kraftfullt verktyg, men dess standardbeteende bevarar inte alltid datum. Utan rätt parametrar (och rätt version) kan det utan problem kopiera 40 000 meddelanden och stämpla varenda ett med skriptets körningsdatum. (Om du någon gång har gått igenom imapsync-loggar rad för rad för att diagnostisera ett datumproblem i en postlåda med 25 000 meddelanden vet du att det är en upplevelse du inte vill upprepa.)

För att vara exakt har imapsync faktiskt alternativ för att försöka bevara datum, men de alternativen samverkar olika beroende på käll- och målservrar, och deras effektivitet är inte garanterad i alla cPanel/Dovecot-konfigurationer.

GSMMO och konsumentverktyg

Google Workspace Migration for Microsoft Outlook (GSMMO) är utformat för att migrera från Outlook, inte från en ren IMAP-server. När det används för att migrera från cPanel (via ett IMAP-konto konfigurerat i Outlook) får datumen samma behandling: INTERNALDATE på Google Workspace sätts till migreringsdatumet. GSMMO:s datumproblem är faktiskt dokumenterat separat, det är så vanligt.

Vilka e-postklienter påverkas?

Datumfelet visar sig inte på samma sätt i alla klienter.

Outlook drabbas hårdast. Det använder INTERNALDATE (eller migreringens Received:-header) som primär sorteringsnyckel för mappar. Efter en dåligt hanterad cPanel-migrering kan en Outlook-postlåda visa tusentals arkiverade e-postmeddelanden med datumet för migreringshelgen. Att åtgärda imapsync-migreringsdatum i Outlook är en av de mest efterfrågade korrigeringarna.

Gmail (Google Workspace) visar generellt datumet från Date:-headern i e-postlistan, men sorteringen kan fortfarande påverkas av INTERNALDATE i vissa fall. Användare rapporterar oberäkneligt beteende vid sökning och datumbaserad sortering.

Apple Mail och Thunderbird beter sig mer oregelbundet, men ingen av dem är immun, särskilt när en migrerings Received:-header ligger överst i headerkedjan.

Goda nyheter: det ursprungliga datumet finns fortfarande kvar

Det här är den tekniska detaljen som förändrar allt. Den ursprungliga Date:-headern är skriven i själva meddelandets råtext. Migreringen rör den inte. När du öppnar ett drabbat e-postmeddelande och tittar på de råa headrarna (i Gmail: "Visa original", i Outlook: Arkiv > Egenskaper) kan du se den ursprungliga Date: intakt, följd av en eller flera Received:-headrar där den första bär migreringsdatumet.

Den informationen finns fortfarande kvar. Den kan användas för att fixa metadatan. Det är exakt vad Redate.ios motor för att fixa e-postdatum gör.

Varför att "fixa det själv" är riskablare än det verkar

Frestelsen är verklig. Problemet verkar enkelt: läs det ursprungliga datumet, fixa metadatan, gå vidare. Men det är ett stort steg mellan att förstå mekanismen och att fixa 12 000 produktionsmeddelanden utan att förlora ett enda.

Några realiteter som hemmagjorda skript vanligtvis inte tar hänsyn till:

Ett skript som fungerar på 50 testmeddelanden i en utvecklingsmiljö håller inte nödvändigtvis för 18 000 meddelanden i en produktionspostlåda som ärvts från ett cPanel-konto som körts sedan 2011.

Hur Redate.io fixar datum efter en cPanel-migrering

Redate.io ansluter direkt till målpostlådan (Google Workspace, Microsoft 365 med enkel inloggning, eller direkt IMAP) och börjar med en kostnadsfri genomsökning för att identifiera e-postmeddelanden vars datummetadata inte stämmer med den ursprungliga Date:-headern.

Redate.io identifierar e-postmeddelanden vars visade datum inte stämmer med det ursprungliga datumet, oavsett vilket verktyg som orsakat problemet. Metadatan fixas riktat utan att meddelandets innehåll ändras: brödtext, bilagor och ursprungliga headrar förblir intakta. Varje fixat e-postmeddelande verifieras individuellt innan åtgärden bekräftas.

För cPanel-migreringar specifikt fungerar det här oavsett om det handlar om Dovecot-till-IMAP-migreringar, imapsync-skript eller andra konfigurationsvarianter som är vanliga hos webbhotell.

Specifika guider efter målplattform

Beroende på var din cPanel-migrering hamnade täcker de här guiderna de exakta stegen:

Migrerat från cPanel och dina användare ser fel datum? Kör en kostnadsfri genomsökning på Redate.io för att ta reda på exakt hur många e-postmeddelanden som påverkas, utan att några ändringar görs förrän du godkänner det.