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

Cada utilizador inicia sessão com a sua própria conta Microsoft, e o Redate.io abre apenas essa caixa de correio com o acesso que essa sessão concede. Sem portal, sem aplicação a registar. Depois disso, o Redate.io analisa 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 nunca são eliminados: ficam numa pasta visível da própria caixa de correio até serem eliminados manualmente. 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, cada utilizador inicia sessão com a sua própria conta Microsoft, o que torna o processamento de grandes conjuntos de caixas muito mais simples de orquestrar para um admin de TI ou um MSP. Se a organização exigir a aprovação de um administrador, o Redate.io prepara uma ligação para reencaminhar.

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.