Corriger les dates imapsync dans Gmail

imapsync est l'outil de référence pour la migration IMAP vers IMAP, et à juste titre - il gère le mappage de dossiers, la préservation des indicateurs et la synchronisation incrémentielle mieux que la plupart des alternatives. Mais quand la destination est Gmail, la préservation des dates devient peu fiable de manières qui surprennent même les administrateurs système expérimentés.

Le flag --syncinternaldates est censé résoudre le problème. Il indique à imapsync de transmettre l'INTERNALDATE du message source au serveur de destination pendant l'APPEND. Sur un serveur IMAP standard, cela fonctionne. Sur Gmail ? Pas toujours. L'implémentation IMAP de Gmail fait passer les messages entrants par son propre pipeline de traitement interne - filtrage anti-spam, analyse de sécurité, indexation du contenu. Pendant ce traitement, Gmail peut écraser l'INTERNALDATE demandée et estampiller le message avec l'horodatage du transfert à la place. Il ajoute aussi un en-tête Received (contenant généralement "gmailapi.google.com" ou l'identifiant de la passerelle IMAP) daté du moment du transfert.

Le plus rageant : cela n'arrive pas à chaque message. Certains e-mails de la boîte migrée obtiennent la bonne INTERNALDATE. D'autres obtiennent la date de transfert. Pas de schéma clair - un message de 2018 peut être correct tandis que celui juste à côté, du même jour, est estampillé avec la date de migration. On se retrouve avec une boîte où 30 à 70 % des e-mails ont de mauvaises dates, dispersés aléatoirement entre les dossiers et les périodes.

Du coup, essayez d'expliquer à un responsable conformité pourquoi 4200 des 11000 e-mails migrés affichent la mauvaise date de réception, mais que les 6800 autres sont corrects. Bon courage pour trouver un schéma là-dedans.

L'interface web Gmail masque le problème. Gmail web affiche la valeur de l'en-tête Date, pas l'INTERNALDATE, donc la plupart des e-mails affectés semblent corrects dans le navigateur. Cela crée un faux sentiment de sécurité dangereux - l'administrateur de migration vérifie Gmail web, voit des dates correctes, et ferme le ticket.

Puis les utilisateurs commencent à connecter Outlook, Apple Mail et Thunderbird à leurs nouveaux comptes Gmail. Ces clients lisent l'IMAP INTERNALDATE pour leurs colonnes de dates. Soudain, des e-mails aléatoires affichent la date de migration tandis que d'autres affichent la bonne date. L'incohérence entre Gmail web et les clients bureau génère des tickets de support confus. Les commandes de recherche IMAP côté serveur (SEARCH SINCE, SEARCH BEFORE) référencent l'INTERNALDATE, renvoyant des résultats incomplets ou inexacts. Les outils de sauvegarde tiers archivant via IMAP capturent définitivement les dates corrompues. Google Vault et les outils de conformité Workspace peuvent référencer l'INTERNALDATE pour les obligations légales, impactant potentiellement l'eDiscovery. La reconnaissance de signatures de migration par Redate.io identifie les en-têtes Received spécifiques à Gmail qui indiquent une corruption des dates, puis applique une correction ciblée des métadonnées à chaque message affecté tout en préservant les libellés, étoiles et statuts lu/non lu.