Por que seus emails mostram a data errada

O problema - todos os emails mostram a mesma data

Após uma migração IMAP, os usuários abrem sua caixa de entrada e encontram uma cena perturbadora: cada email mostra exatamente a mesma data. Em vez da data original de envio ou recebimento, todas as mensagens trazem a data em que a migração foi realizada. Anos de correspondência parecem ter chegado no mesmo dia.

Para administradores de TI, e um pesadelo. Os chamados se acumulam, os usuários não conseguem mais encontrar nada por data, e o histórico cronológico da caixa de email esta, na prática, destruido.

Como isso aparece no Outlook

No Microsoft Outlook, a coluna "Recebido" mostra a data de migração para cada email. Não importa se a mensagem foi enviada em 2018 ou em 2023 - o Outlook exibe a mesma data, a do dia em que a ferramenta de migração processou a caixa. Caixa de entrada, itens enviados, cada pasta e afetada. Usuários que dependem da ordenação por data veem seu fluxo de trabalho completamente quebrado.

Como isso aparece no Apple Mail

O Apple Mail no macOS e no iOS se comporta de forma similar. A data exibida ao lado de cada mensagem reflete o timestamp da migração, e não a data original. Como o Apple Mail usa os metadados do servidor IMAP para determinar as datas de exibição, o mesmo problema de base produz o mesmo resultado visível. Ao percorrer a caixa de entrada, só se ve um muro de datas identicas.

Como isso aparece no Gmail (interface web)

A interface web do Gmail apresenta uma situação ligeiramente diferente. O cliente web do Gmail usa normalmente o cabeçalho "Date" do proprio email, então as mensagens podem aparecer com a data correta no Gmail. Porém, o INTERNALDATE IMAP continua errado, o que significa que qualquer cliente IMAP conectado a essa conta Gmail (Outlook, Thunderbird, Apple Mail) vai mostrar a data de migração. O resultado? A mesma caixa parece correta em um cliente mas errada em outro. Bastante confuso.

Por que isso acontece - a causa técnica

A causa raiz esta na forma como as ferramentas de migração IMAP tratam os cabeçalhos de email e como os clientes de email determinam qual data exibir. Entender isso exige um breve olhar sobre o protocolo IMAP e a estrutura dos cabeçalhos.

Como as ferramentas de migração IMAP tratam os cabeçalhos

Quando um email e migrado de um servidor para outro, a ferramenta de migração baixa a mensagem bruta do servidor de origem e faz o upload para o servidor de destino via comando IMAP APPEND. Durante esse processo, o protocolo IMAP exige que o servidor de destino adicione um cabeçalho "Received" a mensagem. Esse cabeçalho contem o timestamp do momento em que a mensagem foi inserida no novo servidor - ou seja, a data da migração.

O cabeçalho "Received" que quebra tudo

Mensagens de email normalmente contem vários cabeçalhos "Received", cada um adicionado por um servidor de email que processou a mensagem durante a entrega original. Clientes como o Outlook determinam a "data de recebimento" lendo o cabeçalho "Received" mais recente - o que esta no topo da cadeia. Quando uma ferramenta de migração adiciona um novo cabeçalho "Received" com o timestamp da migração, ele se torna o mais recente, e os clientes de email exibem essa data em vez da original.

Não se trata de um bug da ferramenta de migração nem do cliente de email. Ambos seguem corretamente os padrões IMAP e de email. O problema e que esses padrões nunca foram projetados para migração em massa, e a interação entre o IMAP APPEND e a lógica de exibição de datas produz esse resultado indesejado.

INTERNALDATE vs cabeçalho Date

Servidores IMAP armazenam dois valores de data distintos para cada mensagem. O cabeçalho "Date" faz parte do email em si - registra quando a mensagem foi composta e enviada originalmente. O INTERNALDATE e um metadado armazenado pelo servidor IMAP, representando quando a mensagem foi entregue ou inserida naquele servidor específico.

Algumas ferramentas de migração tentam preservar o INTERNALDATE original definindo-o durante o comando APPEND. Mas mesmo quando o INTERNALDATE e corretamente definido, o cabeçalho "Received" adicionado ainda causa problemas em clientes que priorizam a data "Received" em relação ao INTERNALDATE.

Quais ferramentas de migração causam esse problema?

Praticamente todas as ferramentas de migração IMAP podem provocar esse problema. A questão e inerente ao protocolo IMAP, não específica de uma ferramenta. Algumas, porém, são mais frequentemente associadas ao problema devido ao seu uso generalizado.

BitTitan MigrationWiz

O BitTitan MigrationWiz e uma das ferramentas de migração comerciais mais populares usadas por MSPs e consultores de TI. O MigrationWiz adiciona um cabeçalho "Received" contendo "mx.migrationwiz.com" durante o processo de migração. Esse cabeçalho se torna o mais recente na cadeia, fazendo com que Outlook e outros clientes IMAP exibam a data de migração. Veja os guias detalhados para corrigir as datas BitTitan no Outlook, Microsoft 365, Google Workspace e Exchange Online.

CloudM Migrate

O CloudM Migrate (anteriormente Cloud Migrator) e amplamente utilizado para migrações Google Workspace. Assim como as demais ferramentas, o CloudM adiciona seu proprio cabeçalho "Received" durante a inserção IMAP. Emails migrados com CloudM mostram a data de migração em clientes que se baseiam no cabeçalho "Received". Veja os guias para corrigir as datas CloudM no Gmail, Outlook, Google Workspace e Microsoft 365.

imapsync

O imapsync e uma ferramenta open source popular entre administradores Linux e provedores de hospedagem. Embora o imapsync tente preservar o INTERNALDATE, o servidor de destino ainda adiciona um cabeçalho "Received" durante a operação APPEND. A FAQ do imapsync reconhece essa limitacao mas não oferece uma solução embutida para remover o cabeçalho adicionado após a migração. Veja os guias para corrigir as datas imapsync no Outlook, Gmail, Microsoft 365 e Google Workspace.

GSMMO (Google Workspace Migration)

O Google Workspace Migration for Microsoft Outlook (GSMMO) e a ferramenta do proprio Google para migrar a partir do Exchange ou de arquivos PST do Outlook para o Google Workspace. O GSMMO pode produzir o mesmo problema de data, especialmente quando a migração envolve uma etapa IMAP intermediaria. Veja os guias para corrigir as datas GSMMO no Outlook, Gmail e Apple Mail.

Exchange Admin Center (importação IMAP nativa)

O centro de administração Exchange da Microsoft inclui uma funcionalidade de importação IMAP nativa para migrar para o Exchange Online (Microsoft 365). Essa ferramenta de migração embutida adiciona cabeçalhos "Received" durante a importação, causando o mesmo problema de exibição de data. Veja os guias para corrigir as datas de migração Exchange IMAP no Outlook e OWA.

Copia IMAP manual

Até mesmo a copia manual de emails entre servidores IMAP via um cliente como o Thunderbird pode produzir esse problema de data. Quando um cliente de email copia uma mensagem via IMAP, o servidor de destino trata como uma nova inserção e adiciona seu proprio cabeçalho "Received" com o timestamp atual. Veja os guias para corrigir as datas de copia IMAP manual no Outlook, Gmail, Thunderbird e Apple Mail.

Por que as soluções de contorno habituais não funcionam

Diante desse problema, usuários e administradores geralmente tentam várias abordagens antes de perceber que nenhuma resolve de verdade a questão.

"Ordene por data de envio" - por que não basta

A sugestão mais comum e trocar a ordenação de data de "recebimento" para data de "envio" no cliente de email. Isso muda a ordem de exibição, mas não corrige os dados subjacentes. Os resultados de busca continuam mostrando a data errada. Integrações de calendário, ferramentas de conformidade e workflows automatizados que dependem da data de recebimento continuam falhando. E os usuários precisam se lembrar de alterar essa configuração em cada dispositivo e em cada pasta.

Re-migração - cara e arriscada

Alguns administradores consideram executar a migração novamente, esperando evitar o problema de data na segunda tentativa. Essa abordagem e cara (500 a 5.000 EUR dependendo do número de caixas), demorada e arriscada. Uma segunda migração introduz o mesmo problema de cabeçalho "Received", dobra o risco de perda de dados e exige um tempo de inatividade significativo. A re-migração não resolve o problema de data a menos que a ferramenta de migração seja fundamentalmente modificada.

Edição manual de cabeçalhos - exige acesso ao servidor

Tecnicamente, a correção envolve identificar os artefatos de migração na cadeia de cabeçalhos de cada email. Mas fazer isso manualmente exige acesso direto ao servidor, conhecimento da estrutura de cabeçalhos de email e scripting personalizado. Para uma caixa com 10.000 emails, a edição manual e impraticavel e perigosamente sujeita a erros. Emails assinados com S/MIME, mensagens criptografadas com PGP, estruturas multipart com fronteiras MIME aninhadas, problemas de Content-Transfer-Encoding, cabeçalhos non-ASCII (RFC 2047), anexos grandes: cada um desses casos pode levar um script básico a corromper dados de forma irreversivel. Como confirmar que 10.000 emails corrigidos estão todos intactos? Não se pode, a não ser com um sistema de verificação projetado especificamente para isso.

A verdadeira solução - restaurar as datas originais

A abordagem correta consiste em identificar os artefatos de migração na cadeia de cabeçalhos de cada email e aplicar correções direcionadas que restauram a ordem cronológica original em todos os clientes de email. Não se trata de uma simples edição de cabeçalho. O processo envolve validação de conformidade RFC, preservação da estrutura da mensagem e correspondência de assinaturas de migração a partir de um banco de dados de perfis de ferramentas conhecidas.

Como o Redate.io corrige esse problema

O Redate.io se conecta a caixa de email (Google Workspace, Microsoft 365 ou qualquer servidor IMAP) e analisa cada email para identificar as mensagens afetadas pelos cabeçalhos de migração. A análise e gratuita e mostra exatamente quantos emails estão envolvidos antes de qualquer pagamento.

Para cada email afetado, o motor de correção proprietário do Redate.io passa a mensagem por um pipeline de análise multistagio. O motor aplica correspondência de assinaturas em centenas de perfis de ferramentas de migração conhecidas, construidos a partir do processamento de grandes volumes de dados reais de email. Ele lida com problemas de codificação, estruturas multipart, anexos em linha e dezenas de casos especiais que fariam um script caseiro corromper os dados (não e o tipo de descoberta que se quer fazer numa segunda-feira de manha). Cada email corrigido passa por uma verificação de integridade antes de ser finalizado. A mensagem original e movida para uma pasta visível "Redate.io - Originals" (não e excluida) e mantida por 30 dias.

O resultado? Os emails exibem suas datas originais corretas em todos os clientes. A ordenação funciona novamente. O histórico cronológico da caixa e restaurado.

Perguntas frequentes

As datas podem ser corrigidas meses após a migração?

Sim. O cabeçalho "Date" original e preservado dentro da mensagem de email independentemente de quando a migração ocorreu. O Redate.io pode corrigir as datas de emails semanas, meses ou até anos após a migração. A correção funciona enquanto os cabeçalhos originais do email estiverem intactos.

A correção vai excluir meus emails?

Não. O Redate.io nunca exclui emails. As mensagens originais são movidas para uma pasta visível chamada "Redate.io - Originals" dentro da caixa, onde permanecem acessiveis por 30 dias. Cada email corrigido e verificado em relação ao original antes da finalizacao do processo. Se a verificação falhar para uma mensagem, o original permanece intacto.

Isso funciona com caixas de email compartilhadas?

Sim. O Redate.io funciona com caixas compartilhadas no Google Workspace e Microsoft 365. Para caixas compartilhadas, e necessário acesso de nível de administrador para autorizar a conexão. O processo e identico ao das caixas individuais: análise, correção, verificação.

Pronto para restaurar as datas corretas? Inicie uma análise gratuita para descobrir quantos emails estão afetados em cada caixa de email.