imapsync : dates non préservées, guide de correction complet

8 min

imapsync est l'outil de migration email de référence pour les administrateurs système Linux, les hébergeurs et tous ceux qui préfèrent les solutions open source. Créé par Gilles Lamiral, imapsync est activement maintenu depuis 2001 et a été utilisé pour des millions de migrations de boîtes mail dans le monde. Il supporte pratiquement tous les serveurs IMAP : Dovecot, Courier, Cyrus, Zimbra, Exchange, Gmail et des dizaines d'autres.

imapsync a la réputation d'être complet et configurable. Les administrateurs apprécient son contrôle granulaire sur les dossiers à migrer, la gestion des doublons et le mapping des noms de dossiers entre différents serveurs IMAP. Mais malgré tout ce contrôle, un problème persiste : les dates des emails ne sont fréquemment pas préservées après une migration imapsync. Les utilisateurs ouvrent leur boîte mail après migration et constatent que chaque email affiche la date de migration. C'est exaspérant, surtout parce qu'imapsync est censé gérer les dates correctement.

Comment imapsync gère l'INTERNALDATE

La tentative de préservation de l'INTERNALDATE

imapsync tente effectivement de préserver l'INTERNALDATE de chaque email pendant la migration. L'INTERNALDATE est l'horodatage que le serveur IMAP stocke comme métadonnée pour chaque message, séparé des en-têtes de l'email. Quand imapsync copie un message de la source vers la destination, il lit l'INTERNALDATE du serveur source et la transmet au serveur de destination dans la commande IMAP APPEND.

En théorie, cela devrait préserver la date originale. En pratique, le résultat dépend du comportement du serveur de destination et de la façon dont les clients de messagerie interprètent les différents champs liés aux dates dans le message.

Le problème de l'en-tête "Received"

Même quand imapsync réussit à préserver l'INTERNALDATE, le serveur de messagerie de destination ajoute un nouvel en-tête "Received" à chaque message pendant l'opération APPEND. Cet en-tête "Received" contient l'horodatage actuel, la date de migration. Les clients de messagerie comme Outlook, Apple Mail et Thunderbird déterminent la date de "réception" affichée en lisant l'en-tête "Received" le plus haut, pas l'INTERNALDATE. Donc malgré l'effort d'imapsync pour préserver l'INTERNALDATE, la date visible dans la plupart des clients est quand même fausse.

C'est cette déconnexion fondamentale qui cause la confusion. imapsync préserve une valeur de date (INTERNALDATE), mais les clients de messagerie en affichent une autre (l'horodatage de l'en-tête "Received"). Pour une plongée technique dans ce mécanisme, voir pourquoi les emails affichent la mauvaise date après migration IMAP.

L'idée reçue de la FAQ imapsync

La documentation et la FAQ d'imapsync abordent le problème de date mais le présentent comme une limitation inhérente. La FAQ suggère que "les dates peuvent ne pas être préservées" lors de la migration IMAP et implique que c'est simplement comme ça que le protocole IMAP fonctionne. Bien qu'il soit vrai que le protocole IMAP exige des serveurs d'ajouter des en-têtes "Received" lors de l'insertion de messages, la FAQ crée l'impression que le problème est permanent et irréparable.

Ce n'est pas exact. Les en-têtes "Received" ajoutés pendant la migration peuvent être identifiés et supprimés après coup, restaurant l'affichage de la date originale dans les clients de messagerie. L'en-tête "Date" original (qui enregistre quand l'email a été envoyé à l'origine) est toujours préservé par imapsync et sert de référence pour la date correcte.

Identifier l'en-tête de migration imapsync

A quoi ressemble l'en-tête

imapsync lui-même n'ajoute pas d'en-tête "Received", c'est le serveur IMAP de destination qui le fait. L'en-tête ajouté lors d'une migration imapsync ressemble généralement à un en-tête d'insertion IMAP standard du serveur de destination. Par exemple, en migrant vers un serveur Dovecot, l'en-tête pourrait ressembler a :

Received: from localhost by mail.example.com;
  Wed, 15 Jan 2025 09:14:22 +0100

L'identifiant clé est que cet en-tête "Received" est le plus haut dans la chaîne, son horodatage correspond à la date d'exécution de la migration imapsync, et il référence généralement "localhost" ou le nom d'hôte du serveur de destination plutôt qu'un serveur de messagerie externe.

Comparer les dates

Pour confirmer le problème, comparez l'horodatage de l'en-tête "Received" le plus haut avec l'en-tête "Date" de l'email. Si l'en-tête "Received" indique janvier 2025 mais que l'en-tête "Date" indique mars 2020, l'en-tête "Received" de migration est la cause du mauvais affichage de date. Cette comparaison peut se faire en visualisant la source brute du message dans n'importe quel client de messagerie.

Pourquoi les options courantes d'imapsync ne résolvent pas le problème

Le flag --syncinternaldates

imapsync propose le flag --syncinternaldates, qui définit l'INTERNALDATE sur le serveur de destination pour correspondre à l'en-tête "Date" de l'email. C'est utile quand l'INTERNALDATE du serveur source est déjà fausse, mais ça n'empêche pas le serveur de destination d'ajouter un en-tête "Received". La date visible dans Outlook et autres clients reste la date de migration quelle que soit la valeur de l'INTERNALDATE.

L'option --addheader

imapsync peut ajouter des en-têtes personnalisés aux messages pendant la migration, mais ne peut pas empêcher le serveur de destination d'ajouter son propre en-tête "Received". Le protocole IMAP exige des serveurs qu'ils enregistrent l'horodatage d'insertion, et aucune option imapsync ne peut outrepasser ce comportement au niveau du serveur.

Scripts post-migration

Certains administrateurs écrivent des scripts post-migration personnalisés pour supprimer les en-têtes "Received" indésirables. Ça semble raisonnable, surtout pour le genre de personne qui a choisi imapsync en premier lieu (quelqu'un à l'aise avec la ligne de commande). Mais la réalité est bien plus complexe qu'un rechercher-remplacer sur du texte d'en-tête. Que se passe-t-il quand le script tombe sur un email signé S/MIME ? Ou un message multipart avec des frontières MIME imbriquées et des pièces jointes encodées en base64 ? Ou un en-tête avec des caractères non-ASCII encodés RFC 2047 ? Un seul octet mal placé dans une frontière MIME peut silencieusement corrompre un message entier, détruisant les pièces jointes ou rendant l'email illisible. Et comment confirmer que 10000 emails corrigés sont tous intacts ? Pour des milliers d'emails sur plusieurs boîtes mail, le scripting DIY représente un risque substantiel.

Corriger les dates imapsync avec Redate.io

Comment Redate.io gère les migrations imapsync

Le moteur de correction propriétaire de Redate.io est conçu spécifiquement pour cette catégorie de problème. Après connexion à la boîte mail, Redate.io analyse chaque email et fait passer chaque message à travers un pipeline d'analyse multi-étapes. Pour les migrations imapsync, Redate.io détecte l'en-tête "Received" inséré par le serveur en appliquant une correspondance de signatures sur des centaines de profils de migration connus, en analysant la chaîne complète d'en-têtes et en croisant les horodatages avec l'en-tête "Date" original.

Ce n'est pas une simple édition d'en-tête. Le moteur de correction gère la validation de conformité RFC, la préservation de la structure du message (incluant les structures multipart/alternative, les pièces jointes en ligne et les variations de Content-Transfer-Encoding) et la détection des signatures numériques. Les emails avec des signatures S/MIME ou PGP sont automatiquement identifiés et traités de manière appropriée pour préserver l'intégrité des signatures.

Ce que vous obtenez après la correction

Chaque email corrigé affiche sa date de réception originale dans tous les clients de messagerie. L'ordre chronologique est restauré. Chaque correction passe par une vérification d'intégrité avant d'être finalisée. Le message original est déplacé vers un dossier "Redate.io - Originals" et conservé pendant 30 jours comme filet de sécurité.

Compatibilité avec tous les serveurs de destination

Puisqu'imapsync est utilisé pour migrer vers pratiquement n'importe quel serveur IMAP, Redate.io supporte la même étendue de plateformes de destination. Que la migration imapsync ait ciblé Dovecot, Courier, Cyrus, Zimbra, Google Workspace, Microsoft 365 ou tout autre serveur IMAP, Redate.io se connecte et corrige les dates.

Comment corriger les dates après une migration imapsync

Connecter la boîte mail

Connectez-vous à Redate.io et ajoutez la boîte mail. Pour Google Workspace ou Microsoft 365, utilisez l'option de délégation admin. Pour les autres serveurs IMAP (courants dans les scénarios imapsync), entrez l'adresse du serveur, le nom d'utilisateur et le mot de passe. Redate.io se connecte via IMAP standard.

Analyse gratuite

Lancez l'analyse gratuite pour identifier les emails affectés. Le rapport d'analyse montre le nombre total d'emails, combien ont la mauvaise date et quelle date de migration a été détectée. Cette analyse ne coûte rien et donne une image claire avant tout engagement.

Corriger et vérifier

Sélectionnez un plan en fonction du nombre d'emails affectés et lancez la correction. La progression est visible en temps réel. Après achèvement, vérifiez les résultats en consultant les dates des emails dans votre client. Les dates devraient être revenues à leur place.

Guides de correction imapsync par plateforme

Questions fréquentes

Faut-il utiliser --syncinternaldates d'imapsync avant d'utiliser Redate.io ?

Ce n'est pas nécessaire. Redate.io définit la bonne INTERNALDATE pendant le processus de correction, quelle que soit la valeur actuelle. Qu'imapsync ait préservé l'INTERNALDATE originale ou non, Redate.io dérive la valeur correcte à partir de l'en-tête "Date" original.

Peut-on corriger les dates sur le serveur source avant de migrer avec imapsync ?

Si le serveur source a déjà des dates erronées (suite à une migration précédente), Redate.io peut les corriger avant ou après la migration imapsync. Mais corriger les dates sur le serveur de destination après migration est l'approche la plus courante et pratique.

Combien d'emails Redate.io peut-il traiter ?

Redate.io gère des boîtes mail de toute taille. Des plans sont disponibles pour jusqu'à 100000 emails par boîte mail. Pour les organisations avec de nombreuses boîtes, Redate.io propose des tarifs de volume.

La migration imapsync a cassé les dates ? Lancez une analyse gratuite pour voir combien d'emails sont affectés et corrigez-les avec Redate.io.