IMAP INTERNALDATE: por que as datas quebram

As três datas dentro de cada email

Cada email armazenado em um servidor IMAP carrega pelo menos três valores de data distintos. Entender como essas datas funcionam, e como os clientes de email escolhem qual exibir, é a chave para compreender por que a migração quebra as datas. Este artigo é uma análise técnica 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 pós-migração.

1. O cabeçalho "Date" RFC 2822

O cabeçalho "Date" é definido na RFC 2822 (formato de mensagens da Internet). Ele é definido pelo cliente de email do remetente no momento em que a mensagem é composta e enviada. Esse cabeçalho faz parte do corpo da mensagem em si, viaja com a mensagem e nunca é modificado pelos servidores de email no caminho de entrega. Um cabeçalho Date típico se parece com:

Date: Mon, 15 Jan 2024 09:32:17 +0100

O cabeçalho Date representa a "data de envio" da mensagem. É a data mais confiável porque é definida uma única vez e nunca alterada. No entanto, reflete o relógio do remetente, que pode estar mal configurado. Em casos raros, o cabeçalho Date pode estar totalmente ausente (especialmente em notificações de sistema automatizadas ou mensagens malformadas).

2. O IMAP INTERNALDATE

O INTERNALDATE é definido na RFC 3501 (protocolo IMAP4rev1). É um valor de metadado do lado do servidor que representa a data e hora em que a mensagem foi entregue ao servidor. Diferentemente do cabeçalho Date, o INTERNALDATE não faz parte da mensagem de email em si. É armazenado separadamente pelo servidor IMAP como metadado.

Quando um email é entregue normalmente (não migrado), o servidor IMAP define o INTERNALDATE como a hora corrente no momento da entrega. Esse valor corresponde de perto ao cabeçalho Date, geralmente com diferença 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.

É aqui que a coisa fica interessante. Quando uma mensagem é inserida via comando IMAP APPEND (o que as ferramentas de migração usam), o comando APPEND permite ao cliente especificar o INTERNALDATE explicitamente. Ferramentas de migração bem projetadas usam essa funcionalidade para preservar o INTERNALDATE original do servidor de origem. Mas mesmo quando o INTERNALDATE é definido corretamente, o problema do cabeçalho "Received" (descrito abaixo) pode sobrescrever a data exibida em muitos clientes.

3. A cadeia de cabeçalhos "Received"

Cada vez que um email passa por um servidor de email, esse servidor adiciona um cabeçalho "Received" no início da mensagem. Isso cria uma cadeia de cabeçalhos Received que registra o percurso do email do remetente ao destinatário. O mais recente (no topo) mostra o último servidor que processou a mensagem, e o mais antigo (embaixo) mostra o primeiro.

Um email normal pode ter de 3 a 6 cabeçalhos Received, documentando a viagem desde o servidor de saída do remetente, através de relays, até o servidor de entrada do destinatário. Cada cabeçalho Received inclui um timestamp. Aqui está 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 combinação do INTERNALDATE e do cabeçalho "Received" mais recente para determinar a data de "Recebimento" exibida na caixa de entrada. Na prática, o Outlook tende a privilegiar o timestamp do cabeçalho Received mais recente para a coluna "Recebido". A coluna "Enviado" usa o cabeçalho Date. Como o Outlook ordena por padrão pela coluna "Recebido", é o timestamp do cabeçalho Received que os usuários 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 migração, o Apple Mail pode exibir a data correta, mas apenas se o INTERNALDATE foi explicitamente definido na operação APPEND. Se a ferramenta de migração não definiu o INTERNALDATE, o servidor usa por padrão a hora de inserção (a data de migração). Para detalhes sobre o impacto para usuários do Apple Mail, veja Apple Mail: data errada após migração.

Thunderbird

O Mozilla Thunderbird oferece a maior flexibilidade. Pode exibir tanto "Data" (do cabeçalho Date) quanto "Recebido" (dos cabeçalhos Received). Por padrão, o Thunderbird exibe o valor do cabeçalho Date, o que significa que as datas podem parecer corretas no Thunderbird mesmo quando estão erradas no Outlook. A coluna "Recebido" no Thunderbird sempre exibe a data de migração. Veja Thunderbird: data errada após migração para mais detalhes.

Interface web do Gmail

O cliente web do Gmail usa o cabeçalho Date para sua exibição principal de data. Isso significa que o Gmail web frequentemente mostra datas corretas mesmo após a migração. Mas o IMAP INTERNALDATE no servidor Gmail continua incorreto, o que afeta cada cliente IMAP que se conecta a essa conta Gmail. A diferença entre o Gmail web e o Outlook ou o Apple Mail é uma fonte frequente de confusão, e uma que faz os administradores perderem muito tempo de diagnóstico.

Por que o IMAP APPEND quebra as datas

O que acontece durante a migração

Quando uma ferramenta de migração 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 inserção, o Servidor B processa a mensagem recebida e adiciona um novo cabeçalho Received com o timestamp corrente: a data de migração. Esse é o comportamento IMAP padrão definido no protocolo. O servidor trata cada APPEND como uma nova entrega de mensagem.

O resultado: uma cadeia de cabeçalhos contaminada

Após a migração, os cabeçalhos 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 cabeçalho Received da ferramenta de migração agora é a entrada mais alta. Qualquer cliente de email que use o cabeçalho Received mais recente para determinar a data de exibição (o Outlook, em particular) exibirá "11 de abril de 2025" em vez de "15 de janeiro de 2024". O cabeçalho Date original e os cabeçalhos Received originais continuam intactos abaixo, mas não estão mais na posição que os clientes de email privilegiam.

Mesmo um bom tratamento do INTERNALDATE não previne isso

Algumas ferramentas de migração definem corretamente o INTERNALDATE durante o APPEND. Por exemplo, o imapsync preserva explicitamente o INTERNALDATE do servidor de origem. Mas o cabeçalho Received é adicionado pelo servidor de destino, não pela ferramenta de migração. A ferramenta de migração não tem controle sobre esse comportamento. Mesmo com preservação perfeita do INTERNALDATE, o cabeçalho Received mais alto ainda contém a data de migração, e clientes como o Outlook ainda exibem a data errada.

Enfim, o que se pode fazer a respeito, na prática?

Quais ferramentas de migração adicionam cabeçalhos Received

Todas as ferramentas de migração IMAP causam esse problema porque o cabeçalho Received é adicionado pelo servidor de destino, não pela ferramenta em si. O conteúdo do cabeçalho adicionado varia conforme a ferramenta e o servidor.

O BitTitan MigrationWiz adiciona um cabeçalho Received contendo "mx.migrationwiz.com". O CloudM Migrate adiciona cabeçalhos referenciando "cloudm.io". O imapsync aciona um cabeçalho Received genérico do servidor de destino. O GSMMO adiciona cabeçalhos com referências a "gmailapi.google.com".

A correção: restaurar as datas corretas

A boa notícia é que a informação de data correta ainda existe em cada email. O cabeçalho Date original está intacto. Os cabeçalhos Received originais estão intactos. O problema é que um cabeçalho contaminante está posicionado acima deles.

O motor de correção proprietário do Redate.io analisa a cadeia completa de cabeçalhos de cada email afetado, identificando anomalias de data para determinar exatamente quais cabeçalhos precisam de correção, independentemente da ferramenta de migração utilizada. O pipeline de análise multiestágio lida com casos extremos que fazem abordagens mais simples falharem: mensagens assinadas com S/MIME, conteúdo criptografado com PGP, estruturas multipart/alternative, problemas de Content-Transfer-Encoding, cabeçalhos não-ASCII (RFC 2047), anexos grandes e fronteiras MIME corrompidas.

Após a correção, cada email passa por um processo de verificação de integridade para confirmar que a estrutura, o conteúdo e os anexos da mensagem estão preservados de forma idêntica. Os originais nunca são excluídos automaticamente: são movidos para uma pasta de backup visível na caixa de correio, onde permanecem até que o cliente decida removê-los.

Seria possível escrever um script para tentar essa correção por conta própria? Tecnicamente, sim. Mas a diferença entre "funciona em 95% dos emails" e "funciona em 100% dos emails sem corromper um único" é onde meses de engenharia são investidos. E quando se trata da caixa de entrada completa de alguém, essa 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 têm datas erradas? Inicie uma análise gratuita com o Redate.io para obter uma contagem instantânea dos emails afetados, sem necessidade de pagamento.