Datas erradas após migração IMAP para Exchange Online

O clássico cenário da manhã de segunda-feira

Você acabou de concluir a migração IMAP para o Exchange Online. O batch terminou sem erros no centro de administração do Exchange, as caixas estão sincronizadas, os usuários conseguem fazer login. Você fecha o computador na sexta-feira à noite com a sensação de dever cumprido.

Na segunda de manhã, os tickets chegam. "Todos os meus e-mails estão com a data de sexta-feira." "Meu histórico da caixa de entrada ficou inutilizável." "Sumiu e-mail antigo." Na verdade, não sumiu nada: os e-mails estão lá, mas o Outlook exibe todos com a data da migração em vez da data de envio original. Um e-mail de 2019 aparece datado da sexta passada. Resultado: a caixa inteira parece conter só mensagens recentes.

É um dos problemas mais frustrantes das migrações IMAP para Exchange Online, e a Microsoft quase nunca o documenta direito.

Por que a migração via EAC quebra as datas

Quando você usa o centro de administração do Exchange (EAC) para configurar uma migração IMAP a partir de um servidor local (Dovecot, Courier, Cyrus, UW-IMAP, tanto faz), o Exchange Online se conecta ao servidor de origem via IMAP, busca as mensagens e as injeta nas caixas de destino pelo próprio pipeline de transporte interno.

É aí que o problema começa.

Cada e-mail que passa pelo pipeline de transporte do Exchange recebe automaticamente um cabeçalho Received: com registro de data e hora. Esse é um comportamento padrão de servidores SMTP e IMAP há décadas: cada servidor que toca uma mensagem adiciona sua assinatura temporal. O problema é que o Outlook (especialmente o Outlook para Windows nas versões mais recentes) usa o cabeçalho Received: mais recente como referência de exibição quando outros metadados são ambíguos.

O cabeçalho Date: original (aquele que indica quando o e-mail foi realmente enviado, no sentido da RFC 2822) ainda está presente na mensagem. Não foi removido. Mas fica "eclipsado" por esse novo cabeçalho Received: adicionado pelo Exchange durante a injeção.

Além disso, o INTERNALDATE do IMAP (o metadado que os servidores IMAP usam para datar as mensagens internamente e que controla a ordenação na maioria dos clientes) fica com a data da injeção, não com a data original do e-mail. O Exchange Online não tem nenhum mecanismo nativo para preservar o INTERNALDATE do servidor de origem durante uma migração em batch via EAC.

EAC vs. ferramentas de terceiros: uma diferença importante

Convém distinguir duas situações. Com ferramentas como BitTitan MigrationWiz ou CloudM Migrate, o problema também existe, mas essas ferramentas às vezes têm opções de configuração (parcialmente documentadas, muitas vezes escondidas nas configurações avançadas) que tentam preservar alguns metadados de data.

A migração nativa via EAC, por sua vez, não oferece nenhuma opção desse tipo. A Microsoft não expõe nenhum parâmetro para controlar a preservação do INTERNALDATE no pipeline de migração em batch. É uma caixa-preta: você configura o batch, dispara, e o Exchange faz o que quer internamente. E o que ele faz, sistematicamente, é datar as mensagens com a data da injeção.

(Aliás, se você já tentou ler os cabeçalhos brutos de um e-mail migrado via EAC, sabe que o campo Received: adicionado pelo Exchange é inconfundível: ele contém referências aos servidores internos da Microsoft como *.protection.outlook.com ou *.prod.exchangelabs.com, com um registro de data e hora que corresponde exatamente à janela de migração.)

Por que recriar o batch não resolve nada

A reação instintiva de muitos admins de TI diante desse problema é pensar: "Se eu apagar as caixas migradas e relançar o batch do zero, talvez desta vez as datas fiquem certas."

É compreensível. Mas não funciona.

O problema não está na configuração do batch. Não está em algum parâmetro que você esqueceu de marcar. Ele está na própria arquitetura do pipeline de transporte do Exchange, que é idêntica a cada migração. Relançar o batch vai produzir exatamente o mesmo resultado: os mesmos cabeçalhos Received: com a nova data de migração e os mesmos INTERNALDATEs errados. Você terá perdido tempo e os usuários terão sido incomodados uma segunda vez à toa.

Alguns admins também tentam modificar as configurações de ordenação no Outlook ("ordenar por data de envio" em vez de "data de recebimento"). Ordenar por data de envio não é uma solução. É um curativo. O cabeçalho Date: e o INTERNALDATE continuam errados para os clientes que não permitem esse ajuste, para o OWA, para o Outlook Mobile e para qualquer aplicativo de terceiros que acesse a caixa via IMAP ou EWS.

O que acontece de verdade nos cabeçalhos

Veja um exemplo simplificado do que um e-mail contém após migração via EAC. O cabeçalho original:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@antigodomain.com
Subject: Relatório Q1 2019

Após a migração, a mensagem recebe no topo da cadeia algo como:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

O Outlook vê esse cabeçalho Received: primeiro (ele é adicionado no topo do bloco de cabeçalhos), interpreta como a data mais recente de processamento da mensagem e exibe como data de recebimento. O cabeçalho Date: original de 2019 ainda está lá, intacto, algumas linhas abaixo. Mas o Outlook não o usa para exibição na lista de mensagens.

Para ser preciso: o comportamento varia ligeiramente conforme a versão do Outlook. As versões pós-2021 (e especialmente o novo Outlook para Windows implantado desde o final de 2023) são particularmente sensíveis a esse problema porque dependem mais dos metadados do Exchange Graph do que do cabeçalho Date: bruto. O que significa que migrações que não causavam problemas visíveis com o Outlook 2016 podem agora gerar falhas com o novo Outlook.

Quem é realmente afetado

Os servidores IMAP de origem mais comuns nesse tipo de migração são Dovecot (muito utilizado em ambientes Linux/cPanel) e Courier. Ambos expõem INTERNALDATEs via IMAP que o EAC não preserva. Se você migra de um servidor Exchange local para o Exchange Online (migração híbrida ou cutover), o comportamento é diferente porque a Microsoft usa um protocolo de transporte interno (MAPI/EWS) que preserva melhor os metadados. O problema específico é a migração IMAP genérica via EAC.

Os usuários mais afetados são aqueles com caixas de longo histórico (5 anos ou mais) e alto volume de mensagens. Um usuário com 300 e-mails na caixa se recupera rapidamente. Um diretor comercial com 12.000 e-mails organizados por data, dos quais depende diariamente para localizar conversas com clientes, fica completamente paralisado.

Por que um script caseiro é uma má ideia aqui

Alguns admins de TI que entendem o problema técnico ficam tentados a escrever um script PowerShell ou Python para corrigir os cabeçalhos manualmente. O conceito básico pode parecer simples depois que você identifica o mecanismo. Mas a realidade de uma correção em produção é outra história.

Primeiro, os casos especiais. E-mails assinados com S/MIME e mensagens criptografadas com PGP têm uma estrutura que não tolera modificação de cabeçalhos sem invalidar a assinatura. Mensagens multipart/alternative com fronteiras MIME malformadas (comuns em servidores Courier antigos) podem ser corrompidas por um script que modifica a mensagem sem reconstruir corretamente a estrutura. Cabeçalhos não-ASCII codificados conforme a RFC 2047 (nomes de remetentes com caracteres acentuados ou japoneses, por exemplo) são uma fonte clássica de erros.

Depois, o volume. Um script que funciona em 50 e-mails de teste em ambiente de desenvolvimento não gerencia os limites de taxa da API do Exchange Online em produção. O erro 429 Too Many Requests às 2h da manhã durante um batch de 8.000 mensagens, sem mecanismo de retomada, é uma noite sem dormir e potencialmente mensagens duplicadas ou perdidas.

E principalmente: como verificar que cada e-mail corrigido está intacto? Que nenhum anexo foi truncado, que nenhum encadeamento foi quebrado, que os labels e pastas foram preservados? Sem mecanismo de validação individual, você simplesmente torce para que tudo tenha corrido bem.

A correção de datas após migração é um problema que parece um script de 50 linhas, mas que exige milhares para ser confiável em produção.

O que o Redate.io faz de diferente

O Redate.io se conecta ao Exchange Online via APIs do Microsoft 365 (Azure Active Directory, permissões de delegação no nível do tenant) e escaneia as caixas afetadas para identificar os e-mails cujos metadados de data foram corrompidos pela migração. Essa etapa de varredura é gratuita e dá uma visão exata da extensão do problema: número de mensagens afetadas, caixas envolvidas, intervalo de datas corrompidas.

O motor de correção proprietário do Redate.io processa cada e-mail individualmente via um pipeline de análise de múltiplas etapas que inclui correspondência de padrões em assinaturas de ferramentas de migração conhecidas (incluindo o pipeline de transporte do Exchange Online), validação de conformidade RFC e verificação da integridade estrutural da mensagem antes e depois da correção. E-mails assinados com S/MIME, estruturas MIME complexas, codificações não padrão: todos são tratados por caminhos de processamento específicos.

Cada mensagem corrigida é verificada individualmente. Os originais são mantidos em uma pasta de backup visível por 30 dias. Se algo não estiver certo com uma mensagem específica, ela não é modificada: o Redate.io sinaliza a anomalia em vez de arriscar uma corrupção.

A precificação é baseada em volume, com pagamento único por caixa. Sem assinatura, sem taxas recorrentes. Você corrige o problema uma vez, e está resolvido.

Para migrações Exchange Online especificamente, o Redate.io suporta conexão via permissões de aplicativo do Azure AD (sem precisar criar credenciais individuais por caixa), o que torna o processamento de grandes conjuntos de caixas muito mais simples de orquestrar para um admin de TI ou um MSP.

Se você gerencia vários clientes que passaram por esse tipo de migração, consulte também o guia completo sobre correção de datas após migração Microsoft 365 para uma visão geral dos diferentes cenários cobertos.

Os e-mails estão lá, as datas originais também. Inicie uma varredura gratuita no Redate.io para ver exatamente quantas mensagens estão afetadas nas suas caixas do Exchange Online, antes de decidir o que fazer.