As tres datas dentro de cada email
Cada email armazenado em um servidor IMAP carrega pelo menos tres valores de data distintos. Entender como essas datas funcionam, e como os clientes de email escolhem qual exibir, e a chave para compreender por que a migracao quebra as datas. Este artigo e uma analise tecnica aprofundada do sistema de datas IMAP, destinada a administradores de TI e a qualquer pessoa que queira entender a causa raiz dos problemas de data pos-migracao.
1. O cabecalho "Date" RFC 2822
O cabecalho "Date" e definido na RFC 2822 (formato de mensagens da Internet). Ele e definido pelo cliente de email do remetente no momento em que a mensagem e composta e enviada. Esse cabecalho faz parte do corpo da mensagem em si - viaja com a mensagem e nunca e modificado pelos servidores de email no caminho de entrega. Um cabecalho Date tipico se parece com:
Date: Mon, 15 Jan 2024 09:32:17 +0100
O cabecalho Date representa a "data de envio" da mensagem. E a data mais confiavel porque e definida uma unica vez e nunca alterada. No entanto, reflete o relogio do remetente, que pode estar mal configurado. Em casos raros, o cabecalho Date pode estar totalmente ausente (especialmente em notificacoes de sistema automatizadas ou mensagens malformadas).
2. O IMAP INTERNALDATE
O INTERNALDATE e definido na RFC 3501 (protocolo IMAP4rev1). E um valor de metadado do lado do servidor que representa a data e hora em que a mensagem foi entregue ao servidor. Diferentemente do cabecalho Date, o INTERNALDATE nao faz parte da mensagem de email em si. E armazenado separadamente pelo servidor IMAP como metadado.
Quando um email e entregue normalmente (nao migrado), o servidor IMAP define o INTERNALDATE como a hora corrente no momento da entrega. Esse valor corresponde de perto ao cabecalho Date, geralmente com diferenca de alguns segundos ou minutos. Os clientes de email frequentemente usam o INTERNALDATE como "data de recebimento" porque reflete quando o servidor realmente recebeu a mensagem.
E aqui que a coisa fica interessante. Quando uma mensagem e inserida via comando IMAP APPEND (o que as ferramentas de migracao usam), o comando APPEND permite ao cliente especificar o INTERNALDATE explicitamente. Ferramentas de migracao bem projetadas usam essa funcionalidade para preservar o INTERNALDATE original do servidor de origem. Mas mesmo quando o INTERNALDATE e corretamente definido, o problema do cabecalho "Received" (descrito abaixo) pode sobrescrever a data exibida em muitos clientes.
3. A cadeia de cabecalhos "Received"
Cada vez que um email passa por um servidor de email, esse servidor adiciona um cabecalho "Received" no inicio da mensagem. Isso cria uma cadeia de cabecalhos Received que registra o percurso do email do remetente ao destinatario. O mais recente (no topo) mostra o ultimo servidor que processou a mensagem, e o mais antigo (embaixo) mostra o primeiro.
Um email normal pode ter 3 a 6 cabecalhos Received, documentando a viagem desde o servidor de saida do remetente atraves de relays ate o servidor de entrada do destinatario. Cada cabecalho Received inclui um timestamp. Aqui esta um exemplo simplificado:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Como os clientes de email escolhem qual data exibir
Outlook (Desktop, Web, Mobile)
O Microsoft Outlook usa uma combinacao do INTERNALDATE e do cabecalho "Received" mais recente para determinar a data de "Recebimento" exibida na caixa de entrada. Na pratica, o Outlook tende a privilegiar o timestamp do cabecalho Received mais recente para a coluna "Recebido". A coluna "Enviado" usa o cabecalho Date. Como o Outlook ordena por padrao pela coluna "Recebido", e o timestamp do cabecalho Received que os usuarios veem primeiro.
Apple Mail
O Apple Mail no macOS e iOS usa principalmente o IMAP INTERNALDATE para exibir a data. Se o INTERNALDATE foi corretamente preservado durante a migracao, o Apple Mail pode exibir a data correta, mas apenas se o INTERNALDATE foi explicitamente definido na operacao APPEND. Se a ferramenta de migracao nao definiu o INTERNALDATE, o servidor usa por padrao a hora de insercao (a data de migracao). Para detalhes sobre o impacto para usuarios do Apple Mail, veja Apple Mail: data errada apos migracao.
Thunderbird
O Mozilla Thunderbird oferece a maior flexibilidade. Pode exibir tanto "Data" (do cabecalho Date) quanto "Recebido" (dos cabecalhos Received). Por padrao, o Thunderbird exibe o valor do cabecalho Date, o que significa que as datas podem parecer corretas no Thunderbird mesmo quando estao erradas no Outlook. A coluna "Recebido" no Thunderbird sempre exibe a data de migracao. Veja Thunderbird: data errada apos migracao para mais detalhes.
Interface web do Gmail
O cliente web do Gmail usa o cabecalho Date para sua exibicao principal de data. Isso significa que o Gmail web frequentemente mostra datas corretas mesmo apos a migracao. Mas o IMAP INTERNALDATE no servidor Gmail continua incorreto, o que afeta cada cliente IMAP que se conecta a essa conta Gmail. A diferenca entre o Gmail web e o Outlook ou Apple Mail e uma fonte frequente de confusao, e uma que faz os administradores perderem muito tempo de diagnostico.
Por que o IMAP APPEND quebra as datas
O que acontece durante a migracao
Quando uma ferramenta de migracao move um email do Servidor A para o Servidor B, a ferramenta se conecta ao Servidor A via IMAP e baixa a mensagem bruta, depois se conecta ao Servidor B e usa o comando APPEND para inseri-la. Durante essa insercao, o Servidor B trata a mensagem recebida e adiciona um novo cabecalho Received com o timestamp corrente: a data de migracao. Esse e o comportamento IMAP padrao definido no protocolo. O servidor trata cada APPEND como uma nova entrega de mensagem.
O resultado: uma cadeia de cabecalhos contaminada
Apos a migracao, os cabecalhos Received do email se parecem com isto:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
O cabecalho Received da ferramenta de migracao agora e a entrada mais alta. Qualquer cliente de email que use o cabecalho Received mais recente para determinar a data de exibicao (Outlook, em particular) exibira "11 de abril de 2025" em vez de "15 de janeiro de 2024". O cabecalho Date original e os cabecalhos Received originais continuam intactos abaixo, mas nao estao mais na posicao que os clientes de email privilegiam.
Mesmo um bom tratamento do INTERNALDATE nao previne isso
Algumas ferramentas de migracao definem corretamente o INTERNALDATE durante o APPEND. Por exemplo, o imapsync preserva explicitamente o INTERNALDATE do servidor de origem. Mas o cabecalho Received e adicionado pelo servidor de destino, nao pela ferramenta de migracao. A ferramenta de migracao nao tem controle sobre esse comportamento. Mesmo com preservacao perfeita do INTERNALDATE, o cabecalho Received mais alto ainda contem a data de migracao, e clientes como o Outlook ainda exibem a data errada.
Enfim, o que se pode concretamente fazer a respeito?
Quais ferramentas de migracao adicionam cabecalhos Received
Todas as ferramentas de migracao IMAP causam esse problema porque o cabecalho Received e adicionado pelo servidor de destino, nao pela ferramenta em si. O conteudo do cabecalho adicionado varia conforme a ferramenta e o servidor.
O BitTitan MigrationWiz adiciona um cabecalho Received contendo "mx.migrationwiz.com". O CloudM Migrate adiciona cabecalhos referenciando "cloudm.io". O imapsync aciona um cabecalho Received generico do servidor de destino. O GSMMO adiciona cabecalhos com referencias a "gmailapi.google.com".
A correcao: restaurar as datas corretas
A boa noticia e que a informacao de data correta ainda existe em cada email. O cabecalho Date original esta intacto. Os cabecalhos Received originais estao intactos. O problema e que um cabecalho contaminante esta sentado acima deles.
O motor de correcao proprietario do Redate.io analisa a cadeia completa de cabecalhos de cada email afetado, aplicando correspondencia de assinaturas em centenas de assinaturas de ferramentas de migracao conhecidas para identificar exatamente quais cabecalhos necessitam de correcao. O pipeline de analise multistagio lida com casos extremos que fazem abordagens mais simples falharem: mensagens assinadas com S/MIME, conteudo criptografado com PGP, estruturas multipart/alternative, problemas de Content-Transfer-Encoding, cabecalhos non-ASCII (RFC 2047), anexos grandes e fronteiras MIME corrompidas.
Apos a correcao, cada email passa por um processo de verificacao de integridade para confirmar que a estrutura, conteudo e anexos da mensagem estao preservados de forma identica. Os originais sao mantidos em uma pasta de backup visivel por 30 dias.
Seria possivel escrever um script para tentar essa correcao por conta propria? Tecnicamente, sim. Mas a diferenca entre "funciona em 95% dos emails" e "funciona em 100% dos emails sem corromper um unico" representa meses de desenvolvimento. E quando se trata da caixa completa de alguem, uma taxa de falha de 5% significa centenas de mensagens silenciosamente danificadas sem forma de verificar o que deu errado.
Quer saber quantos emails na sua caixa tem datas erradas? Inicie uma analise gratuita com o Redate.io para obter uma contagem instantanea dos emails afetados, sem pagamento necessario.