Corriger dates imapsync

La promesse de --syncinternaldates (et là où elle s'arrête)

Vous avez lancé la commande imapsync. Vous avez inclus --syncinternaldates parce que vous avez lu la documentation et que vous êtes rigoureux comme ça. La migration se termine, le log indique que tout a été transféré, zéro erreur. Puis vous ouvrez la boîte dans Outlook et chaque email affiche la date d'hier.

C'est l'une des frustrations les plus courantes avec imapsync, et ça déroute les administrateurs système depuis au moins 2017. Le flag --syncinternaldates est censé préserver l'INTERNALDATE IMAP pendant la migration. Et il le fait : il donne à chaque copie la date interne que détient le serveur source. C'est justement là qu'est le piège.

imapsync est un outil open-source en Perl écrit par Gilles Lamiral, et il est sincèrement bon dans ce qu'il fait. Il gère les transferts de boîtes aux lettres IMAP vers IMAP avec un niveau de fiabilité que la plupart des outils commerciaux envient. Mais imapsync ne peut copier que les dates qu'il trouve, et c'est là que ça se complique.

Comment les dates IMAP fonctionnent réellement

Il y a trois "dates" différentes impliquées dans chaque email, et la plupart des gens (y compris certains administrateurs IT) les confondent :

L'en-tête Date: (RFC 2822) - la date que le client de messagerie de l'expéditeur a apposée quand le message a été composé. Elle vit dans le corps du message et n'est jamais modifiée par les serveurs de messagerie.
Les en-têtes Received: - chaque serveur de messagerie qui traite le message en ajoute un avec son propre horodatage. Ils forment une chaîne de l'expéditeur au destinataire. L'en-tête Received le plus haut (le plus récent) est ce que certains clients de messagerie utilisent pour l'affichage.
INTERNALDATE - un horodatage côté serveur IMAP qui contrôle comment les messages sont triés dans la boîte. Il est fixé quand le message est stocké pour la première fois via IMAP APPEND.

Quand imapsync migre un message, il lit le message depuis le serveur source (y compris son INTERNALDATE) et l'écrit sur le serveur destination via IMAP APPEND. Le flag --syncinternaldates indique à imapsync de passer l'INTERNALDATE source au serveur destination pendant l'APPEND.

Bonne nouvelle : Microsoft 365, Outlook.com et Gmail gardent la date qu'on leur donne. Quand les dates ressortent fausses, le problème est donc ailleurs.

Pourquoi les dates peuvent quand même être fausses

La spécification IMAP (RFC 3501) dit que si une date-heure est fournie avec la commande APPEND, le serveur DEVRAIT l'utiliser. "DEVRAIT" en langage RFC signifie "faites-le sauf si vous avez une bonne raison de ne pas le faire". Microsoft 365, Outlook.com et Gmail le font : une copie qui porte sa date d'origine la garde.

Ce qu'imapsync transmet, en revanche, c'est la date que le serveur SOURCE détient pour chaque message, pas la date d'envoi de l'email. Sur une boîte saine, les deux coïncident. Sur une boîte déjà migrée une fois ou restaurée depuis une sauvegarde, la source peut détenir la date de cette opération précédente, et imapsync la recopie telle quelle.

Gmail n'est un cas à part que lorsque la copie passe par l'API d'import de Gmail au lieu d'IMAP : cette API ajoute une ligne Received: datée du jour de la copie, et Outlook peut afficher cette date. imapsync parle IMAP, il n'est pas concerné.

Dovecot et Cyrus, les deux serveurs IMAP open-source les plus répandus, gardent eux aussi la date de l'APPEND. Quelle que soit la destination, la question est donc la même : quelle date détenait la source ?

Erreurs de ligne de commande imapsync courantes qui cassent les dates

Au-delà des dates de la source, les administrateurs trébuchent souvent sur les options de ligne de commande d'imapsync, ou accusent les mauvaises. Voici les erreurs les plus fréquentes :

Copier depuis une source dont les dates étaient déjà fausses

--syncinternaldates est activé par défaut : imapsync donne à chaque copie la date interne que détient le serveur source (sa documentation : "Sets the internal dates on host2 as the same as host1"). Si la boîte source est elle-même le résultat d'une migration précédente ou d'une restauration, ses dates internes peuvent déjà être celles de cette opération, et imapsync recopie fidèlement cette mauvaise date. C'est la cause la plus fréquente, et la plus facile à rater, parce que le log affiche deux dates identiques.

Utiliser --syncinternaldates avec --addheader

Certains guides recommandent d'utiliser --addheader pour injecter un en-tête personnalisé pendant la migration. Ajouter un en-tête modifie le message (une ligne de plus en haut), mais pas la date qu'imapsync transmet : ça n'explique pas des dates fausses. La copie n'est simplement plus identique à l'original, ce qui compte si vous comparez les deux.

Confondre --minage et --maxage avec la préservation des dates

Les flags --minage et --maxage filtrent quels messages migrer en fonction de leur âge. Ils n'affectent pas la façon dont les dates sont gérées à destination. J'ai vu des administrateurs passer des heures à ajuster ces flags en pensant que ça corrigerait le problème de dates. Ça ne le fera pas.

Accuser TLS de décaler les dates

Sur TLS (--ssl1, --ssl2), l'établissement des connexions ajoute de la latence, et sur une grande migration (50 000+ messages) cela se compte en heures. Ça ne touche pas aux dates : chaque copie porte la date qu'imapsync transmet, quelle que soit l'heure à laquelle elle arrive.

Lire les logs imapsync : ce que la sortie indique vraiment

imapsync produit des logs détaillés, ce qui est bien. Mais la sortie des logs peut être trompeuse en ce qui concerne les dates.

Une ligne de transfert réussie typique ressemble à ceci :

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Les deux dates correspondent. Ça signifie qu'imapsync a envoyé le bon INTERNALDATE à la destination. Et Microsoft 365, Outlook.com comme Gmail gardent la date qu'on leur donne. Mais deux dates identiques prouvent seulement que la copie est fidèle à la SOURCE : si la date source était déjà fausse, les deux colonnes affichent la même mauvaise date.

Vous voulez vérifier ce qui s'est réellement passé ? Après la migration, connectez-vous à la destination avec un client IMAP et vérifiez l'INTERNALDATE directement :

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Si la date retournée n'est pas celle de l'envoi, regardez le même message sur la source : vous y trouverez la même mauvaise date. Le log n'a pas menti, il a recopié ce qu'on lui donnait.

C'est l'un des aspects les plus frustrants du débug des problèmes de dates : un log propre, deux dates identiques, et pourtant la mauvaise date dans Outlook, parce que l'erreur était là avant qu'imapsync ne tourne.

Migrations imapsync à grande échelle : où les problèmes de dates se multiplient

Une migration de boîte unique avec imapsync est agaçante quand les dates cassent. Mais les MSP et les départements IT qui lancent imapsync sur des centaines de boîtes font face à une toute autre échelle de problème.

Prenons un scénario de migration d'entreprise typique. Vous déplacez 200 boîtes depuis un serveur Zimbra vers Microsoft 365. Vous écrivez un script wrapper qui boucle sur un CSV d'utilisateurs en appelant imapsync pour chacun. La migration tourne pendant le week-end. Lundi matin, vous avez 200 boîtes avec des dates erronées et environ 1,2 million d'emails au total affichant l'horodatage de migration.

Peut-on relancer imapsync pour corriger ? Techniquement oui, mais imapsync va sauter les messages qui existent déjà à destination (il est conçu pour être idempotent). Il faudrait --delete2 pour supprimer les messages destination et les retransférer, ce qui est risqué sur une boîte en production. Et si les dates de la source étaient en cause, un second passage recopie les mêmes mauvaises dates.

Certains administrateurs essaient une approche hybride : lancer imapsync avec --dry d'abord pour tester, puis la vraie migration. Mais --dry ne fait que simuler le transfert : il montre les dates qu'imapsync transmettrait, pas si ce sont les dates d'envoi des emails. Rien ne vous prévient que les dates de la source sont déjà fausses.

Corrections maison et leurs limites

Si vous cherchez dans les forums et listes de diffusion (la liste imapsync-devel sur SourceForge est toujours active début 2026), vous trouverez des suggestions allant du créatif au dangereux.

Certains suggèrent d'utiliser un one-liner Perl pour modifier l'INTERNALDATE sur le serveur destination directement. D'autres recommandent d'exporter tous les messages au format mbox, de manipuler les dates et de réimporter. Quelques-uns ont écrit des scripts Python qui utilisent imaplib pour récupérer, modifier et réinsérer les messages.

Toutes ces approches partagent les mêmes problèmes fondamentaux. Comment gérer les messages signés S/MIME sans casser la signature ? Qu'en est-il des structures MIME multipart avec des frontières imbriquées ? Des en-têtes non-ASCII encodés en RFC 2047 ? Des messages chiffrés PGP où on ne peut même pas inspecter le contenu ? Un script qui gère 50 messages de test dans un environnement de dev va s'étouffer sur les cas limites d'une boîte de production de 30 000 messages.

Et la plus grande question que personne ne pose avant qu'il soit trop tard : comment vérifier que chaque message modifié est toujours intact ? Que les pièces jointes n'ont pas été corrompues, que le threading fonctionne toujours, que le tableur de 85 Mo que quelqu'un a envoyé par email en 2020 a survécu à la manipulation ?

(Si vous avez déjà essayé de parser des en-têtes d'emails bruts en Perl, vous savez que ce n'est pas exactement une activité reposante.)

Comment Redate.io corrige les dates imapsync

L'en-tête Date: original est toujours intact après une migration imapsync. imapsync transfèe le message brut fidèlement ; la mauvaise date est dans les métadonnées qu'a reçues la copie, pas dans le message. Cet en-tête original est ce qui rend la correction possible.

Redate.io se connecte directement à la boîte aux lettres (Google Workspace, Microsoft 365 ou tout serveur IMAP), scanne les emails avec des anomalies de dates et applique une correction ciblée des métadonnées via un pipeline propriétaire d'analyse de chaîne d'en-têtes et de reconstruction de dates. Elle n'a pas besoin de savoir quel outil a fait la migration : elle repère les emails dont la date affichée ne correspond pas à leur date d'origine.

Chaque email corrigé est vérifié individuellement : intégrité du message, préservation des pièces jointes, placement dans les dossiers, threading, labels. Les originaux sont conservés dans un dossier de sauvegarde visible Redate.io - Originals jusqu'à ce que vous les supprimiez vous-même. Si quelque chose ne va pas, l'annulation est à un clic.

Le scan gratuit se connecte à la boîte, identifie chaque email avec une anomalie de date et affiche le nombre exact et le coût. Pas de carte de crédit, pas de logiciel à installer. Pour les spécificités de votre plateforme :

Redate.io fonctionne aussi pour les migrations effectuées il y a des mois ou des années. L'en-tête Date: n'expire pas, et la capacité de corriger non plus.

Migration avec imapsync et des dates incorrectes ? Lancez un scan gratuit pour voir exactement combien d'emails sont affectés.

imapsync : dates non préservées ? Comment les corriger