Corriger les dates de migration CloudM dans Gmail
Pourquoi les migrations CloudM affichent la mauvaise date dans Gmail
CloudM Migrate (anciennement Cloud Migrator) est largement utilisé pour migrer des boîtes aux lettres vers Google Workspace. CloudM utilise l'API Gmail pour transférer les e-mails vers le compte Gmail de destination. Lors de ce transfert, l'infrastructure de Gmail enregistre l'horodatage d'insertion comme INTERNALDATE du message, écrasant la date de livraison originale par la date à laquelle la migration a été effectuée.
CloudM tente de préserver l'en-tête Date original à l'intérieur du corps de l'e-mail, et l'interface web de Gmail utilise généralement cet en-tête Date pour l'affichage. Cependant, l'IMAP INTERNALDATE est définitivement définie à la date de migration. Chaque client IMAP qui se connecte au compte Gmail (Outlook, Apple Mail, Thunderbird, clients mobiles utilisant IMAP) lit cette INTERNALDATE et affiche la date de migration dans la colonne de réception.
Les organisations migrant depuis Microsoft 365, Exchange sur site ou d'autres plateformes vers Google Workspace via CloudM découvrent ce problème lorsque les utilisateurs connectent des clients de bureau à leurs nouveaux comptes Gmail. L'interface web de Gmail peut sembler correcte, mais Outlook et Apple Mail affichent chaque e-mail comme reçu à la date de migration, générant confusion et tickets de support au sein de l'organisation.
Comment cela affecte Gmail
Dans Gmail, l'impact dépend de la manière dont l'utilisateur accède à sa boîte aux lettres. L'interface web de Gmail affiche généralement les dates correctement car elle lit l'en-tête Date de l'e-mail. En revanche, tout client connecté via IMAP (Outlook, Apple Mail, Thunderbird) affiche la date de migration car ces clients s'appuient sur l'IMAP INTERNALDATE plutôt que sur l'en-tête Date.
Le système de libellés et la recherche de Gmail sont également affectés de manière subtile. Bien que la recherche web de Gmail utilise l'en-tête Date pour les opérateurs « before: » et « after: », la commande IMAP SEARCH DATE utilise l'INTERNALDATE. Les outils de sauvegarde tiers et les solutions d'archivage d'e-mails qui se connectent via IMAP archivent la date de migration comme date du message, créant des inexactitudes permanentes dans les sauvegardes. Google Vault, utilisé pour la conformité et la conservation juridique, peut également référencer l'INTERNALDATE pour certaines opérations, affectant la précision de la découverte juridique basée sur les dates.
Questions fréquemment posées
CloudM Migrate corrompt-il toujours les dates dans Gmail ?
CloudM transfère les e-mails via l'API Gmail, qui définit l'INTERNALDATE à l'horodatage du transfert. L'en-tête Date à l'intérieur de l'e-mail est préservé, donc Gmail web affiche généralement la date correcte. Mais les clients IMAP affichent la date de migration car ils lisent l'INTERNALDATE.
Pourquoi les e-mails semblent corrects dans Gmail web mais incorrects dans Outlook ?
Gmail web utilise l'en-tête Date du corps de l'e-mail pour l'affichage, que CloudM préserve. Outlook et les autres clients IMAP utilisent l'IMAP INTERNALDATE, qui est définie à la date de migration. Redate.io corrige l'INTERNALDATE afin que tous les clients affichent la bonne date.
Redate.io peut-il corriger les dates de migration CloudM sur tout un domaine Google Workspace ?
Oui. Grâce à la délégation à l'échelle du domaine Google Workspace, Redate.io peut analyser et corriger les boîtes aux lettres de l'ensemble de l'organisation. Les administrateurs peuvent traiter plusieurs boîtes aux lettres sans nécessiter l'intervention individuelle des utilisateurs.