Changer la date de réception d'un mail : limites techniques

Un email a trois "dates". Pas une.

Quand on parle de "changer la date de réception d'un mail", la plupart des gens imaginent modifier un champ quelque part, comme on modifierait la date de création d'un fichier sous Windows. La réalité est un peu plus compliquée. Un email transporte en réalité trois couches de datation distinctes, chacune avec ses propres règles, ses propres gardiens, et ses propres conséquences si on y touche.

Comprendre ces trois couches, c'est comprendre pourquoi certaines corrections sont techniquement saines, et d'autres sont soit impossibles, soit immédiatement détectables comme falsifications.

Couche 1 : l'INTERNALDATE IMAP

L'INTERNALDATE est une métadonnée stockée côté serveur, en dehors du message lui-même. Elle ne fait pas partie du contenu de l'email. C'est le serveur IMAP qui la définit, et c'est elle que la plupart des clients mail utilisent pour trier vos emails dans leur liste.

Outlook, par exemple, affiche par défaut les messages triés par INTERNALDATE. Gmail aussi, dans certains contextes. Du coup, si votre INTERNALDATE est fausse, tous vos emails semblent avoir la même date dans l'interface, peu importe ce que disent les en-têtes internes du message.

L'INTERNALDATE est définie au moment où le message est déposé sur le serveur. Via le protocole IMAP, la seule façon de la "modifier" est indirecte : il faut utiliser la commande APPEND pour déposer une nouvelle copie du message avec la date souhaitée. Il n'existe pas de commande IMAP SETINTERNALDATE. Ce détail aura son importance dans un moment.

Couche 2 : l'en-tête Date: (RFC 2822)

C'est le champ Date: dans les en-têtes bruts du message. Il est défini par le client mail au moment de l'envoi, et il voyage avec le message de serveur en serveur. C'est la date d'envoi déclarée par l'expéditeur.

(D'ailleurs, si vous n'avez jamais regardé les en-têtes bruts d'un email, c'est une lecture assez dépaysante. Chaque message traîne une vingtaine de lignes techniques que 99 % des gens n'ont jamais vues.)

Techniquement, rien n'empêche d'envoyer un email avec un champ Date: antidaté ou postdaté. Les serveurs SMTP ne valident pas ce champ. Mais les serveurs destinataires, eux, notent l'heure d'arrivée réelle dans les en-têtes Received:, ce qui crée immédiatement une incohérence visible par n'importe quel client de messagerie ou outil d'analyse.

Couche 3 : les en-têtes Received: empilés

Chaque fois qu'un serveur SMTP relaie un message, il ajoute un en-tête Received: en haut de la pile, avec un timestamp. Un email passé par trois serveurs aura trois en-têtes Received:. Ils sont lus du bas vers le haut : le plus ancien est en bas, le plus récent est en haut.

C'est précisément là que les outils de migration créent le problème. Quand BitTitan MigrationWiz, CloudM, imapsync ou GSMMO migrent un email, ils le réinjectent sur le nouveau serveur via IMAP. Ce dépôt génère une nouvelle entrée Received: horodatée au moment de la migration. Résultat : le message le plus ancien de votre boîte, un email de 2019, se retrouve avec un Received: daté de novembre 2024. Et comme certains clients mail (Outlook en tête) utilisent le Received: le plus récent comme date d'affichage...

Voilà le problème. 15000 emails affichent tous la même date de migration.

Peut-on vraiment "modifier" ces dates ?

Techniquement, oui pour l'INTERNALDATE (avec des contraintes). Techniquement possible mais inutile pour le Date:. Et pour les Received:, ça mérite qu'on s'y attarde.

Réécrire un en-tête Received: est trivial. Et immédiatement détectable.

Un en-tête Received: n'est qu'une ligne de texte dans le message. On peut l'éditer comme n'importe quel fichier texte. C'est exactement aussi simple que ça en a l'air.

Mais voilà ce qui se passe ensuite.

Premier problème : DKIM. La signature DKIM (DomainKeys Identified Mail) est calculée sur un ensemble d'en-têtes du message, y compris parfois les Received:. Modifier un en-tête signé invalide la signature. N'importe quel serveur destinataire qui vérifie DKIM verra immédiatement que le message a été altéré. Ce n'est pas une falsification subtile, c'est une alarme.

Deuxième problème : les identifiants internes. Les serveurs de messagerie modernes (Google Workspace, Microsoft 365) assignent à chaque message un identifiant interne croissant et unique. Ces identifiants sont liés à l'INTERNALDATE et à l'ordre de réception. Modifier un Received: sans cohérence avec ces identifiants crée des incohérences que les outils d'audit détectent sans difficulté.

Troisième problème, plus pratique : même si vous modifiez le Received: dans le contenu du message, vous n'avez pas touché à l'INTERNALDATE, qui reste celle du dépôt IMAP. Le client mail continue d'afficher la mauvaise date pour le tri. Vous avez modifié le message pour rien.

Bref. Réécrire les Received: pour falsifier une date d'email dans un but malveillant : trivial techniquement, détectable en quelques secondes par un expert. Ce n'est pas une voie sérieuse.

L'en-tête Date: : changer le passé sur le papier

Même raisonnement pour le Date:. On peut le modifier dans le corps du message. Mais les en-têtes Received: authentifiés par les serveurs intermédiaires restent intacts et racontent une autre histoire. La chaîne temporelle est incohérente. Tout analyste ou tribunal comparant ces champs le verra immédiatement.

Pour être précis, ça n'empêche pas certains clients mail d'afficher le Date: modifié si on leur présente directement le fichier .eml. Mais dans le contexte d'un serveur de messagerie live, avec authentification et journaux, la modification est transparente.

La migration IMAP : le seul contexte où corriger les dates est sain

Il y a un cas, et un seul, où modifier la date de réception d'un email est non seulement possible mais techniquement justifié : corriger les dommages causés par une migration IMAP mal gérée.

Voici la situation concrète. Vous venez de migrer 80 boîtes de messagerie Exchange vers Microsoft 365. La migration s'est terminée un vendredi soir. Lundi matin, les premiers tickets arrivent : "Tous mes emails ont la même date", "Impossible de retrouver un email de l'année dernière", "Mon historique avec ce client est complètement cassé". Vous avez 80 utilisateurs bloqués et votre responsable qui attend une réponse.

Dans ce contexte, le problème est documenté, identifiable, et sa cause est claire : l'outil de migration a ajouté un Received: daté du jour de migration, et certains clients mail utilisent ce nouvel en-tête comme date d'affichage. L'en-tête Date: original, lui, est intact dans chaque message. Il n'a jamais été modifié. Il contient encore la date d'envoi originale, correcte.

La correction n'est donc pas une falsification : c'est une restauration. On repart de données vraies (le Date: original) pour reconstruire des métadonnées cohérentes. C'est fondamentalement différent d'essayer de faire passer un email de 2024 pour un email de 2019.

Pour aller plus loin sur les mécanismes spécifiques à chaque outil, ces guides détaillent les cas concrets : corriger les dates BitTitan dans Microsoft 365, corriger les dates CloudM dans Outlook, ou corriger les dates imapsync dans Google Workspace.

Pourquoi ne pas écrire un script soi-même

La logique de base est accessible. N'importe quel admin IT qui a passé du temps sur des forums IMAP peut reconstituer l'approche générale. Ce n'est pas le problème.

Le problème, c'est l'écart entre un script qui fonctionne sur 50 emails de test et un script qui tourne sur 40000 messages en production sans perdre un seul email, sans corrompre une seule pièce jointe, et sans casser un seul fil de conversation.

Quelques cas concrets que les scripts maison ne gèrent généralement pas :

• Emails S/MIME signés : la signature couvre le contenu et les en-têtes. Toute modification de la structure du message invalide la signature. Un email signé corrigé maladroitement arrive comme "signature invalide" chez les destinataires.
• Messages PGP chiffrés : même famille de problèmes, avec des conséquences potentiellement pires selon l'implémentation.
• Encodages non-ASCII dans les en-têtes : le RFC 2047 décrit l'encodage des caractères spéciaux dans les en-têtes. Un script qui manipule les en-têtes sans gérer ces cas va corrompre silencieusement des objets d'emails avec des accents, des caractères japonais, ou des noms arabes.
• Limites de taux API : Google Workspace et Microsoft 365 implémentent des throttling agressifs. À 3h du matin, un batch de 10000 emails qui se heurte à une erreur 429 Too Many Requests sans gestion de backoff exponentiel laisse la moitié des boîtes à moitié corrigées.
• Frontières MIME corrompues : les messages multipart avec des pièces jointes ont des frontières MIME précises. Les régénérer incorrectement rend les pièces jointes illisibles.

Et la question qu'aucun script maison ne résout : comment vérifier que chaque email corrigé est intact ? Un script qui modifie 40000 messages sans vérification individuelle est un pari. Un pari sur des données que vos utilisateurs considèrent souvent comme irremplaçables.

Un article sur les options disponibles pour corriger les dates après migration explore les différentes approches, y compris leurs limites respectives.

Ce que fait Redate.io dans ce contexte

Redate.io est conçu spécifiquement pour ce cas : corriger les dates corrompues par une migration IMAP, à grande échelle, sans risque pour l'intégrité des messages.

Le service se connecte directement aux boîtes concernées (Google Workspace via délégation de domaine, Microsoft 365 via Azure AD, ou IMAP direct), scanne gratuitement les messages avec des dates incorrectes, puis applique un pipeline de correction propriétaire qui gère les cas limites documentés ci-dessus. Chaque email est vérifié individuellement après correction. Les originaux restent dans un dossier de sauvegarde visible pendant 30 jours.

La correspondance de motifs couvre des centaines de signatures d'outils de migration connus : BitTitan MigrationWiz, CloudM, imapsync, GSMMO, et leurs variantes. La détection est précise : Redate.io ne touche pas aux emails dont la date est correcte.

Le modèle tarifaire est simple : paiement unique par boîte mail, sans abonnement. Le scan de diagnostic est gratuit, ce qui permet de mesurer l'étendue des dégâts avant de décider quoi que ce soit.

Si vous gérez des boîtes affectées par ce problème, cet article sur les dates erronées dans Outlook après migration détaille les symptômes les plus courants et comment les distinguer d'autres causes.

Prêt à mesurer l'étendue du problème sur vos boîtes ? Lancez un scan gratuit sur Redate.io et voyez exactement combien d'emails sont affectés avant toute correction.