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 clienți de email 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 probleme de date post-migration.
1. L'headerul "Date" RFC 2822
L'headerul "Date" est défini dans la RFC 2822 (format des messages Internet). Il est défini par le client de email 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 servere de email 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 "data trimiterii" 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 clienți de email utilisent souvent l'INTERNALDATE comme "data primirii" 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 instrumente de migrare), la commande APPEND permet au client de spécifier l'INTERNALDATE explicitement. Les instrumente de migrare 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'headerul "Received" (décrit ci-dessous) peut quand même écraser la date affichée dans de nombreux clients.
3. La chaîne d'headerele "Received"
Chaque fois qu'un email passe par un server de email, ce serveur ajoute un headerul "Received" au début du message. Cela crée une chaîne d'headerele 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 headerele Received, documentant le voyage depuis le serveur sortant de l'expéditeur à travers les relais jusqu'au serveur entrant du destinataire. Chaque headerul 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 clienți de email choisissent quelle date afficher
Outlook (Bureau, Web, Mobile)
Microsoft Outlook utilise une combinaison de l'INTERNALDATE et de l'headerul "Received" le plus récent pour déterminer la date de "Réception" affichée dans la inbox. En pratique, Outlook tend à privilégier l'horodatage de l'headerul 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'headerul 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 data corectă, mais uniquement si l'INTERNALDATE a été explicitement défini lors de l'opération APPEND. Si l'instrument de migrare n'a pas défini l'INTERNALDATE, le serveur utilise par défaut l'heure d'insertion (la data migrării). Pour les détails sur l'impact pour les utilisateurs Apple Mail, voir Apple Mail : data greșită 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 headerele 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 data migrării. Voir Thunderbird : data greșită 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 datele corecte 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 instrument de migrare 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 headerul Received avec l'horodatage courant : la data migrării. 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 headerele 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'headerul Received de l'instrument de migrare est maintenant l'entrée la plus haute. Tout client de email qui utilise l'headerul 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 headerele Received d'origine sont toujours intacts en dessous, mais ils ne sont plus dans la position que les clienți de email privilégient.
Même une bonne gestion de l'INTERNALDATE n'empêche pas ça
Certains instrumente de migrare définissent correctement l'INTERNALDATE pendant l'APPEND. Par exemple, imapsync préservé explicitement l'INTERNALDATE du serveur source. Mais l'headerul Received est ajouté par le serveur de destination, pas par l'instrument de migrare. L'instrument de migrare n'a aucun contrôle sur ce comportement. Même avec une préservation parfaite de l'INTERNALDATE, l'headerul Received le plus haut contient toujours la date de migration, et des clients comme Outlook affichent toujours la data greșită.
Bref, que peut-on concretement y faire ?
Quels instrumente de migrare ajoutent des headerele Received
Tous les instrumente de migrare IMAP causent ce problème car l'headerul 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 headerul Received contenant "mx.migrationwiz.com". CloudM Migrate ajoute des en-têtes référençant "cloudm.io". imapsync déclenche un headerul 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 datele corecte
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 headerele Received d'origine sont intacts. Le problème est qu'un en-tête contaminant est assis au-dessus d'eux.
Le motor de corecție proprietar de Redate.io analyse la chaîne complète d'en-têtes de chaque email concerne, appliquant une potrivirea semnăturilor sur des centaines de signatures d'instrumente de migrare connus pour identifier exactement quels en-têtes necesitent une correction. Le pipeline de analiză multi-etapă 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 verificare de integritate 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 căsuță de email 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 ? Lansați o analiză gratuită avec Redate.io pour obtenir un comptage instantane des emails concernés, sans paiement requis.