Les trois dates à l'intérieur de chaque email
Chaque email stocké sur un serveur IMAP porte au moins trois valeurs de date distinctes. Comprendre comment ces dates fonctionnent, et comment les clients de messagerie choisissent laquelle afficher, est la clé pour comprendre pourquoi la migration casse les dates. Cet article est une analyse technique approfondie du système de dates IMAP, destinée aux administrateurs informatiques et à toute personne souhaitant comprendre la cause profonde des problèmes de dates post-migration.
1. L'en-tête "Date" RFC 2822
L'en-tête "Date" est défini dans la RFC 2822 (format des messages Internet). Il est défini par le client de messagerie de l'expéditeur au moment où le message est composé et envoyé. Cet en-tête fait partie du corps du message lui-même, il voyage avec le message et n'est jamais modifié par les serveurs de messagerie sur le trajet de livraison. Un en-tête Date typique ressemble à :
Date: Mon, 15 Jan 2024 09:32:17 +0100
L'en-tête Date représente la "date d'envoi" du message. C'est la date la plus fiable car elle est définie une seule fois et jamais altérée. Cependant, elle reflète l'horloge de l'expéditeur, qui peut être mal configurée. Dans de rares cas, l'en-tête Date peut être tôtalement absent (en particulier dans les notifications système automatisées ou les messages mal formés).
2. L'IMAP INTERNALDATE
L'INTERNALDATE est défini dans la RFC 3501 (protocole IMAP4rev1). C'est une valeur de métadonnée côté serveur qui représente la date et l'heure auxquelles le message a été livré au serveur. Contrairement à l'en-tête Date, l'INTERNALDATE ne fait pas partie du message email lui-même. Il est stocké séparément par le serveur IMAP comme métadonnée.
Quand un email est livré normalement (pas migré), le serveur IMAP définit l'INTERNALDATE à l'heure courante au moment de la livraison. Cette valeur correspond de près à l'en-tête Date, généralement à quelques secondes ou minutes près. Les clients de messagerie utilisent souvent l'INTERNALDATE comme "date de réception" car il reflète le moment où le serveur a réellement reçu le message.
Et c'est là que ça devient intéressant. Quand un message est inséré via la commande IMAP APPEND (ce qu'utilisent les outils de migration), la commande APPEND permet au client de spécifier l'INTERNALDATE explicitement. Les outils de migration bien conçus utilisent cette fonctionnalité pour préserver l'INTERNALDATE d'origine du serveur source. Mais même quand l'INTERNALDATE est correctement défini, le problème d'en-tête "Received" (décrit ci-dessous) peut quand même écraser la date affichée dans de nombreux clients.
3. La chaîne d'en-têtes "Received"
Chaque fois qu'un email passe par un serveur de messagerie, ce serveur ajoute un en-tête "Received" au début du message. Cela crée une chaîne d'en-têtes Received qui enregistre le parcours de l'email de l'expéditeur au destinataire. Le plus récent (en haut) montre le dernier serveur qui a traité le message, et le plus ancien (en bas) montre le premier.
Un email normal peut avoir 3 à 6 en-têtes Received, documentant le voyage depuis le serveur sortant de l'expéditeur à travers les relais jusqu'au serveur entrant du destinataire. Chaque en-tête Received inclut un horodatage. Voici un exemple simplifié :
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Comment les clients de messagerie choisissent quelle date afficher
Outlook (Bureau, Web, Mobile)
Microsoft Outlook utilise une combinaison de l'INTERNALDATE et de l'en-tête "Received" le plus récent pour déterminer la date de "Réception" affichée dans la boîte de réception. En pratique, Outlook tend à privilégier l'horodatage de l'en-tête Received le plus récent pour la colonne "Reçu". La colonne "Envoyé" utilise l'en-tête Date. Comme Outlook trie par défaut par la colonne "Reçu", c'est l'horodatage de l'en-tête Received que les utilisateurs voient en premier.
Apple Mail
Apple Mail sur macOS et iOS utilise principalement l'IMAP INTERNALDATE pour afficher la date. Si l'INTERNALDATE a été correctement préservé pendant la migration, Apple Mail peut afficher la bonne date, mais uniquement si l'INTERNALDATE a été explicitement défini lors de l'opération APPEND. Si l'outil de migration n'a pas défini l'INTERNALDATE, le serveur utilise par défaut l'heure d'insertion (la date de migration). Pour les détails sur l'impact pour les utilisateurs Apple Mail, voir Apple Mail : mauvaise date après migration.
Thunderbird
Mozilla Thunderbird offre le plus de flexibilité. Il peut afficher à la fois "Date" (depuis l'en-tête Date) et "Reçu" (depuis les en-têtes Received). Par défaut, Thunderbird affiche la valeur de l'en-tête Date, ce qui signifie que les dates peuvent apparaître correctes dans Thunderbird même quand elles sont fausses dans Outlook. La colonne "Reçu" dans Thunderbird affiche toujours la date de migration. Voir Thunderbird : mauvaise date après migration pour plus de détails.
Interface web Gmail
Le client web de Gmail utilise l'en-tête Date pour son affichage principal de la date. Cela signifie que Gmail web montre souvent des dates correctes même après migration. Mais l'IMAP INTERNALDATE sur le serveur Gmail est quand même incorrect, ce qui affecté chaque client IMAP qui se connecte à ce compte Gmail. La différence entre Gmail web et Outlook ou Apple Mail est une source de confusion fréquente, et une qui fait perdre beaucoup de temps de dépannage aux administrateurs.
Pourquoi IMAP APPEND casse les dates
Ce qui se passe pendant la migration
Quand un outil de migration déplacé un email du Serveur A au Serveur B, l'outil se connecte au Serveur A via IMAP et télécharge le message brut, puis se connecte au Serveur B et utilise la commande APPEND pour l'insérer. Pendant cette insertion, le Serveur B traité le message entrant et ajoute un nouvel en-tête Received avec l'horodatage courant : la date de migration. C'est le comportement IMAP standard défini dans le protocole. Le serveur traité chaque APPEND comme une nouvelle livraison de message.
Le résultat : une chaîne d'en-têtes contaminée
Après migration, les en-têtes Received de l'email ressemblent à ceci :
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
L'en-tête Received de l'outil de migration est maintenant l'entrée la plus haute. Tout client de messagerie qui utilise l'en-tête Received le plus récent pour déterminer la date d'affichage (Outlook, en particulier) affichera "11 avril 2025" au lieu de "15 janvier 2024". L'en-tête Date d'origine et les en-têtes Received d'origine sont toujours intacts en dessous, mais ils ne sont plus dans la position que les clients de messagerie privilégient.
Même une bonne gestion de l'INTERNALDATE n'empêche pas ça
Certains outils de migration définissent correctement l'INTERNALDATE pendant l'APPEND. Par exemple, imapsync préservé explicitement l'INTERNALDATE du serveur source. Mais l'en-tête Received est ajouté par le serveur de destination, pas par l'outil de migration. L'outil de migration n'a aucun contrôle sur ce comportement. Même avec une préservation parfaite de l'INTERNALDATE, l'en-tête Received le plus haut contient toujours la date de migration, et des clients comme Outlook affichent toujours la mauvaise date.
Bref, que peut-on concretement y faire ?
Quels outils de migration ajoutent des en-têtes Received
Tous les outils de migration IMAP causent ce problème car l'en-tête Received est ajouté par le serveur de destination, pas par l'outil lui-même. Le contenu de l'en-tête ajoute varie selon l'outil et le serveur.
BitTitan MigrationWiz ajoute un en-tête Received contenant "mx.migrationwiz.com". CloudM Migrate ajoute des en-têtes référençant "cloudm.io". imapsync déclenche un en-tête Received générique du serveur de destination. GSMMO ajoute des en-têtes avec des références "gmailapi.google.com".
La correction : restaurer les dates correctes
La bonne nouvelle, c'est que l'information de date correcte existe toujours dans chaque email. L'en-tête Date d'origine est intact. Les en-têtes Received d'origine sont intacts. Le problème est qu'un en-tête contaminant est assis au-dessus d'eux.
Le moteur de correction propriétaire de Redate.io analyse la chaîne complète d'en-têtes de chaque email concerne, appliquant une correspondance de signatures sur des centaines de signatures d'outils de migration connus pour identifier exactement quels en-têtes necesitent une correction. Le pipeline d'analyse multi-étapes gère les cas limites qui font échouer les approches plus simples : messages signés S/MIME, contenu chiffré PGP, structures multipart/alternative, problèmes de Content-Transfer-Encoding, en-têtes non-ASCII (RFC 2047), pieces jointes surdimensionnées et limites MIME corrompues.
Après correction, chaque email passe par un processus de vérification d'intégrité pour confirmer que la structure, le contenu et les pieces jointes du message sont préservés à l'identique. Les originaux sont conservés dans un dossier de sauvegarde visible pendant 30 jours.
Pourrait-on écrire un script pour tenter cette correction soi-même ? Techniquement, oui. Mais la différence entre "ca marche sur 95 % des emails" et "ca marche sur 100 % des emails sans en corrompre un seul" représente des mois de developpement. Et quand on parle de la boîte aux lettres complète de quelqu'un, un taux d'échec de 5 % signifie des centaines de messages silencieusement endommages sans moyen de vérifier ce qui a mal tourné.
Vous voulez savoir combien d'emails dans votre boîte ont des dates fausses ? Lancez une analyse gratuite avec Redate.io pour obtenir un comptage instantane des emails concernés, sans paiement requis.