Outlook : date reçue migration IMAP vs date envoyée

Le symptôme que tout le monde connaît

Vous venez de terminer une migration IMAP vers Microsoft 365 ou Google Workspace. Lundi matin, les tickets arrivent : "Tous mes emails ont la même date", "Mon historique est cassé", "Je ne retrouve plus rien dans ma boîte". Vous ouvrez Outlook, et là, effectivement, des milliers d'emails affichent la date du weekend dernier. Pas la date à laquelle ils ont été envoyés. La date à laquelle la migration a eu lieu.

Ce n'est pas un bug Outlook. C'est une conséquence directe du fonctionnement du protocole IMAP et des outils de migration. Mais pour comprendre pourquoi, il faut ouvrir le capot.

Trois dates dans un seul email

Un email, c'est plus complexe qu'il n'y paraît. En-tête, corps du message, pièces jointes... et plusieurs horodatages distincts qui cohabitent. (D'ailleurs, si vous avez déjà essayé de lire les en-têtes bruts d'un email, vous savez que ce n'est pas exactement de la lecture de plage.)

L'en-tête Date: (RFC 2822)

C'est la date que l'expéditeur a mise dans son message au moment de l'envoi. Définie par le RFC 2822, elle ressemble à ça :

Date: Tue, 14 Mar 2023 09:42:17 +0100

Cet en-tête est gravé dans la masse du message. Il ne change jamais, sauf si quelqu'un modifie le contenu brut du message. C'est la "date envoyée" au sens strict.

L'en-tête Received: (ajouté à chaque saut réseau)

Chaque serveur qui touche un email en transit ajoute un en-tête Received: en tête du message, avec sa propre date. Un email qui passe par trois serveurs accumule donc trois en-têtes Received:. Le plus récent est toujours en premier. Ça donne quelque chose comme :

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Résultat : quand un outil de migration comme BitTitan MigrationWiz, CloudM, imapsync ou GSMMO déplace un email d'un serveur source vers un serveur destination, il se comporte lui aussi comme un "saut réseau". Il injecte un nouvel en-tête Received: tout en haut de la pile, avec la date et l'heure de la migration.

L'INTERNALDATE IMAP

C'est la troisième date, et c'est celle qui pose problème. L'INTERNALDATE est une métadonnée stockée côté serveur IMAP, indépendante du contenu du message. Elle représente la date à laquelle l'email a été livré (ou inséré) dans la boîte mail. Quand un outil de migration insère un email via la commande IMAP APPEND, c'est lui qui choisit quelle valeur donner à l'INTERNALDATE. Et dans beaucoup de cas, les outils utilisent la date du moment de la migration. Pas la date originale.

C'est là que tout se grippe.

Pourquoi Outlook affiche la date de migration

Outlook utilise l'INTERNALDATE pour afficher la colonne "Reçu". C'est son comportement par défaut, et il est cohérent avec la spécification IMAP : l'INTERNALDATE est censée représenter la date de réception dans la boîte. Dans un flux normal (un vrai email qui arrive), l'INTERNALDATE est proche de la date dans l'en-tête Date:. Les deux sont cohérentes.

Après une migration ratée, l'INTERNALDATE de tous les emails importés pointe vers la nuit du 14 au 15 juin 2024 (ou quelle que soit la date de migration). Outlook lit cette valeur, l'affiche dans la colonne "Reçu", et le résultat est catastrophique : 45 000 emails semblent avoir été reçus le même soir.

Pour être précis, le premier en-tête Received: (le plus récent dans la pile) influence aussi l'affichage dans certaines configurations. Mais l'INTERNALDATE reste le déterminant principal pour la colonne "Reçu" d'Outlook en mode IMAP synchronisé.

Le contournement "Ajouter la colonne Envoyé" dans Outlook

La première chose que font la plupart des admins IT quand ils découvrent le problème, c'est de chercher un contournement côté client. Et il en existe un, effectivement.

Dans Outlook, on peut modifier l'affichage des colonnes d'un dossier pour remplacer (ou compléter) la colonne "Reçu" par la colonne "Date" ou "Envoyé". La colonne "Date" lit directement l'en-tête Date: du message, pas l'INTERNALDATE. Puisque l'en-tête Date: n'a pas été touché par la migration, les dates originales réapparaissent.

Pour le faire dans Outlook (desktop, version Microsoft 365) : clic droit sur l'en-tête de colonne dans la liste des messages, "Paramètres d'affichage", puis modifier les colonnes pour retirer "Reçu" et ajouter "Date". C'est faisable par GPO pour un déploiement en masse.

Bon. Sur le papier, ça règle le problème visuel. Dans les faits, c'est un pansement sur une artère.

Les limites concrètes de ce contournement

Les clients mobiles et web

Outlook sur iOS, Android, et Outlook Web App (OWA) n'ont pas les mêmes options de personnalisation. La modification de vue que vous avez déployée sur les postes Windows ne se propage pas. Vos utilisateurs qui consultent leurs emails sur leur téléphone continuent de voir la date de migration. Et dans une entreprise de taille moyenne, c'est probablement la moitié des utilisateurs.

La recherche

La recherche Outlook utilise l'index Windows Search (ou l'index Exchange/Microsoft 365 côté serveur). Cet index est construit à partir de l'INTERNALDATE, pas de l'en-tête Date:. Si un utilisateur cherche "emails de janvier 2022", la recherche retourne les emails dont l'INTERNALDATE est en janvier 2022. Pas ceux dont l'en-tête Date: est en janvier 2022. Le résultat : les anciens emails ne remontent plus dans les filtres de date. Changer la colonne d'affichage ne change rien à ça.

Les règles de messagerie

Les règles Outlook ("si l'email a été reçu avant le...", "si l'email a été reçu après le...") utilisent aussi l'INTERNALDATE. Une règle de tri ou d'archivage basée sur des plages de dates ne fonctionnera plus correctement après migration si l'INTERNALDATE n'a pas été corrigée.

Conformité et eDiscovery

C'est peut-être le point le plus sérieux. Les outils de compliance, d'archivage légal, et de eDiscovery (Microsoft Purview, par exemple) utilisent l'INTERNALDATE comme référence de date pour les requêtes légales. Si votre entreprise est soumise à des obligations de rétention ou doit répondre à des demandes de discovery, des INTERNALDATE corrompues peuvent poser de vrais problèmes juridiques. Un audit qui demande "tous les emails entre telle et telle date" ne retournera pas les bons résultats.

Les outils tiers

CRM, outils de ticketing, archiveurs... tout ce qui se connecte à votre serveur mail via IMAP ou les API Microsoft 365/Google Workspace lit l'INTERNALDATE. Changer la vue Outlook ne corrige rien pour ces systèmes.

La seule vraie solution : corriger au niveau du serveur

Le tri par date envoyée dans Outlook n'est pas une solution. C'est un pansement. La vraie correction doit se faire au niveau des métadonnées du serveur, pas de la vue client.

Concrètement, cela signifie corriger l'INTERNALDATE de chaque email pour qu'elle corresponde à la date originale de l'en-tête Date:. L'en-tête Date: original est toujours présent dans le message (il n'a pas été effacé par la migration), ce qui rend la correction possible. C'est là que se trouve l'information de date réelle.

Sur Google Workspace, l'API Gmail expose un paramètre internalDate qui permet d'agir directement sur cette métadonnée. Sur Microsoft 365, le mécanisme est différent mais le résultat attendu est le même. Sur un serveur IMAP standard, la norme prévoit que la date peut être spécifiée lors de l'insertion d'un message.

En pratique, réaliser cette opération sur des dizaines de milliers d'emails en production, sans perte de données, sans doublons, sans casser les fils de discussion ou les labels, en gérant les cas limites (messages signés S/MIME, structures MIME complexes, encodages non-ASCII selon le RFC 2047, pièces jointes volumineuses)... c'est une autre affaire. Un script qui fonctionne sur 50 emails de test ne tiendra pas sur une boîte de 40 000 messages. La gestion des erreurs 429 (quota API dépassé), des timeouts réseau à 2h du matin, des messages dont la structure MIME est déjà partiellement corrompue après migration... tout ça demande une ingénierie sérieuse.

C'est précisément ce que fait Redate.io. Le moteur de correction propriétaire analyse la chaîne d'en-têtes de chaque email, identifie la date originale fiable, et applique une correction ciblée des métadonnées sans toucher au contenu du message. Chaque email corrigé est vérifié individuellement. Les originaux sont conservés dans un dossier de sauvegarde pendant 30 jours, ce qui garantit un rollback possible à tout moment. Ce qu'un script maison ne propose jamais.

Identifier l'outil de migration responsable

Le problème se manifeste de la même façon quelle que soit l'origine de la migration, mais les détails varient selon l'outil utilisé. BitTitan MigrationWiz, CloudM, imapsync et GSMMO ont chacun leur signature dans les en-têtes Received: qu'ils injectent. Le pipeline d'analyse de Redate.io maintient une base de correspondance sur des centaines de signatures d'outils de migration connus pour distinguer l'en-tête de migration du reste de la chaîne de transit légitime.

Si vous ne savez pas quel outil a été utilisé pour votre migration (ça arrive, surtout quand vous reprenez un parc après un autre MSP), le scan gratuit de Redate.io identifie les boîtes affectées et donne une estimation du volume à corriger avant tout engagement.

Pour des contextes spécifiques, des guides détaillés sont disponibles : corriger les dates imapsync dans Outlook, corriger les dates BitTitan dans Outlook, ou encore corriger les dates CloudM dans Outlook.

Que faire maintenant

Si vous lisez cet article après une migration, la bonne nouvelle c'est que l'en-tête Date: original est intact dans chacun de vos emails. Les informations de date réelle sont là, présentes dans chaque message. Le problème est dans les métadonnées, pas dans le contenu. Et les métadonnées, ça se corrige.

Vous pouvez aussi consulter l'article IMAP INTERNALDATE : pourquoi les dates cassent pour aller plus loin sur la mécanique du problème, ou le guide complet sur les dates erronées dans Outlook après migration si vous voulez une vue d'ensemble des cas de figure.

Prêt à corriger les dates de vos boîtes mail ? Lancez un scan gratuit sur Redate.io pour identifier les emails affectés et estimer le volume avant toute correction.