Corriger les dates imapsync dans Microsoft 365

Migrer vers Microsoft 365 avec imapsync semble raisonnable. C'est gratuit, scriptable, et gère bien les transferts IMAP vers IMAP dans la plupart des scénarios. Mais Exchange Online n'est pas "la plupart des scénarios".

La passerelle IMAP d'Exchange Online est une couche de compatibilité greffée sur un système conçu autour d'EWS et MAPI. Quand imapsync pousse un message via cette passerelle avec la commande APPEND, le message entre dans le pipeline de transport complet d'Exchange Online - le même pipeline qui traite le courrier entrant depuis Internet. Ce pipeline ajoute des en-têtes de transport, exécute les vérifications de prévention des pertes de données, applique les règles de conformité et estampille un nouvel en-tête Received avec l'instant exact où le message a touché le serveur. Le flag --syncinternaldates ? Le pipeline de transport d'Exchange Online n'en tient pas compte. L'INTERNALDATE est écrasée pour correspondre à l'horodatage de livraison.

Ce n'est pas un bug que Microsoft prévoit de corriger. C'est le fonctionnement architectural d'Exchange Online. Le pipeline de transport traite chaque APPEND comme une nouvelle livraison de message, un point c'est tout. Que vous migriez 500 e-mails ou 500000, chacun reçoit la même date de migration estampillée dans ses en-têtes et métadonnées.

Imaginez annoncer à votre directeur informatique que la migration exécutée pendant le week-end vient d'aplatir 6 ans d'historique e-mail sur une seule date. C'est la réalité à laquelle les administrateurs font face après une migration imapsync vers Microsoft 365. Et contrairement à Google Workspace (où le client web Gmail peut masquer le problème), Microsoft 365 affiche la mauvaise date partout - Outlook bureau, OWA, Outlook mobile, Microsoft Search. Pas d'issue de secours côté client.

Dans Microsoft 365, les dégâts sont totaux et visibles. Chaque client - Outlook pour Windows, Outlook pour Mac, OWA, Outlook mobile sur iOS et Android - affiche l'horodatage de migration. Les utilisateurs ne peuvent pas trier par date, ne peuvent pas retrouver d'e-mails chronologiquement, ne peuvent pas se fier aux résultats de recherche filtrés par plage de dates. Une boîte de 80000 e-mails affichant tous "12 novembre 2024" est fonctionnellement inutilisable pour le travail quotidien.

Les implications de conformité sont pires. Exchange Online Protection, Microsoft Purview et les stratégies de rétention indexent tous l'horodatage de livraison corrompu. Une politique de rétention configurée pour supprimer les e-mails de plus de 7 ans opère sur la mauvaise date - ce qui signifie que des e-mails de 2018 qui devraient approcher de la suppression semblent maintenant dater de 2024. Les organisations soumises au RGPD, HIPAA ou aux réglementations financières font face à une exposition réglementaire réelle quand la rétention de leurs e-mails ne peut plus être garantie. Et si une demande d'obligation légale arrive pour "tous les e-mails du T3 2023", les dates corrompues font que Purview ne renvoie rien - parce que selon les métadonnées, aucun e-mail n'existe pour cette période.

Redate.io se connecte à Microsoft 365 et applique son analyse de la chaîne d'en-têtes et sa reconstruction des métadonnées de date à chaque message affecté. La reconnaissance de signatures spécifiques à imapsync identifie quels en-têtes Received ont été injectés pendant la migration versus ceux qui appartiennent à la chaîne de livraison originale. Chaque message est corrigé et vérifié individuellement, avec l'original préservé dans un dossier de sauvegarde. Le forfait Enterprise gère des boîtes jusqu'à 100000 e-mails, et les administrateurs peuvent traiter plusieurs boîtes depuis un seul tableau de bord.