Modifier la date d'un email reçu : vrai ou faux ?

La question que tout le monde pose (et pourquoi elle cache deux situations très différentes)

Tapez "modifier la date d'un email reçu" dans Google. Vous tombez sur des dizaines de fils sur les forums Microsoft Q&A, des threads Reddit, des questions Quora. La demande est claire, mais les raisons derrière elle sont radicalement différentes selon qui pose la question.

Il y a ceux qui cherchent à falsifier une date, rétrospectivement, pour des raisons qu'on préfère ne pas imaginer. Et il y a des administrateurs IT qui, après une migration IMAP, voient tous leurs emails afficher le même jour (celui de la migration), et veulent simplement retrouver les vraies dates. Ces deux situations n'ont rien à voir l'une avec l'autre, mais elles partagent la même formulation de recherche.

Cet article répond aux deux. Spoiler : dans le premier cas, la modification n'est pas vraiment possible de façon indétectable. Dans le second, elle est tout à fait légitime et c'est exactement ce que fait Redate.io.

D'abord : qu'est-ce que la "date" d'un email ?

Un email ne contient pas une seule date. Il en contient plusieurs, stockées à des endroits différents, contrôlées par des entités différentes.

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

C'est la date que le client de l'expéditeur inscrit dans le message au moment de l'envoi. Elle est visible dans les en-têtes bruts sous la forme :

Date: Mon, 14 Oct 2024 09:32:11 +0200

Cet en-tête fait partie du corps du message. Il peut techniquement être modifié si vous accédez au fichier brut. Mais "techniquement" est le mot important ici.

Les en-têtes Received:

Chaque serveur de messagerie par lequel passe un email ajoute son propre en-tête Received: avec un timestamp. Ces en-têtes forment une chaîne chronologique, du serveur de l'expéditeur jusqu'à votre boîte. (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. Plusieurs dizaines de lignes de métadonnées techniques, dans un ordre qui va du plus récent au plus ancien.)

L'INTERNALDATE IMAP

C'est la métadonnée la plus importante pour comprendre pourquoi certaines modifications n'ont aucun effet visible. L'INTERNALDATE est un attribut stocké côté serveur IMAP, indépendamment du contenu du message. C'est lui que la plupart des clients mail utilisent pour trier les emails dans les dossiers. Outlook l'utilise. Gmail aussi. Apple Mail, dans la majorité des cas, également.

L'INTERNALDATE n'est pas dans le message. Il est dans la base de données du serveur. Vous ne pouvez pas le modifier en éditant un fichier .eml sur votre disque.

Ce qui se passe vraiment quand vous modifiez localement

Éditer un fichier .eml

Techniquement, un fichier .eml est un fichier texte. Vous pouvez l'ouvrir dans un éditeur, changer la ligne Date:, sauvegarder. Si vous réimportez ce fichier dans un client mail local, la date affichée peut changer, selon le client.

Mais voilà ce que ça ne change pas :

• L'INTERNALDATE sur le serveur IMAP (toujours intact)
• Les en-têtes Received: ajoutés par les serveurs intermédiaires
• Les logs de livraison chez Google, Microsoft, ou votre fournisseur
• La signature DKIM, si le message en avait une

Résultat : sur votre machine locale, vous voyez peut-être une date différente. Depuis Outlook connecté à Exchange Online, ou Gmail dans un navigateur, rien n'a changé.

Changer l'horloge système

Certains forums suggèrent de modifier l'horloge du poste de travail pour "tromper" le client mail. Ça ne fonctionne pas. Outlook et Gmail ne lisent pas l'heure système pour afficher les dates des emails reçus. Ils lisent l'INTERNALDATE depuis le serveur, ou les en-têtes du message. L'horloge locale n'intervient nulle part dans ce processus.

La manipulation via Thunderbird

Thunderbird offre plus de flexibilité que la plupart des clients. Avec des extensions ou en manipulant directement le profil (fichiers mbox, fichiers .msf), certains tentent de modifier l'affichage des dates. Ça peut fonctionner dans Thunderbird lui-même, pour les emails stockés localement en mode POP3. Mais dès que Thunderbird est connecté en IMAP, il resynchronise avec le serveur. La "correction" disparaît à la prochaine synchronisation.

DKIM : la barrière invisible que personne ne mentionne

La plupart des emails envoyés depuis 2018 sont signés avec DKIM (DomainKeys Identified Mail). Une signature DKIM ressemble à ça dans les en-têtes :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Le champ h= liste les en-têtes couverts par la signature. Dans l'exemple ci-dessus, Date est signé. Si vous modifiez l'en-tête Date: du message, la vérification DKIM échoue. N'importe quel serveur de messagerie, n'importe quel outil d'analyse forensique, peut détecter la modification en recalculant la signature.

Ce n'est pas une protection parfaite (un expéditeur malveillant contrôle sa propre clé DKIM et peut signer ce qu'il veut au moment de l'envoi). Mais pour un email déjà reçu et signé, modifier l'en-tête Date: laisse une trace détectable.

Les logs serveur : la vraie source de vérité

Même si vous arriviez à modifier toutes les métadonnées visibles d'un email (en-têtes, INTERNALDATE, tout), les fournisseurs conservent leurs propres logs.

Google Workspace journalise chaque message dans les logs d'audit de la Admin Console. Microsoft 365 fait de même dans le Centre de conformité (Purview). Ces logs incluent les timestamps de livraison, indépendamment de ce qui est affiché dans les clients. Un avocat, un service juridique, ou une équipe de sécurité informatique peut récupérer ces données. La date visible dans Outlook ne fait pas foi devant un tribunal ou lors d'un audit de sécurité.

Pour être précis : même un administrateur qui a accès à la boîte via délégation de domaine ne peut pas réécrire rétrospectivement ces logs. Ils sont hors de portée des utilisateurs, même privilegiés.

Le cas légitime : la correction post-migration

Vous venez de terminer une migration de 150 boîtes depuis un Exchange on-premise vers Microsoft 365. Le lundi suivant, les tickets arrivent : "tous mes anciens emails sont datés du vendredi dernier". La date de la migration.

C'est un problème bien documenté et complètement différent de ce qu'on vient de décrire. Ici, personne ne cherche à falsifier quoi que ce soit. Les vraies dates originales existent toujours, intactes, dans l'en-tête Date: de chaque message. Le problème vient d'ailleurs : l'outil de migration (BitTitan MigrationWiz, CloudM, imapsync, ou un autre) a inséré un en-tête Received: avec la date de migration en tête de la chaîne. Outlook, qui se fie aux en-têtes Received: les plus récents plutôt qu'à l'INTERNALDATE dans certains contextes, affiche cette date à la place.

Dans ce cas, la "correction" consiste à rétablir la cohérence entre ce que le message dit (l'en-tête Date: original, toujours là) et ce que le serveur pense (l'INTERNALDATE, fixé au moment de la migration). Ce n'est pas de la falsification. C'est de la restauration.

C'est exactement ce que fait une migration mal configurée impose comme problème à des milliers de boîtes. Et c'est ce que Redate.io résout.

Pourquoi le "faire soi-même" échoue à l'échelle

Comprendre le problème est une chose. Le corriger sur 40 000 emails répartis sur 150 boîtes sans en perdre un seul, c'en est une autre.

Les scripts qu'on trouve sur GitHub ou Stack Overflow fonctionnent sur 20 emails de test. Ils rencontrent des problèmes en production pour des raisons que l'auteur du script n'avait pas anticipées :

• Les emails signés S/MIME ou chiffrés PGP ont des structures qui ne se manipulent pas comme des messages ordinaires
• Les messages multipart avec des frontières MIME non standard provoquent des erreurs de parsing
• Les en-têtes encodés en RFC 2047 (caractères non-ASCII dans les champs From: ou Subject:) cassent les parsers naïfs
• Les APIs Google et Microsoft imposent des limites de taux (rate limiting) : à 3h du matin pendant un batch de 30 000 emails, l'erreur 429 Too Many Requests n'est pas gérée, le script s'arrête, et personne ne sait où il s'est arrêté
• Aucun mécanisme de rollback : si un message est corrompu pendant le traitement, il n'y a rien pour revenir en arrière

Redate.io conserve une copie de chaque email original dans un dossier de sauvegarde visible pendant 30 jours. Chaque correction est vérifiée individuellement. Le pipeline d'analyse gère des centaines de signatures d'outils de migration connus, ainsi que tous les cas limites qu'un script maison ne traiterait pas.

Pour aller plus loin sur les spécificités selon l'outil utilisé : BitTitan MigrationWiz et les dates d'emails, ou CloudM Migrate : corriger les dates erronées.

Ce qui change, ce qui ne change jamais

La distinction est nette. Les trois premières lignes du tableau décrivent des modifications superficielles ou détectables. La dernière décrit une correction légitime des métadonnées, alignée avec le contenu original du message, après une migration qui a introduit une incohérence.

Si vous êtes dans la situation décrite en bas du tableau, après une migration avec imapsync, BitTitan, CloudM ou un autre outil, Redate.io est fait pour ça.

Vos emails affichent la date de migration à la place des vraies dates ? Scannez gratuitement vos boîtes avec Redate.io et voyez exactement combien d'emails sont concernés avant de décider.