Mauvaises dates email après migration vers Exchange Online

Le scénario classique du lundi matin

Vous venez de finaliser la migration IMAP vers Exchange Online. Le batch s'est terminé sans erreur dans le centre d'administration Exchange, les boîtes sont synchronisées, les utilisateurs peuvent se connecter. Vous fermez votre ordinateur le vendredi soir avec le sentiment du travail accompli.

Lundi matin, les tickets arrivent. "Tous mes emails sont datés du vendredi." "Mon historique de boîte de réception est inutilisable." "Il manque des emails anciens." Il ne manque rien, en réalité : les emails sont là, mais Outlook les affiche tous avec la date de migration au lieu de leur date d'envoi originale. Un email de 2019 apparaît daté du vendredi dernier. Résultat : la boîte entière semble ne contenir que des messages récents.

C'est l'un des problèmes les plus frustrants des migrations IMAP vers Exchange Online, et il est presque systématiquement sous-documenté par Microsoft.

Pourquoi la migration via l'EAC casse les dates

Quand vous utilisez le centre d'administration Exchange (EAC) pour configurer une migration IMAP depuis un serveur local (Dovecot, Courier, Cyrus, UW-IMAP, peu importe), Exchange Online se connecte à votre serveur source via IMAP, récupère les messages, et les injecte dans les boîtes de destination via son propre pipeline de transport interne.

C'est là que le problème se crée.

Chaque email qui transite par le pipeline de transport d'Exchange reçoit automatiquement un en-tête Received: horodaté. C'est un comportement standard des serveurs SMTP et IMAP depuis des décennies : chaque serveur qui touche un message y appose sa signature temporelle. Le problème, c'est qu'Outlook (et en particulier Outlook pour Windows, dans les versions récentes) utilise l'en-tête Received: le plus récent comme référence d'affichage lorsque d'autres métadonnées sont ambiguës.

L'en-tête Date: original (celui qui indique quand l'email a vraiment été envoyé, au sens de la RFC 2822) est toujours présent dans le message. Il n'a pas été supprimé. Mais il se retrouve "éclipsé" par ce nouvel en-tête Received: ajouté par Exchange lors de l'injection.

En parallèle, l'INTERNALDATE IMAP (la métadonnée que les serveurs IMAP utilisent pour dater les messages en interne et qui pilote le tri dans la plupart des clients) est positionnée à la date d'injection, pas à la date originale de l'email. Exchange Online n'a aucun moyen natif de préserver l'INTERNALDATE du serveur source lors d'une migration par batch via l'EAC.

EAC vs. outils tiers : une différence importante

Il faut distinguer deux situations. Avec des outils comme BitTitan MigrationWiz ou CloudM Migrate, le problème existe aussi, mais ces outils ont parfois des options de configuration (partiellement documentées, souvent cachées dans les paramètres avancés) qui tentent de préserver certaines métadonnées de date.

La migration native via l'EAC, elle, n'offre aucune option de ce type. Microsoft n'expose pas de paramètre pour contrôler la préservation de l'INTERNALDATE dans le pipeline de batch migration. C'est une boîte noire : vous configurez le batch, vous le lancez, Exchange fait ce qu'il veut en interne. Et ce qu'il fait, systématiquement, c'est dater les messages à la date de leur injection.

(D'ailleurs, si vous avez déjà essayé de lire les en-têtes bruts d'un email migré via l'EAC, vous savez que le champ Received: ajouté par Exchange est reconnaissable entre mille : il contient des références aux serveurs internes Microsoft comme *.protection.outlook.com ou *.prod.exchangelabs.com, avec un horodatage qui correspond exactement à la fenêtre de migration.)

Pourquoi recréer le batch ne résout rien

La réaction instinctive de beaucoup d'admins IT face à ce problème est de se dire : "Si je supprime les boîtes migrées et que je relance le batch depuis zéro, peut-être que cette fois les dates seront correctes."

C'est compréhensible. Mais ça ne fonctionne pas.

Le problème n'est pas dans la configuration du batch. Il n'est pas dans un paramètre qu'on aurait oublié de cocher. Il est dans l'architecture même du pipeline de transport Exchange, qui est identique à chaque migration. Relancer le batch produira exactement le même résultat : les mêmes en-têtes Received: avec la nouvelle date de migration, et les mêmes INTERNALDATE incorrects. Vous aurez perdu du temps et les utilisateurs auront été dérangés une deuxième fois pour rien.

Certains admins tentent aussi de modifier les paramètres de tri dans Outlook ("trier par date d'envoi" plutôt que "date de réception"). Le tri par date d'envoi n'est pas une solution. C'est un pansement. L'en-tête Date: et l'INTERNALDATE restent incorrects pour les clients qui ne permettent pas ce réglage, pour OWA, pour Outlook Mobile, et pour toute application tierce qui accède à la boîte via IMAP ou EWS.

Ce qui se passe réellement dans les en-têtes

Voici un exemple simplifié de ce que contient un email après migration via l'EAC. L'en-tête original :

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@anciendomaine.fr
Subject: Rapport Q1 2019

Après migration, le message reçoit en tête de chaîne quelque chose comme :

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook voit cet en-tête Received: en premier (il est ajouté en haut du bloc d'en-têtes), l'interprète comme la date la plus récente de traitement du message, et l'affiche comme date de réception. L'en-tête Date: original de 2019 est toujours là, intact, quelques lignes plus bas. Mais Outlook ne l'utilise pas pour l'affichage dans la liste des messages.

Pour être précis : le comportement varie légèrement selon les versions d'Outlook. Les versions post-2021 (et surtout le nouvel Outlook pour Windows déployé depuis fin 2023) sont particulièrement sensibles à ce problème parce qu'elles s'appuient davantage sur les métadonnées Exchange Graph que sur l'en-tête Date: brut. Ce qui veut dire que des migrations qui ne causaient pas de problème visible avec Outlook 2016 peuvent maintenant poser problème avec le nouvel Outlook.

Qui est vraiment affecté

Les serveurs IMAP sources les plus courants dans ce type de migration sont Dovecot (très répandu en environnement Linux/cPanel) et Courier. Les deux exposent des INTERNALDATE via IMAP que l'EAC ne préserve pas. Si vous migrez depuis un serveur Exchange on-premises vers Exchange Online (migration hybride ou cutover), le comportement est différent parce que Microsoft utilise un protocole de transport interne (MAPI/EWS) qui préserve mieux les métadonnées. C'est la migration IMAP générique via l'EAC qui pose problème.

Les utilisateurs les plus touchés sont ceux qui ont des boîtes avec un historique long (5 ans et plus) et un volume élevé de messages. Un utilisateur avec 300 emails dans sa boîte s'en remettra vite. Un directeur commercial avec 12000 emails classés par date, dont il dépend quotidiennement pour retrouver des échanges clients, lui, est paralysé.

Pourquoi un script maison est une mauvaise idée ici

Certains admins IT qui comprennent le problème technique sont tentés d'écrire un script PowerShell ou Python pour corriger les en-têtes manuellement. Le concept de base peut paraître simple une fois qu'on a identifié le mécanisme. Mais la réalité d'une correction en production est une autre affaire.

D'abord, les cas limites. Les emails signés S/MIME et les messages chiffrés PGP ont une structure qui ne tolère pas la modification des en-têtes sans invalider la signature. Les messages multipart/alternative avec des frontières MIME mal formées (fréquents sur les vieux serveurs Courier) peuvent être corrompus par un script qui modifie le message sans reconstruire correctement la structure. Les en-têtes non-ASCII encodés selon la RFC 2047 (noms d'expéditeurs avec des caractères accentués ou japonais, par exemple) sont une source d'erreurs classique.

Ensuite, le volume. Un script qui fonctionne sur 50 emails de test en environnement de développement ne gère pas les limites de taux de l'API Exchange Online en production. L'erreur 429 Too Many Requests à 2h du matin pendant un batch de 8000 messages, sans mécanisme de reprise, c'est une nuit blanche et potentiellement des messages en double ou perdus.

Et surtout : comment vérifier que chaque email corrigé est intact ? Qu'aucune pièce jointe n'a été tronquée, qu'aucun fil de discussion n'est cassé, que les labels et dossiers sont préservés ? Sans mécanisme de validation individuel, on espère juste que tout s'est bien passé.

La correction de dates après migration est un problème qui ressemble à un script de 50 lignes mais qui en demande des milliers pour être fiable en production.

Ce que Redate.io fait différemment

Redate.io se connecte à Exchange Online via les API Microsoft 365 (Azure Active Directory, permissions de délégation au niveau du tenant) et scanne les boîtes concernées pour identifier les emails dont les métadonnées de date ont été corrompues par la migration. Cette étape de scan est gratuite et donne une vision exacte de l'étendue du problème : nombre de messages affectés, boîtes concernées, plage de dates corrompues.

Le moteur de correction propriétaire de Redate.io traite ensuite chaque email individuellement via un pipeline d'analyse multi-étapes qui inclut une correspondance de motifs sur des signatures d'outils de migration connus (dont le pipeline de transport Exchange Online), une validation de conformité RFC, et une vérification de l'intégrité structurelle du message avant et après correction. Les emails S/MIME signés, les structures MIME complexes, les encodages non-standard : tous sont gérés par des chemins de traitement spécifiques.

Chaque message corrigé est vérifié individuellement. Les originaux sont conservés dans un dossier de sauvegarde visible pendant 30 jours. Si quelque chose ne va pas avec un message particulier, il n'est pas modifié : Redate.io signale l'anomalie au lieu de risquer une corruption.

La tarification est basée sur le volume, en paiement unique par boîte. Pas d'abonnement, pas de frais récurrents. Vous corrigez le problème une fois, c'est terminé.

Pour les migrations Exchange Online spécifiquement, Redate.io prend en charge la connexion via les permissions d'application Azure AD (sans avoir à créer des credentials individuels par boîte), ce qui rend le traitement de grandes flottes de boîtes beaucoup plus simple à orchestrer pour un admin IT ou un MSP.

Si vous gérez plusieurs clients qui ont subi ce type de migration, consultez aussi le guide complet sur la correction des dates après migration Microsoft 365 pour une vue d'ensemble des différents scénarios couverts.

Les emails sont là, les dates originales aussi. Lancez un scan gratuit sur Redate.io pour voir exactement combien de messages sont affectés dans vos boîtes Exchange Online, avant de décider quoi faire.