Corrigir datas de migração do imapsync no Microsoft 365

Migrar para o Microsoft 365 com imapsync parece razoável. A ferramenta é gratuita, permite automação por scripts e lida bem com transferências IMAP para IMAP na maioria dos cenários. Mas no Microsoft 365, há um detalhe que decide a data com que cada e-mail acaba por ficar.

O Exchange Online mantém a data que lhe é dada: quando o imapsync escreve uma mensagem por IMAP, transmite juntamente a data interna de cada e-mail (--syncinternaldates está ativo por predefinição), e a cópia mantém essa data. O que o imapsync transmite, no entanto, é a data que o servidor de ORIGEM guarda para cada mensagem, não a data em que o e-mail foi enviado. Numa caixa de correio saudável, as duas coincidem. Numa caixa de correio já migrada uma vez ou restaurada a partir de uma cópia de segurança, a origem pode guardar a data dessa operação anterior, e o imapsync copia-a tal como está.

Isto não é um erro do Microsoft 365 nem do imapsync. Cada cópia mantém fielmente a data que lhe foi atribuída. Quando essa data já estava errada na origem, sejam 500 ou 500.000 e-mails migrados, cada e-mail afetado mostra a data dessa operação anterior em vez da data em que foi recebido.

Imagine explicar ao seu diretor de TI que a migração do fim de semana acabou de comprimir 6 anos de histórico de e-mail em uma única data. Essa é a realidade que os administradores enfrentam após uma migração com imapsync para o Microsoft 365. E diferente do Google Workspace (onde a interface web do Gmail pode mascarar o problema), o Microsoft 365 mostra a data errada em todos os lugares - Outlook desktop, OWA, Outlook móvel, Microsoft Search. Não há escapatória do lado do cliente.

No Microsoft 365, o dano é total e visível. Cada cliente - Outlook para Windows, Outlook para Mac, OWA, Outlook móvel no iOS e Android - exibe a marca temporal da migração. Os usuários não conseguem ordenar por data, não conseguem encontrar e-mails cronologicamente, não podem confiar nos resultados de pesquisa com filtro por data. Uma caixa de correio com 80.000 e-mails mostrando "12 de novembro de 2024" está funcionalmente inutilizada para o trabalho diário.

As implicações de conformidade são piores. O Exchange Online Protection, Microsoft Purview e as políticas de retenção indexam a marca temporal de entrega corrompida. Uma política de retenção configurada para excluir e-mails com mais de 7 anos opera com a data errada - o que significa que e-mails de 2018 que deveriam estar próximos da exclusão agora parecem ser de 2024. Organizações sujeitas ao RGPD, HIPAA ou regulamentações da SEC enfrentam exposição regulatória real quando a retenção de e-mails não é confiável. E se chegar uma solicitação de retenção legal para "todos os e-mails do terceiro trimestre de 2023," as datas corrompidas fazem o Purview não retornar nada - porque, segundo os metadados, não existem e-mails desse período.

O Redate.io se conecta ao Microsoft 365 e aplica sua análise de cadeia de cabeçalhos e processo de reconstrução de metadados de data a cada mensagem afetada. Não é necessário saber qual ferramenta fez a migração: o Redate.io identifica os e-mails cuja data apresentada não corresponde à data original. Cada mensagem é corrigida e verificada individualmente, com o original preservado em uma pasta de backup. O Redate.io processa a caixa de correio independentemente do número de e-mails, sem limite de tamanho.