eM Client : dates fausses après import PST ou Thunderbird

Le symptôme : tous vos emails portent la même date

Vous venez de terminer un import PST dans eM Client, ou vous avez migré depuis Thunderbird vers votre nouvelle boîte. L'import s'est déroulé sans erreur apparente. Mais en ouvrant votre boîte de réception, quelque chose cloche : des centaines, parfois des milliers d'emails affichent tous la même date, celle du jour de l'import. Un email de 2019 semble avoir été reçu hier. Un contrat signé il y a trois ans apparaît comme s'il venait d'arriver.

La première réaction naturelle est de blâmer eM Client. Mauvais paramètre, mauvaise colonne de tri, bug d'affichage... On cherche dans les préférences. On bascule entre "Date de réception" et "Date d'envoi". Rien ne change. Ou plutôt, quelque chose change, mais ça ne règle pas le fond du problème.

C'est parce que le problème n'est pas dans eM Client. Il est dans les métadonnées du serveur.

La vraie cause : l'INTERNALDATE IMAP écrasé pendant l'import

Pour comprendre ce qui se passe, il faut descendre d'un niveau et regarder comment le protocole IMAP stocke les emails.

Chaque message sur un serveur IMAP possède deux types de dates distinctes :

• L'en-tête Date: (défini par la RFC 2822) : c'est la date que l'expéditeur a inscrite dans le message au moment de l'envoi. Elle est encapsulée dans le corps du message, intouchable en théorie.
• L'INTERNALDATE : une métadonnée serveur, externe au message, qui représente la date à laquelle le message a été déposé dans la boîte. C'est cette valeur que les clients mail utilisent prioritairement pour trier et afficher les emails.

Lors d'un import PST ou d'une migration depuis Thunderbird, l'outil d'import (qu'il s'agisse du module natif d'eM Client, d'un outil tiers, ou d'une copie IMAP manuelle) dépose les messages sur le serveur IMAP de destination. Et là, si l'outil ne préserve pas explicitement l'INTERNALDATE original au moment du dépôt, le serveur assigne automatiquement l'INTERNALDATE courant, c'est-à-dire la date et l'heure de l'import.

Résultat : 8000 emails archivés depuis 2017, tous estampillés "reçus" au moment de votre migration.

(D'ailleurs, si vous avez déjà essayé de lire les en-têtes bruts d'un email avec Afficher la source dans eM Client, vous avez pu constater que l'en-tête Date: original est toujours là, intact. C'est le signe que le problème vient de l'INTERNALDATE serveur, pas du message lui-même.)

Pourquoi changer la colonne de tri ne sert à rien

La confusion vient d'une distinction que peu de gens connaissent. Dans eM Client, comme dans Outlook ou Thunderbird, il existe généralement deux colonnes de date :

• "Date reçue" (ou "Date d'arrivée") : basée sur l'INTERNALDATE serveur.
• "Date" ou "Date d'envoi" : basée sur l'en-tête Date: du message.

Beaucoup d'admins découvrent ça et pensent avoir trouvé la solution : basculer sur "Date d'envoi", et le problème disparaît visuellement dans eM Client. Mais ce n'est pas tout à fait exact.

Correction : même en triant par date d'envoi dans eM Client, le problème persiste pour tous les autres clients et toutes les autres interfaces qui accèdent à la même boîte. Si vos utilisateurs consultent leurs emails depuis OWA, depuis Outlook au bureau, depuis l'application Gmail sur mobile, ou depuis n'importe quel client configuré en IMAP, ils verront les dates d'import. Le paramètre de tri d'eM Client ne s'applique qu'à eM Client, et il n'agit pas sur les métadonnées stockées côté serveur.

De plus, sur Microsoft 365 et Google Workspace, la vue web native trie par INTERNALDATE. Vous ne pouvez pas changer ce comportement depuis le client.

Le tri par date d'envoi n'est pas une solution. C'est un pansement qui masque un problème réel sans le corriger.

Le cas particulier de l'import PST

L'import de fichiers PST mérite un paragraphe à part. Un fichier PST (Personal Storage Table) est un format propriétaire Microsoft qui stocke emails, contacts et calendriers localement. Quand vous importez un PST dans eM Client, deux scénarios sont possibles :

• Import local vers un compte IMAP : eM Client lit le PST et pousse les messages sur le serveur IMAP de destination. Si la date de dépôt n'est pas préservée, l'INTERNALDATE est écrasé. C'est le cas le plus fréquent, et c'est là que les dates se retrouvent corrompues.
• Import vers un dossier local : les messages restent sur la machine, hors serveur. L'INTERNALDATE n'existe pas dans ce contexte, et eM Client peut afficher la date Date: du message. Moins de problème de date ici, mais aussi moins d'utilité pratique.

Pour Thunderbird, la situation est similaire. Si vous utilisez la fonction d'import intégrée d'eM Client (qui lit les profils Thunderbird), ou si vous avez copié des dossiers mbox via IMAP, les messages sont redéposés sur le serveur sans garantie de préservation de l'INTERNALDATE. Et un serveur qui reçoit un message sans instruction de date explicite sur l'INTERNALDATE va systématiquement horodater au moment de la réception.

Quelle plateforme est concernée ?

Le problème est identique quelle que soit la plateforme de destination, parce qu'il s'agit d'un comportement standard du protocole IMAP :

• Microsoft 365 / Exchange Online : l'INTERNALDATE est écrasé lors de tout import qui n'utilise pas la commande IMAP APPEND avec un paramètre de date explicite. Même chose pour une migration depuis Exchange on-premise.
• Google Workspace : même comportement. Les emails importés via eM Client ou des outils tiers affichent la date d'import dans Gmail et dans l'interface d'administration.
• Hébergeurs IMAP classiques (OVH, Infomaniak, Ionos, o2switch, etc.) : aucun traitement spécial de la date lors de la réception d'un message en APPEND. L'INTERNALDATE sera la date du dépôt.

Un client nous a contacté après avoir migré une bonne centaine de boîtes depuis un Exchange 2013 vers Microsoft 365, en utilisant eM Client comme outil de transition pour certains comptes VIP. Résultat : les boîtes migrées proprement via MigrationWiz étaient correctes, mais les boîtes passées par eM Client avaient toutes les dates d'import. Inutile de dire que les utilisateurs concernés n'ont pas apprécié.

Pourquoi un script maison ne résoudra pas ça facilement

Techniquement, quelqu'un qui comprend le protocole IMAP pourrait penser à écrire un script pour corriger les INTERNALDATE. L'en-tête Date: original est là, intact dans chaque message. Il suffirait de le lire et de reconstruire les métadonnées serveur en conséquence, non ?

En théorie, oui. En pratique, c'est un terrain miné.

D'abord, les cas limites s'accumulent rapidement sur une boîte de production. Les messages S/MIME signés numériquement sont particulièrement sensibles à toute manipulation de structure. Les messages PGP chiffrés aussi. Les emails avec des pièces jointes volumineuses, des frontières MIME non standard, ou des encodages Content-Transfer-Encoding inhabituels peuvent se corrompre silencieusement si le traitement n'est pas rigoureux. Un script qui fonctionne sur 50 emails de test ne fonctionnera pas de manière fiable sur une boîte de 20 000 messages avec 6 ans d'historique.

Ensuite, la gestion des quotas API. Sur Microsoft 365, les limites de taux sur l'API Graph ou sur EWS à 3h du matin sur un batch de correction de 8000 messages, ça se gère. Mais ça ne se gère pas tout seul. Un script non supervisé qui rencontre une erreur 429 Too Many Requests sur le message n°3741 continuera peut-être, peut-être pas. Et vous ne saurez pas forcément quels messages ont été traités.

Et surtout : comment vérifier que chaque email corrigé est intact après traitement ? Un script maison n'a généralement pas de mécanisme de vérification individuelle. Redate.io le fait automatiquement, pour chaque message.

Corriger les dates à la source avec Redate.io

Redate.io s'attaque au problème là où il se trouve : au niveau des métadonnées serveur, pas au niveau du client mail.

Le processus commence par une phase de scan gratuite. Redate.io se connecte à la boîte concernée (Microsoft 365 via Azure AD, Google Workspace via délégation de domaine, ou IMAP direct pour les hébergeurs classiques) et identifie les emails dont les métadonnées de date sont incohérentes avec le contenu du message. Vous voyez le résultat avant de rien payer.

La correction utilise un moteur propriétaire qui analyse la chaîne d'en-têtes complète de chaque message, applique une correspondance de motifs sur des centaines de signatures d'outils d'import connus (dont les comportements spécifiques d'eM Client, de Thunderbird, des imports PST), et reconstruit les métadonnées de date de façon ciblée sans altérer le contenu du message, ses pièces jointes, ni sa structure MIME.

Chaque email corrigé est vérifié individuellement. Les originaux sont conservés dans un dossier de sauvegarde visible pendant 30 jours, ce qu'un script maison ne fera jamais par défaut.

La tarification est simple : paiement unique par boîte, basé sur le volume d'emails à corriger. Pas d'abonnement, pas de frais récurrents. Consultez la page de démarrage pour voir les détails.

Pour la prochaine migration : ce qu'il faut vérifier

Si vous planifiez une migration et voulez éviter ce problème en amont, le point de contrôle est simple : l'outil que vous utilisez préserve-t-il explicitement l'INTERNALDATE lors du dépôt des messages sur le serveur de destination ?

Pour les imports PST vers Microsoft 365, les outils certifiés Microsoft (comme MigrationWiz dans ses modes natifs, ou l'outil de migration Exchange Online) gèrent généralement cette préservation. Pour les imports manuels via eM Client ou Thunderbird, c'est rarement le cas. Vérifiez la documentation de votre outil avant de lancer un import sur des boîtes de production.

Une bonne checklist de migration email inclut toujours une vérification post-migration des dates sur un échantillon de boîtes. Si vous voulez aller plus loin, notre checklist migration email couvre ce point en détail.

Pour les admins qui gèrent régulièrement des migrations pour leurs clients, l'article sur la correction des dates email côté MSP et celui sur le fonctionnement de l'INTERNALDATE IMAP donnent une vision plus complète du problème.

Les dates de vos emails sont corrompues après un import eM Client ? Lancez un scan gratuit sur Redate.io pour mesurer l'étendue du problème avant de décider quoi faire.