cPanel-migratie: verkeerde datums

De maandagochtend die pijn doet

U heeft zojuist de migratie van een gedeeld cPanel-hosting naar Google Workspace of Microsoft 365 afgerond. Alles leek vlekkeloos verlopen: de mailboxen zijn bereikbaar, gebruikers kunnen inloggen. Dan, rond 9:15, komt het eerste ticket binnen: "Al mijn oude e-mails tonen dezelfde datum, die van het afgelopen weekend." Dan een tweede. Dan tien.

Dit is geen losstaande fout. Het is het directe gevolg van de manier waarop cPanel-migraties omgaan met (of liever gezegd: negeren van) de datummetadata van e-mails.

cPanel, Roundcube, Horde: een bijzondere IMAP-context

Een gedeelde cPanel-hosting is een Linux-server met een IMAP-server (doorgaans Dovecot) en Roundcube of Horde als webmailinterface. Op zich niets uitzonderlijks. Maar deze omgeving heeft een paar eigenschappen die migraties naar enterprise-platformen lastiger maken dan ze lijken.

Ten eerste stapelen cPanel-mailboxen jaren aan e-mails op, soms een decennium. Een klant die zijn domein al sinds 2013 bij een shared hosting heeft, kan diepe archieven hebben. Dat volume, gecombineerd met de manier waarop de migratie wordt uitgevoerd, creëert de ideale voedingsbodem voor datumproblemen.

Ten tweede zijn de tools die voor deze migraties worden gebruikt vaak de ingebouwde migratietool van WHM, imapsync uitgevoerd via de commandoregel door de hoster of IT-partner, of consumentenoplossingen zoals GSMMO voor migraties naar Google Workspace.

Waarom datums beschadigd raken na een cPanel-migratie

Om het probleem te begrijpen, moeten twee afzonderlijke concepten helder zijn: de Date:-header van een e-mail en de IMAP INTERNALDATE.

De Date:-header wordt op het moment van verzending in de ruwe berichttekst geschreven, conform RFC 2822. Die header geeft aan wanneer het bericht is opgesteld en verstuurd. Hij verandert nooit, tenzij het bericht opzettelijk wordt gemanipuleerd.

De INTERNALDATE is een stukje metadata dat de IMAP-server aan elk opgeslagen bericht koppelt, los van de berichtinhoud. Wanneer een e-mail normaal op een server arriveert, wordt de INTERNALDATE afgeleid uit de Received:-headers of uit het moment van aflevering. Outlook, Thunderbird en de meeste andere e-mailclients gebruiken juist deze waarde om berichten te sorteren.

Bij een IMAP-migratie worden berichten van de ene naar de andere server gekopieerd. Het probleem: de migratietool moet elk bericht opnieuw aanmaken op de doelserver. En bij veel tools krijgt de INTERNALDATE van dat nieuw aangemaakte bericht de datum van de migratie, niet die van het originele bericht. Bovendien wordt er een Received:-header met de migratiedatum bovenaan de headerketen toegevoegd, wat e-mailclients die die header raadplegen voor de weergavedatum nog verder in de war brengt.

Resultaat: een e-mail uit 2019 arriveert op Google Workspace met een INTERNALDATE die is ingesteld op de dag van de migratie, en een Received:-header van gisteren. Outlook toont hem in de inbox alsof hij zojuist is binnengekomen. De volledige chronologie van het archief is vernietigd.

De migratietool van WHM / cPanel

De ingebouwde tool in WHM om cPanel-accounts naar een ander platform te verplaatsen, veroorzaakt dit probleem bijna altijd wanneer de bestemming een externe IMAP-server is (Google Workspace, Microsoft 365). Hij kopieert de Maildir-inhoud via IMAP naar de nieuwe server zonder de oorspronkelijke INTERNALDATE te bewaren. Elk bericht krijgt daardoor het tijdstempel van het moment van de operatie.

imapsync en handmatige migraties vanuit cPanel

imapsync is een krachtige tool, maar het standaardgedrag bewaart datums niet altijd. Zonder de juiste parameters (en de juiste versie) kan het probleemloos 40.000 berichten kopiëren en aan elk bericht de uitvoerdatum van het script toekennen. (Als u ooit de logs van imapsync regel voor regel heeft doorgespit om een datumprobleem te diagnosticeren op een mailbox van 25.000 berichten, weet u dat u dat niet snel wilt herhalen.)

Om precies te zijn: imapsync heeft opties om te proberen de datum te bewaren, maar die opties werken anders afhankelijk van de bron- en doelserver, en hun effectiviteit is niet gegarandeerd op alle cPanel / Dovecot-configuraties. Zie ook imapsync: datums niet behouden? voor een uitgebreidere analyse.

GSMMO en consumententools

Google Workspace Migration for Microsoft Outlook (GSMMO) is bedoeld voor migraties vanuit Outlook, niet vanuit een kale IMAP-server. Wanneer het wordt gebruikt om vanuit cPanel te migreren (via een IMAP-account dat in Outlook is geconfigureerd), ondergaan datums dezelfde behandeling: de INTERNALDATE op Google Workspace wordt ingesteld op de migratiedatum. Het GSMMO-datumprobleem is apart gedocumenteerd, zo vaak komt het voor.

Welke e-mailclients worden getroffen?

De datumcorruptie manifesteert zich niet op dezelfde manier in elke client.

Outlook is de meest getroffen client. Hij gebruikt de INTERNALDATE (of de migratie-Received:-header) als primair sorteercriterium voor mappen. Na een slecht uitgevoerde cPanel-migratie kan een Outlook-mailbox duizenden gearchiveerde e-mails tonen met de datum van het migratieweekend. De correctie van imapsync-datums in Outlook is een van de meest aangevraagde hersteloperaties.

Gmail (Google Workspace) toont doorgaans de datum uit de Date:-header in de berichtenlijst, maar de sortering kan toch worden beïnvloed door de INTERNALDATE. Gebruikers melden onregelmatig gedrag bij zoeken en sorteren op datum.

Apple Mail en Thunderbird gedragen zich genuanceerder, maar geen van beide is immuun voor het probleem, zeker niet wanneer de migratie-Received:-header bovenaan de headerketen staat.

Goed nieuws: de originele datum is er nog

Dit is het technische detail dat alles verandert. De originele Date:-header van het bericht staat in de ruwe berichttekst. De migratie raakt hem niet aan. Wanneer u een getroffen e-mail opent en de ruwe headers bekijkt (in Gmail: "Origineel weergeven", in Outlook: Bestand > Eigenschappen), ziet u de originele Date: intact, gevolgd door een of meer Received:-headers waarvan de bovenste de migratiedatum draagt.

Die informatie is er altijd nog. Ze kan worden gebruikt om de metadata te herstellen. Dat is precies wat de correctie-engine van Redate.io doet.

Waarom "dit zelf oplossen" riskanter is dan het lijkt

De verleiding is groot. Het probleem lijkt simpel: de originele datum uitlezen, de metadata corrigeren, door naar het volgende bericht. Maar tussen het begrijpen van het mechanisme en het foutloos corrigeren van 12.000 e-mails in productie zit een wereld van verschil.

Een paar zaken die zelfgeschreven scripts doorgaans niet voorzien:

S/MIME-ondertekende of PGP-versleutelde e-mails: elke wijziging aan de berichtstructuur maakt de cryptografische handtekening ongeldig. Een e-mail die voor de correctie de handtekeningverificatie doorstond, doet dat daarna niet meer. Gebruikers in gereguleerde sectoren (advocatuur, financiën, zorg) ontdekken dit op het slechtst mogelijke moment.
Niet-ASCII-headers en RFC 2047-codering: cPanel-mailboxen bevatten jaren aan e-mails van de meest uiteenlopende e-mailclients. Sommige headers bevatten tekens die zijn gecodeerd conform RFC 2047. Een slecht geschreven script dat headers reconstrueert, kan die coderingen onzichtbaar beschadigen.
Geneste MIME-structuren: een e-mail met drie bijlagen en een alternatieve HTML-body heeft een complexe multipart-structuur. De kleinste fout in de MIME-grenzen maakt het bericht onleesbaar, of erger: bijlagen verdwijnen zonder foutmelding.
API-quota's en rate limiting: Google Workspace en Microsoft 365 hanteren strikte limieten op het aantal IMAP-bewerkingen per minuut. Een script dat exponentiële backoff niet correct implementeert, loopt om 3 uur 's nachts tegen 429-fouten aan, en u wordt 's ochtends wakker met een half voltooide migratie waarvan u niet precies weet waar die is gestopt.
Geen rollback mogelijk: als er halverwege iets misgaat, met welke toestand valt u terug? Zijn de originelen er nog? Heeft u duplicaten? Redate.io bewaart de originelen 30 dagen in een zichtbare back-upmap, zodat u nooit in die situatie belandt.

Een script dat werkt op 50 testmails in een ontwikkelomgeving, werkt niet noodzakelijkerwijs op 18.000 berichten van een productie-mailbox die al sinds 2011 op cPanel-hosting staat.

Hoe Redate.io datums herstelt na een cPanel-migratie

Redate.io maakt rechtstreeks verbinding met de doelmailbox (Google Workspace via domeindelegatie, Microsoft 365 via Azure AD, of een directe IMAP-server) en begint met een gratis scan om e-mails te identificeren waarvan de datummetadata niet overeenkomt met de originele Date:-header.

De multi-stage analysepipeline past daarna patroonherkenning toe op de handtekeningen van Received:-headers om te bepalen welke door migratietools zijn toegevoegd (en die te onderscheiden van legitieme headers). De gerichte metadatacorrectie vindt plaats zonder de berichtinhoud te wijzigen: de tekst, bijlagen en originele headers blijven volledig intact. Elk gecorrigeerd bericht wordt individueel geverifieerd voordat de bewerking wordt bevestigd.

Voor migraties vanuit cPanel specifiek herkent de engine de typische handtekeningen van Dovecot-naar-IMAP-migraties en imapsync-scripts, inclusief de configuratievarianten die gangbaar zijn bij Europese shared hosting-providers.

Specifieke gidsen per doelplatform

Afhankelijk van het doelplatform van uw cPanel-migratie beschrijven de volgende gidsen de exacte stappen:

Heeft u gemigreerd vanuit cPanel en zien uw gebruikers verkeerde datums? Start een gratis scan op Redate.io om precies te zien hoeveel e-mails zijn getroffen, zonder enige wijziging voordat u akkoord gaat.

Verkeerde e-maildatums na cPanel-migratie