Migration cPanel : emails mal datés

Le lundi matin qui fait mal

Vous venez de finaliser la migration d'un hébergement mutualisé cPanel vers Google Workspace ou Microsoft 365. L'opération s'est bien passée, les boîtes sont accessibles, les utilisateurs se connectent. Puis, vers 9h15, le premier ticket tombe : "Mes emails anciens affichent tous la même date, celle du week-end dernier." Puis un deuxième. Puis dix.

Ce n'est pas un bug isolé. C'est la conséquence directe de la façon dont les migrations depuis cPanel traitent (ou plutôt ne traitent pas) les métadonnées de date des emails.

cPanel, Roundcube, Horde : un contexte IMAP particulier

Un hébergement mutualisé cPanel, c'est un serveur Linux qui fait tourner un serveur IMAP (généralement Dovecot) avec Roundcube ou Horde comme interface webmail. Rien d'exotique là-dedans. Mais ce contexte a quelques particularités qui rendent les migrations vers des plateformes enterprise plus délicates qu'elles n'y paraissent.

D'abord, les boîtes cPanel accumulent souvent des emails sur des années, parfois une décennie. Un client qui hébergeait son domaine chez un mutualisé depuis 2013 peut avoir des archives très profondes. Ce volume, combiné à la manière dont la migration est effectuée, crée un terrain fertile pour le problème de dates.

Ensuite, les outils utilisés pour ces migrations sont souvent soit l'outil natif de cPanel (le "Migrations" de WHM), soit imapsync lancé en ligne de commande par l'hébergeur ou le prestataire IT, soit des solutions grand public comme GSMMO pour migrer vers Google Workspace.

Pourquoi les dates sont corrompues après une migration cPanel

Pour comprendre le problème, il faut saisir deux concepts distincts : l'en-tête Date: d'un email et l'INTERNALDATE IMAP.

L'en-tête Date: est inscrit dans le corps brut du message au moment de son envoi, conformément à la RFC 2822. Il indique quand l'email a été rédigé et envoyé. Cet en-tête ne change jamais, sauf manipulation volontaire du message.

L'INTERNALDATE, lui, est une métadonnée que le serveur IMAP associe à chaque message stocké. Elle est distincte du contenu du message. Quand un email arrive normalement sur un serveur, l'INTERNALDATE est défini à partir des en-têtes Received: du message, ou à la date de dépôt si le message est soumis directement. C'est cette valeur qu'Outlook, Thunderbird, et la plupart des clients mail utilisent pour trier les messages.

Lors d'une migration IMAP, les messages sont copiés d'un serveur à l'autre. Le problème : l'outil de migration doit créer chaque message sur le serveur de destination. Et pour beaucoup d'outils, l'INTERNALDATE du message nouvellement créé correspond à la date de la migration, pas à la date originale du message. En parallèle, un en-tête Received: horodaté à la date de migration est ajouté en haut de la chaîne d'en-têtes, ce qui perturbe encore davantage les clients mail qui s'y réfèrent pour calculer la date à afficher.

Résultat : un email de 2019 arrive sur Google Workspace avec un INTERNALDATE fixé au jour de la migration, et un en-tête Received: estampillé hier. Outlook l'affiche dans la boîte de réception comme s'il venait d'arriver. Toute la chronologie de l'archivage est détruite.

L'outil de migration WHM / cPanel

L'outil intégré à WHM pour migrer les comptes cPanel vers une autre plateforme génère ce problème de manière quasi systématique quand la destination est un serveur IMAP externe (Google Workspace, Microsoft 365). Il copie le contenu des Maildir sur le nouveau serveur via IMAP APPEND sans préserver l'INTERNALDATE original. Chaque message reçoit donc l'horodatage du moment de l'opération.

imapsync et les migrations manuelles depuis cPanel

imapsync est un outil puissant, mais son comportement par défaut ne préserve pas toujours les dates. Sans les bons paramètres (et la bonne version), il peut très bien copier 40 000 messages en leur attribuant à tous la date d'exécution du script. (D'ailleurs, si vous avez déjà parcouru les logs d'imapsync ligne par ligne pour diagnostiquer un problème de dates sur une boîte de 25 000 messages, vous savez que c'est une expérience qu'on ne cherche pas à répéter.)

Pour être précis, imapsync dispose d'options pour tenter de préserver la date, mais ces options interagissent différemment selon les serveurs source et destination, et leur efficacité n'est pas garantie sur toutes les configurations cPanel / Dovecot.

GSMMO et les outils grand public

Google Workspace Migration for Microsoft Outlook (GSMMO) est prévu pour migrer depuis Outlook, pas depuis un serveur IMAP nu. Quand il est utilisé pour migrer depuis cPanel (via un compte IMAP configuré dans Outlook), les dates subissent le même traitement : l'INTERNALDATE sur Google Workspace est fixé à la date de migration. Le problème GSMMO et les dates d'emails est d'ailleurs documenté séparément, tant il est répandu.

Quels clients mail sont affectés ?

La corruption des dates ne se manifeste pas de la même façon selon le client utilisé.

Outlook est le client le plus affecté. Il utilise l'INTERNALDATE (ou l'en-tête Received: de migration) comme critère de tri principal pour les dossiers. Après une migration cPanel mal gérée, une boîte sous Outlook peut afficher des milliers d'emails archivés avec la date du week-end de migration. La correction des dates imapsync dans Outlook est l'une des corrections les plus demandées.

Gmail (Google Workspace) affiche généralement la date issue de l'en-tête Date: dans la liste des emails, mais le tri peut quand même être affecté par l'INTERNALDATE selon les cas. Les utilisateurs signalent des comportements erratiques dans la recherche et le tri par date.

Apple Mail et Thunderbird ont des comportements plus nuancés, mais ni l'un ni l'autre ne sont immunisés contre le problème, surtout quand l'en-tête Received: de migration est présent en tête de chaîne.

Bonne nouvelle : la date originale est toujours là

C'est le détail technique qui change tout. L'en-tête Date: original du message est inscrit dans le corps brut de l'email. La migration ne le touche pas. Quand vous ouvrez un email affecté et que vous regardez les en-têtes bruts (dans Gmail : "Afficher l'original", dans Outlook : Fichier > Propriétés), vous voyez le Date: original intact, suivi d'un ou plusieurs en-têtes Received: dont le premier porte la date de migration.

Cette information est toujours présente. Elle peut être exploitée pour corriger les métadonnées. C'est exactement ce que fait le moteur de correction de Redate.io.

Pourquoi "corriger ça soi-même" est plus risqué qu'il n'y paraît

La tentation est forte. Le problème paraît simple : lire la date originale, corriger les métadonnées, passer au suivant. Mais entre comprendre le mécanisme et corriger 12 000 emails en production sans en perdre un seul, il y a un écart considérable.

Quelques réalités que les scripts maison n'anticipent généralement pas :

Emails S/MIME signés ou PGP chiffrés : toute modification de la structure du message invalide la signature cryptographique. Un email qui passait la vérification de signature avant correction ne la passe plus après. Les utilisateurs en conformité réglementaire (cabinet d'avocats, secteur financier, santé) découvrent ce problème au pire moment.
En-têtes non-ASCII et encodage RFC 2047 : les boîtes cPanel accumulent des années d'emails provenant de clients mail très variés. Certains en-têtes contiennent des caractères encodés selon RFC 2047. Un script mal écrit qui reconstruit les en-têtes peut corrompre ces encodages de façon invisible.
Structures MIME imbriquées : un email avec trois pièces jointes et un corps HTML alternatif a une structure multipart complexe. La moindre erreur sur les frontières MIME rend le message illisible, ou pire : les pièces jointes disparaissent sans message d'erreur.
Quotas API et rate limiting : Google Workspace et Microsoft 365 imposent des limites strictes sur le nombre d'opérations IMAP par minute. Un script qui n'implémente pas correctement le backoff exponentiel déclenche des erreurs 429 à 3h du matin, et vous vous réveillez avec une migration à moitié terminée dont vous ne savez pas exactement où elle s'est arrêtée.
Rollback impossible : si quelque chose tourne mal à mi-parcours, avec quel état revenez-vous ? Les originaux sont-ils encore là ? Avez-vous des doublons ? Redate.io conserve les originaux dans un dossier de sauvegarde visible pendant 30 jours, précisément pour ne jamais se retrouver dans cette situation.

Un script qui fonctionne sur 50 emails de test dans un environnement de dev ne fonctionnera pas nécessairement sur 18 000 messages d'une boîte de production héritée d'un hébergement cPanel depuis 2011.

Comment Redate.io corrige les dates après migration cPanel

Redate.io se connecte directement à la boîte de destination (Google Workspace via délégation de domaine, Microsoft 365 via Azure AD, ou serveur IMAP direct) et commence par un scan gratuit pour identifier les emails dont les métadonnées de date sont incohérentes avec l'en-tête Date: original.

Le pipeline d'analyse multi-étapes applique ensuite une correspondance de motifs sur les signatures d'en-têtes Received: pour identifier ceux introduits par les outils de migration (et les distinguer des en-têtes légitimes). La correction ciblée des métadonnées s'effectue sans altération du contenu du message : le texte, les pièces jointes, les en-têtes originaux, tout reste intact. Chaque email corrigé est vérifié individuellement avant que l'opération soit validée.

Pour les migrations depuis cPanel spécifiquement, le moteur reconnaît les signatures typiques des migrations Dovecot-vers-IMAP et des scripts imapsync, y compris les variantes de configuration courantes chez les hébergeurs mutualisés français et européens.

Guides spécifiques selon votre destination

Selon la plateforme de destination de votre migration cPanel, les guides suivants décrivent les étapes précises :

Vous avez migré depuis cPanel et vos utilisateurs voient des dates incorrectes ? Lancez un scan gratuit sur Redate.io pour identifier exactement combien d'emails sont affectés, sans aucune modification avant votre accord.

Emails mal datés après migration cPanel / Roundcube