Corriger dates imapsync

La promesse de --syncinternaldates (et pourquoi elle ne tient pas)

Vous avez lance la commande imapsync. Vous avez inclus --syncinternaldates parce que vous avez lu la documentation et que vous etes rigoureux comme ca. La migration se termine, le log indique que tout a ete transfere, zero erreur. Puis vous ouvrez la boite dans Outlook et chaque email affiche la date d'hier.

C'est l'une des frustrations les plus courantes avec imapsync, et ca deroute les administrateurs systeme depuis au moins 2017. Le flag --syncinternaldates est cense preserver l'INTERNALDATE IMAP pendant la migration. Et techniquement, il essaie. Mais "essaie" fait beaucoup de travail dans cette phrase.

imapsync est un outil open-source en Perl ecrit par Gilles Lamiral, et il est sincerement bon dans ce qu'il fait. Il gere les transferts de boites aux lettres IMAP vers IMAP avec un niveau de fiabilite que la plupart des outils commerciaux envient. Mais la preservation des dates n'est pas entierement entre les mains d'imapsync, et c'est la que ca se complique.

Comment les dates IMAP fonctionnent reellement

Il y a trois "dates" differentes impliquees dans chaque email, et la plupart des gens (y compris certains administrateurs IT) les confondent :

L'en-tete Date: (RFC 2822) - la date que le client de messagerie de l'expediteur a apposee quand le message a ete compose. Elle vit dans le corps du message et n'est jamais modifiee par les serveurs de messagerie.
Les en-tetes Received: - chaque serveur de messagerie qui traite le message en ajoute un avec son propre horodatage. Ils forment une chaine de l'expediteur au destinataire. L'en-tete Received le plus haut (le plus recent) est ce que certains clients de messagerie utilisent pour l'affichage.
INTERNALDATE - un horodatage cote serveur IMAP qui controle comment les messages sont tries dans la boite. Il est fixe quand le message est stocke pour la premiere fois via IMAP APPEND.

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

Voici le probleme : le serveur de destination n'est pas oblige de respecter cette date.

Pourquoi les serveurs de destination ignorent l'INTERNALDATE

La specification 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". Plusieurs plateformes de messagerie majeures ont decide qu'elles avaient une bonne raison.

Microsoft 365 est le plus gros contrevenant. Quand un message arrive via IMAP APPEND, le pipeline de transport Exchange y appose un nouvel en-tete Received contenant la date actuelle, puis fixe l'INTERNALDATE base sur cet horodatage de livraison. Peu importe la date demandee par imapsync. Le serveur M365 l'ecrase.

Google Workspace (Gmail) se comporte differemment mais peut aussi poser probleme. L'implementation IMAP de Gmail respecte l'INTERNALDATE de l'APPEND dans la plupart des cas, mais ajoute son propre en-tete Received. Si le client de messagerie qui lit la boite priorise les en-tetes Received sur l'INTERNALDATE pour l'affichage (et Outlook fait exactement ca), les dates apparaissent quand meme fausses.

Dovecot et Cyrus, les deux serveurs IMAP open-source les plus repandus, respectent generalement l'INTERNALDATE de l'APPEND. Du coup, les migrations imapsync entre deux serveurs Dovecot preservent habituellement les dates correctement. Les problemes commencent quand la destination est une plateforme hebergee avec son propre traitement de transport.

Erreurs de ligne de commande imapsync courantes qui cassent les dates

Meme quand le serveur de destination coopererait, les administrateurs trebuchent souvent sur les options de ligne de commande d'imapsync. Voici les erreurs les plus frequentes :

Oublier --syncinternaldates

Le flag n'est pas active par defaut. Si vous lancez un imapsync --host1 source --host2 dest --user1 user --user2 user basique sans lui, imapsync ne tente pas du tout de preserver les dates. Le serveur destination utilise l'horodatage courant pour chaque message. C'est la cause la plus frequente, et la plus facile a rater parce qu'imapsync ne vous previent pas.

Utiliser --syncinternaldates avec --addheader

Certains guides recommandent d'utiliser --addheader pour injecter un en-tete personnalise pendant la migration. Si vous ajoutez des en-tetes, vous modifiez le message, ce qui peut pousser le serveur destination a le traiter comme un message "nouveau" et a l'estampiller en consequence. L'interaction entre ces deux flags est mal documentee.

Confondre --minage et --maxage avec la preservation des dates

Les flags --minage et --maxage filtrent quels messages migrer en fonction de leur age. Ils n'affectent pas la facon dont les dates sont gerees a destination. J'ai vu des administrateurs passer des heures a ajuster ces flags en pensant que ca corrigerait le probleme de dates. Ca ne le fera pas.

Derive de timestamps due a la negociation SSL

Lors de migrations sur TLS avec --ssl1 et --ssl2, l'etablissement de connexion ajoute de la latence. Dans les grandes migrations (50 000+ messages), cette latence s'accumule. Ca ne change pas les dates de plusieurs jours, mais ca peut faire que des messages envoyes a quelques minutes d'intervalle arrivent avec des horodatages identiques a destination, perdant leur ordre relatif.

Lire les logs imapsync : ce que la sortie indique vraiment

imapsync produit des logs detailles, ce qui est bien. Mais la sortie des logs peut etre trompeuse en ce qui concerne les dates.

Une ligne de transfert reussie typique ressemble a 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. Ca signifie qu'imapsync a envoye le bon INTERNALDATE a la destination. Mais ca ne signifie pas que le serveur destination a effectivement stocke cette date. imapsync rapporte ce qu'il a demande, pas ce que le serveur a accepte.

Vous voulez verifier ce qui s'est reellement passe ? Apres la migration, connectez-vous a la destination avec un client IMAP et verifiez l'INTERNALDATE directement :

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Si la date retournee est la date de migration au lieu du 2019-01-15, le serveur destination a ignore la demande d'imapsync. Le log vous a menti (enfin, il vous a dit ce qu'il a demande, pas ce qu'il a obtenu).

Cet ecart entre ce qu'imapsync rapporte et ce qui se passe reellement est l'un des aspects les plus frustrants du debug des problemes de dates. On peut fixer un fichier de log propre pendant des heures sans jamais realiser que les dates sont fausses de l'autre cote.

Migrations imapsync a grande echelle : ou les problemes de dates se multiplient

Une migration de boite unique avec imapsync est agacante quand les dates cassent. Mais les MSP et les departements IT qui lancent imapsync sur des centaines de boites font face a une toute autre echelle de probleme.

Prenons un scenario de migration d'entreprise typique. Vous deplacez 200 boites depuis un serveur Zimbra vers Microsoft 365. Vous ecrivez 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 boites avec des dates cassees et environ 1,2 million d'emails au total affichant l'horodatage de migration.

Peut-on relancer imapsync avec --syncinternaldates si on l'a oublie la premiere fois ? Techniquement oui, mais imapsync va sauter les messages qui existent deja a destination (il est concu pour etre idempotent). Il faudrait --delete2 pour supprimer les messages destination et les retransferer, ce qui est risque sur une boite en production. Et meme dans ce cas, si le serveur destination ignore l'INTERNALDATE, on revient au point de depart.

Certains administrateurs essaient une approche hybride : lancer imapsync avec --dry d'abord pour tester, puis la vraie migration. Mais --dry ne teste pas ce que le serveur destination fait avec l'INTERNALDATE. Il simule seulement le transfert. Le probleme de dates est invisible tant que les messages ne sont pas reellement ecrits a destination.

Corrections maison et leurs limites

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

Certains suggerent 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 reimporter. Quelques-uns ont ecrit des scripts Python qui utilisent imaplib pour recuperer, modifier et reinserer les messages.

Toutes ces approches partagent les memes problemes fondamentaux. Comment gerer les messages signes S/MIME sans casser la signature ? Qu'en est-il des structures MIME multipart avec des frontieres imbriquees ? Des en-tetes non-ASCII encodes en RFC 2047 ? Des messages chiffres PGP ou on ne peut meme pas inspecter le contenu ? Un script qui gere 50 messages de test dans un environnement de dev va s'etouffer sur les cas limites d'une boite de production de 30 000 messages.

Et la plus grande question que personne ne pose avant qu'il soit trop tard : comment verifier que chaque message modifie est toujours intact ? Que les pieces jointes n'ont pas ete corrompues, que le threading fonctionne toujours, que le tableur de 85 Mo que quelqu'un a envoye par email en 2020 a survecu a la manipulation ?

(Si vous avez deja essaye de parser des en-tetes d'emails bruts en Perl, vous savez que ce n'est pas exactement une activite reposante.)

Comment Redate.io corrige les dates imapsync

L'en-tete Date: original est toujours intact apres une migration imapsync. imapsync transfee le message brut fidelement ; c'est la gestion des metadonnees du serveur de destination qui cause le probleme d'affichage. Cet en-tete original est ce qui rend la correction possible.

Redate.io se connecte directement a la boite aux lettres (Google Workspace, Microsoft 365 ou tout serveur IMAP), scanne les emails avec des anomalies de dates et applique une correction ciblee des metadonnees via un pipeline proprietaire d'analyse de chaine d'en-tetes et de reconstruction de dates. La correction gere les patterns specifiques que les migrations imapsync laissent derriere, y compris les signatures caracteristiques d'en-tetes Received des serveurs destination qui ont ecrase l'INTERNALDATE.

Chaque email corrige est verifie individuellement : integrite du message, preservation des pieces jointes, placement dans les dossiers, threading, labels. Les originaux sont conserves dans un dossier de sauvegarde visible Redate.io - Originals pendant 30 jours. Si quelque chose ne va pas, l'annulation est a un clic.

Le scan gratuit se connecte a la boite, identifie chaque email avec une anomalie de date et affiche le nombre exact et le cout. Pas de carte de credit, pas de logiciel a installer. Pour les specificites de votre plateforme :

Redate.io fonctionne aussi pour les migrations effectuees il y a des mois ou des annees. L'en-tete Date: n'expire pas, et la capacite de corriger non plus.

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

imapsync : dates non preservees ? Comment les corriger