O problema - todos os emails mostram a mesma data
Apos uma migracao IMAP, os usuarios 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 migracao foi realizada. Anos de correspondencia parecem ter chegado no mesmo dia.
Para administradores de TI, e um pesadelo. Os chamados se acumulam, os usuarios nao conseguem mais encontrar nada por data, e o historico cronologico da caixa de email esta, na pratica, destruido.
Como isso aparece no Outlook
No Microsoft Outlook, a coluna "Recebido" mostra a data de migracao para cada email. Nao 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 migracao processou a caixa. Caixa de entrada, itens enviados, cada pasta e afetada. Usuarios que dependem da ordenacao 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 migracao, e nao a data original. Como o Apple Mail usa os metadados do servidor IMAP para determinar as datas de exibicao, o mesmo problema de base produz o mesmo resultado visivel. Ao percorrer a caixa de entrada, so se ve um muro de datas identicas.
Como isso aparece no Gmail (interface web)
A interface web do Gmail apresenta uma situacao ligeiramente diferente. O cliente web do Gmail usa normalmente o cabecalho "Date" do proprio email, entao as mensagens podem aparecer com a data correta no Gmail. Porem, 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 migracao. O resultado? A mesma caixa parece correta em um cliente mas errada em outro. Bastante confuso.
Por que isso acontece - a causa tecnica
A causa raiz esta na forma como as ferramentas de migracao IMAP tratam os cabecalhos 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 cabecalhos.
Como as ferramentas de migracao IMAP tratam os cabecalhos
Quando um email e migrado de um servidor para outro, a ferramenta de migracao 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 cabecalho "Received" a mensagem. Esse cabecalho contem o timestamp do momento em que a mensagem foi inserida no novo servidor - ou seja, a data da migracao.
O cabecalho "Received" que quebra tudo
Mensagens de email normalmente contem varios cabecalhos "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 cabecalho "Received" mais recente - o que esta no topo da cadeia. Quando uma ferramenta de migracao adiciona um novo cabecalho "Received" com o timestamp da migracao, ele se torna o mais recente, e os clientes de email exibem essa data em vez da original.
Nao se trata de um bug da ferramenta de migracao nem do cliente de email. Ambos seguem corretamente os padroes IMAP e de email. O problema e que esses padroes nunca foram projetados para migracao em massa, e a interacao entre o IMAP APPEND e a logica de exibicao de datas produz esse resultado indesejado.
INTERNALDATE vs cabecalho Date
Servidores IMAP armazenam dois valores de data distintos para cada mensagem. O cabecalho "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 especifico.
Algumas ferramentas de migracao tentam preservar o INTERNALDATE original definindo-o durante o comando APPEND. Mas mesmo quando o INTERNALDATE e corretamente definido, o cabecalho "Received" adicionado ainda causa problemas em clientes que priorizam a data "Received" em relacao ao INTERNALDATE.
Quais ferramentas de migracao causam esse problema?
Praticamente todas as ferramentas de migracao IMAP podem provocar esse problema. A questao e inerente ao protocolo IMAP, nao especifica de uma ferramenta. Algumas, porem, sao mais frequentemente associadas ao problema devido ao seu uso generalizado.
BitTitan MigrationWiz
O BitTitan MigrationWiz e uma das ferramentas de migracao comerciais mais populares usadas por MSPs e consultores de TI. O MigrationWiz adiciona um cabecalho "Received" contendo "mx.migrationwiz.com" durante o processo de migracao. Esse cabecalho se torna o mais recente na cadeia, fazendo com que Outlook e outros clientes IMAP exibam a data de migracao. 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 migracoes Google Workspace. Assim como as demais ferramentas, o CloudM adiciona seu proprio cabecalho "Received" durante a insercao IMAP. Emails migrados com CloudM mostram a data de migracao em clientes que se baseiam no cabecalho "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 cabecalho "Received" durante a operacao APPEND. A FAQ do imapsync reconhece essa limitacao mas nao oferece uma solucao embutida para remover o cabecalho adicionado apos a migracao. 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 migracao envolve uma etapa IMAP intermediaria. Veja os guias para corrigir as datas GSMMO no Outlook, Gmail e Apple Mail.
Exchange Admin Center (importacao IMAP nativa)
O centro de administracao Exchange da Microsoft inclui uma funcionalidade de importacao IMAP nativa para migrar para o Exchange Online (Microsoft 365). Essa ferramenta de migracao embutida adiciona cabecalhos "Received" durante a importacao, causando o mesmo problema de exibicao de data. Veja os guias para corrigir as datas de migracao Exchange IMAP no Outlook e OWA.
Copia IMAP manual
Ate 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 insercao e adiciona seu proprio cabecalho "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 solucoes de contorno habituais nao funcionam
Diante desse problema, usuarios e administradores geralmente tentam varias abordagens antes de perceber que nenhuma resolve de verdade a questao.
"Ordene por data de envio" - por que nao basta
A sugestao mais comum e trocar a ordenacao de data de "recebimento" para data de "envio" no cliente de email. Isso muda a ordem de exibicao, mas nao corrige os dados subjacentes. Os resultados de busca continuam mostrando a data errada. Integracoes de calendario, ferramentas de conformidade e workflows automatizados que dependem da data de recebimento continuam falhando. E os usuarios precisam se lembrar de alterar essa configuracao em cada dispositivo e em cada pasta.
Re-migracao - cara e arriscada
Alguns administradores consideram executar a migracao novamente, esperando evitar o problema de data na segunda tentativa. Essa abordagem e cara (500 a 5.000 EUR dependendo do numero de caixas), demorada e arriscada. Uma segunda migracao introduz o mesmo problema de cabecalho "Received", dobra o risco de perda de dados e exige um tempo de inatividade significativo. A re-migracao nao resolve o problema de data a menos que a ferramenta de migracao seja fundamentalmente modificada.
Edicao manual de cabecalhos - exige acesso ao servidor
Tecnicamente, a correcao envolve identificar os artefatos de migracao na cadeia de cabecalhos de cada email. Mas fazer isso manualmente exige acesso direto ao servidor, conhecimento da estrutura de cabecalhos de email e scripting personalizado. Para uma caixa com 10.000 emails, a edicao 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, cabecalhos non-ASCII (RFC 2047), anexos grandes: cada um desses casos pode levar um script basico a corromper dados de forma irreversivel. Como confirmar que 10.000 emails corrigidos estao todos intactos? Nao se pode, a nao ser com um sistema de verificacao projetado especificamente para isso.
A verdadeira solucao - restaurar as datas originais
A abordagem correta consiste em identificar os artefatos de migracao na cadeia de cabecalhos de cada email e aplicar correcoes direcionadas que restauram a ordem cronologica original em todos os clientes de email. Nao se trata de uma simples edicao de cabecalho. O processo envolve validacao de conformidade RFC, preservacao da estrutura da mensagem e correspondencia de assinaturas de migracao 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 cabecalhos de migracao. A analise e gratuita e mostra exatamente quantos emails estao envolvidos antes de qualquer pagamento.
Para cada email afetado, o motor de correcao proprietario do Redate.io passa a mensagem por um pipeline de analise multistagio. O motor aplica correspondencia de assinaturas em centenas de perfis de ferramentas de migracao conhecidas, construidos a partir do processamento de grandes volumes de dados reais de email. Ele lida com problemas de codificacao, estruturas multipart, anexos em linha e dezenas de casos especiais que fariam um script caseiro corromper os dados (nao e o tipo de descoberta que se quer fazer numa segunda-feira de manha). Cada email corrigido passa por uma verificacao de integridade antes de ser finalizado. A mensagem original e movida para uma pasta visivel "Redate.io - Originals" (nao e excluida) e mantida por 30 dias.
O resultado? Os emails exibem suas datas originais corretas em todos os clientes. A ordenacao funciona novamente. O historico cronologico da caixa e restaurado.
Perguntas frequentes
As datas podem ser corrigidas meses apos a migracao?
Sim. O cabecalho "Date" original e preservado dentro da mensagem de email independentemente de quando a migracao ocorreu. O Redate.io pode corrigir as datas de emails semanas, meses ou ate anos apos a migracao. A correcao funciona enquanto os cabecalhos originais do email estiverem intactos.
A correcao vai excluir meus emails?
Nao. O Redate.io nunca exclui emails. As mensagens originais sao movidas para uma pasta visivel chamada "Redate.io - Originals" dentro da caixa, onde permanecem acessiveis por 30 dias. Cada email corrigido e verificado em relacao ao original antes da finalizacao do processo. Se a verificacao 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 necessario acesso de nivel de administrador para autorizar a conexao. O processo e identico ao das caixas individuais: analise, correcao, verificacao.
Pronto para restaurar as datas corretas? Inicie uma analise gratuita para descobrir quantos emails estao afetados em cada caixa de email.