Outlook: data recebida IMAP vs data de envio

O sintoma que todo mundo conhece

Você acabou de terminar uma migração IMAP para o Microsoft 365 ou Google Workspace. Segunda de manhã, os tickets chegam: "Todos os meus e-mails têm a mesma data", "Meu histórico está destruído", "Não consigo mais achar nada na minha caixa". Você abre o Outlook e, de fato, milhares de e-mails exibem a data do fim de semana passado. Não a data em que foram enviados. A data em que a migração aconteceu.

Não é um bug do Outlook. É uma consequência direta do funcionamento do protocolo IMAP e das ferramentas de migração. Mas para entender o motivo, é preciso abrir o capô.

Três datas em um único e-mail

Um e-mail é mais complexo do que parece. Cabeçalho, corpo da mensagem, anexos... e vários registros de data e hora distintos que coexistem. (Aliás, se você já tentou ler os cabeçalhos brutos de um e-mail, sabe que não é exatamente uma leitura de praia.)

O cabeçalho Date: (RFC 2822)

É a data que o remetente colocou na mensagem no momento do envio. Definida pelo RFC 2822, ela se parece com isto:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Esse cabeçalho está gravado na massa da mensagem. Ele nunca muda, a não ser que alguém modifique o conteúdo bruto do e-mail. É a "data de envio" no sentido estrito do termo.

O cabeçalho Received: (adicionado a cada salto de rede)

Cada servidor que toca um e-mail em trânsito adiciona um cabeçalho Received: no início da mensagem, com sua própria data. Um e-mail que passa por três servidores acumula três cabeçalhos Received:. O mais recente sempre vem primeiro. O resultado é algo assim:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Resultado: quando uma ferramenta de migração como BitTitan MigrationWiz, CloudM, imapsync ou GSMMO move um e-mail de um servidor de origem para um servidor de destino, ela também se comporta como um "salto de rede". Ela injeta um novo cabeçalho Received: no topo da pilha, com a data e a hora da migração.

O INTERNALDATE do IMAP

É a terceira data, e é ela que causa o problema. O INTERNALDATE é um metadado armazenado no lado do servidor IMAP, independente do conteúdo da mensagem. Ele representa a data em que o e-mail foi entregue (ou inserido) na caixa de correio. Quando uma ferramenta de migração insere um e-mail via o comando IMAP APPEND, é ela quem escolhe qual valor atribuir ao INTERNALDATE. E em muitos casos, as ferramentas usam a data do momento da migração. Não a data original.

É aí que tudo trava.

Por que o Outlook exibe a data da migração

O Outlook usa o INTERNALDATE para exibir a coluna "Recebido". Esse é o comportamento padrão, e é coerente com a especificação IMAP: o INTERNALDATE deve representar a data de recebimento na caixa. Em um fluxo normal (um e-mail real que chega), o INTERNALDATE é próximo da data no cabeçalho Date:. Os dois são coerentes.

Após uma migração mal feita, o INTERNALDATE de todos os e-mails importados aponta para a madrugada de 14 para 15 de junho de 2024 (ou seja lá qual for a data da migração). O Outlook lê esse valor, exibe na coluna "Recebido", e o resultado é catastrófico: 45.000 e-mails parecem ter sido recebidos na mesma noite.

Para ser preciso, o primeiro cabeçalho Received: (o mais recente na pilha) também influencia a exibição em algumas configurações. Mas o INTERNALDATE continua sendo o determinante principal para a coluna "Recebido" do Outlook em modo IMAP sincronizado.

O contorno "Adicionar a coluna Enviado" no Outlook

A primeira coisa que a maioria dos admins de TI faz ao descobrir o problema é procurar um contorno do lado do cliente. E existe um, de fato.

No Outlook, é possível modificar a exibição das colunas de uma pasta para substituir (ou complementar) a coluna "Recebido" pela coluna "Data" ou "Enviado". A coluna "Data" lê diretamente o cabeçalho Date: da mensagem, não o INTERNALDATE. Como o cabeçalho Date: não foi tocado pela migração, as datas originais voltam a aparecer.

Para fazer isso no Outlook (desktop, versão Microsoft 365): clique com o botão direito no cabeçalho de coluna na lista de mensagens, "Configurações de exibição", depois modifique as colunas para remover "Recebido" e adicionar "Data". É possível fazer isso via GPO para uma implantação em massa.

Bom. No papel, isso resolve o problema visual. Na prática, é um curativo numa artéria.

Os limites concretos desse contorno

Os clientes móveis e web

O Outlook no iOS, Android e o Outlook Web App (OWA) não têm as mesmas opções de personalização. A modificação de exibição que você implantou nas máquinas Windows não se propaga. Seus usuários que consultam os e-mails pelo celular continuam vendo a data da migração. E em uma empresa de médio porte, isso é provavelmente metade dos usuários.

A pesquisa

A pesquisa do Outlook usa o índice do Windows Search (ou o índice do Exchange/Microsoft 365 no lado do servidor). Esse índice é construído a partir do INTERNALDATE, não do cabeçalho Date:. Se um usuário procurar "e-mails de janeiro de 2022", a pesquisa retorna os e-mails cujo INTERNALDATE está em janeiro de 2022. Não aqueles cujo cabeçalho Date: está em janeiro de 2022. O resultado: os e-mails antigos não aparecem mais nos filtros de data. Mudar a coluna de exibição não muda nada nisso.

As regras de mensagem

As regras do Outlook ("se o e-mail foi recebido antes de...", "se o e-mail foi recebido depois de...") também usam o INTERNALDATE. Uma regra de triagem ou arquivamento baseada em intervalos de datas não vai funcionar corretamente após a migração se o INTERNALDATE não for corrigido.

Conformidade e eDiscovery

Talvez seja o ponto mais sério. As ferramentas de conformidade, arquivamento legal e eDiscovery (o Microsoft Purview, por exemplo) usam o INTERNALDATE como referência de data para consultas legais. Se sua empresa está sujeita a obrigações de retenção de dados ou precisa responder a solicitações de discovery, INTERNALDATEs corrompidos podem gerar problemas jurídicos reais. Uma auditoria que pede "todos os e-mails entre tal e tal data" não vai retornar os resultados corretos.

As ferramentas de terceiros

CRM, ferramentas de ticketing, arquivadores... tudo que se conecta ao seu servidor de e-mail via IMAP ou pelas APIs do Microsoft 365/Google Workspace lê o INTERNALDATE. Mudar a exibição do Outlook não corrige nada para esses sistemas.

A única solução real: corrigir no nível do servidor

Ordenar por data de envio no Outlook não é uma solução. É um curativo. A correção real precisa acontecer no nível dos metadados do servidor, não da exibição do cliente.

Na prática, isso significa corrigir o INTERNALDATE de cada e-mail para que corresponda à data original do cabeçalho Date:. O cabeçalho Date: original está sempre presente na mensagem (ele não foi apagado pela migração), o que torna a correção possível. É ali que está a informação de data real.

No Google Workspace, a API do Gmail expõe um parâmetro internalDate que permite agir diretamente sobre esse metadado. No Microsoft 365, o mecanismo é diferente, mas o resultado esperado é o mesmo. Em um servidor IMAP padrão, a norma prevê que a data pode ser especificada na inserção de uma mensagem.

Na prática, realizar essa operação em dezenas de milhares de e-mails em produção, sem perda de dados, sem duplicatas, sem quebrar os fios de discussão ou os rótulos, gerenciando os casos limites (mensagens assinadas com S/MIME, estruturas MIME complexas, codificações não-ASCII conforme o RFC 2047, anexos volumosos)... isso é outra história. Um script que funciona em 50 e-mails de teste não vai aguentar uma caixa com 40.000 mensagens. O gerenciamento dos erros 429 (cota de API excedida), dos timeouts de rede às 2h da manhã, das mensagens cuja estrutura MIME já está parcialmente corrompida após a migração... tudo isso exige uma engenharia séria.

É exatamente isso que o Redate.io faz. O motor de correção proprietário analisa a cadeia de cabeçalhos de cada e-mail, identifica a data original confiável e aplica uma correção direcionada dos metadados sem tocar no conteúdo da mensagem. Cada e-mail corrigido é verificado individualmente. Os originais são mantidos em uma pasta de backup por 30 dias, o que garante um rollback possível a qualquer momento. Algo que um script caseiro nunca oferece.

Identificar a ferramenta de migração responsável

O problema se manifesta da mesma forma independentemente da origem da migração, mas os detalhes variam conforme a ferramenta utilizada. BitTitan MigrationWiz, CloudM, imapsync e GSMMO têm cada um sua assinatura nos cabeçalhos Received: que injetam. O pipeline de análise do Redate.io mantém uma base de correspondência com centenas de assinaturas de ferramentas de migração conhecidas para distinguir o cabeçalho de migração do restante da cadeia de trânsito legítima.

Se você não sabe qual ferramenta foi usada na sua migração (isso acontece, especialmente quando você assume um parque de outro MSP), o scan gratuito do Redate.io identifica as caixas afetadas e fornece uma estimativa do volume a corrigir antes de qualquer compromisso.

Para contextos específicos, há guias detalhados disponíveis: corrigir as datas do imapsync no Outlook, corrigir as datas do BitTitan no Outlook, ou corrigir as datas do CloudM no Outlook.

O que fazer agora

Se você está lendo este artigo após uma migração, a boa notícia é que o cabeçalho Date: original está intacto em cada um dos seus e-mails. As informações de data real estão lá, presentes em cada mensagem. O problema está nos metadados, não no conteúdo. E metadados se corrigem.

Você também pode consultar o artigo IMAP INTERNALDATE: por que as datas quebram para entender melhor a mecânica do problema, ou o guia completo sobre datas erradas no Outlook após migração se quiser uma visão geral dos diferentes cenários.

Pronto para corrigir as datas das suas caixas de e-mail? Inicie um scan gratuito no Redate.io para identificar os e-mails afetados e estimar o volume antes de qualquer correção.