Alterar data de email recebido

A pergunta que todo mundo faz (e por que ela esconde duas situações bem diferentes)

Digite "alterar data de email recebido" no Google. Você encontra dezenas de tópicos no Microsoft Q&A, threads no Reddit, perguntas no Quora. A dúvida é clara, mas os motivos por trás dela são radicalmente diferentes dependendo de quem pergunta.

Tem quem queira falsificar uma data retroativamente, por razões que prefiro não imaginar. E tem administradores de TI que, depois de uma migração IMAP, veem todos os emails exibindo o mesmo dia (o da migração) e querem simplesmente recuperar as datas originais. Essas duas situações não têm nada a ver uma com a outra, mas compartilham a mesma busca no Google.

Este artigo responde às duas. Spoiler: no primeiro caso, a modificação não é realmente possível de forma indetectável. No segundo, ela é totalmente legítima, e é exatamente isso que o Redate.io faz.

Antes de tudo: o que é a "data" de um email?

Um email não contém uma única data. Ele contém várias, armazenadas em lugares diferentes, controladas por entidades diferentes.

O cabeçalho Date: (RFC 2822)

É a data que o cliente do remetente insere na mensagem no momento do envio. Ela aparece nos cabeçalhos brutos assim:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Esse cabeçalho faz parte do corpo da mensagem. Tecnicamente, ele pode ser modificado se você acessar o arquivo bruto. Mas "tecnicamente" é a palavra-chave aqui.

Os cabeçalhos Received:

Cada servidor de e-mail pelo qual uma mensagem passa adiciona seu próprio cabeçalho Received: com um timestamp. Esses cabeçalhos formam uma cadeia cronológica, do servidor do remetente até sua caixa. (Aliás, se você já tentou ler os cabeçalhos brutos de um email, sabe que não é exatamente leitura de praia. São dezenas de linhas de metadados técnicos, numa ordem que vai do mais recente para o mais antigo.)

O INTERNALDATE do IMAP

É o metadado mais importante para entender por que certas modificações não têm nenhum efeito visível. O INTERNALDATE é um atributo armazenado no lado do servidor IMAP, independentemente do conteúdo da mensagem. É ele que a maioria dos clientes de e-mail usa para ordenar as mensagens nas pastas. O Outlook usa. O Gmail também. O Apple Mail, na maioria dos casos, idem.

O INTERNALDATE não está dentro da mensagem. Ele está no banco de dados do servidor. Você não consegue modificá-lo editando um arquivo .eml no seu computador.

O que realmente acontece quando você edita localmente

Editar um arquivo .eml

Um arquivo .eml é tecnicamente um arquivo de texto. Você pode abri-lo num editor, mudar a linha Date:, salvar. Se reimportar esse arquivo num cliente de e-mail local, a data exibida pode mudar, dependendo do cliente.

Mas eis o que isso não altera:

O INTERNALDATE no servidor IMAP (permanece intacto)
Os cabeçalhos Received: adicionados pelos servidores intermediários
Os logs de entrega no Google, Microsoft ou seu provedor
A assinatura DKIM, se a mensagem tinha uma

Resultado: na sua máquina local, você talvez veja uma data diferente. No Outlook conectado ao Exchange Online, ou no Gmail pelo navegador, nada mudou.

Alterar o relógio do sistema

Alguns fóruns sugerem mudar o relógio da estação de trabalho para "enganar" o cliente de e-mail. Não funciona. O Outlook e o Gmail não leem o horário do sistema para exibir as datas dos emails recebidos. Eles leem o INTERNALDATE do servidor, ou os cabeçalhos da mensagem. O relógio local não entra nesse processo em nenhum momento.

A manipulação via Thunderbird

O Thunderbird oferece mais flexibilidade do que a maioria dos clientes. Com extensões ou manipulando diretamente o perfil (arquivos mbox, arquivos .msf), alguns tentam modificar a exibição das datas. Pode funcionar dentro do próprio Thunderbird, para emails armazenados localmente em modo POP3. Mas assim que o Thunderbird está conectado via IMAP, ele ressincroniza com o servidor. A "correção" desaparece na próxima sincronização.

DKIM: a barreira invisível que ninguém menciona

A maioria dos emails enviados desde 2018 é assinada com DKIM (DomainKeys Identified Mail). Uma assinatura DKIM aparece assim nos cabeçalhos:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

O campo h= lista os cabeçalhos cobertos pela assinatura. No exemplo acima, Date está assinado. Se você modificar o cabeçalho Date: da mensagem, a verificação DKIM falha. Qualquer servidor de e-mail, qualquer ferramenta de análise forense, consegue detectar a modificação recalculando a assinatura.

Não é uma proteção perfeita (um remetente mal-intencionado controla sua própria chave DKIM e pode assinar o que quiser no momento do envio). Mas para um email já recebido e assinado, modificar o cabeçalho Date: deixa um rastro detectável.

Os logs do servidor: a verdadeira fonte de verdade

Mesmo que você consiga modificar todos os metadados visíveis de um email (cabeçalhos, INTERNALDATE, tudo), os provedores mantêm seus próprios registros.

O Google Workspace registra cada mensagem nos logs de auditoria do Admin Console. O Microsoft 365 faz o mesmo no Centro de Conformidade (Purview). Esses logs incluem os timestamps de entrega, independentemente do que é exibido nos clientes. Um advogado, um departamento jurídico ou uma equipe de segurança de TI pode recuperar esses dados. A data visível no Outlook não tem validade jurídica num tribunal ou numa auditoria de segurança.

Para ser preciso: nem mesmo um administrador com acesso à caixa via delegação de domínio consegue reescrever esses logs retroativamente. Eles estão fora do alcance dos usuários, mesmo dos privilegiados.

O caso legítimo: a correção pós-migração

Você acabou de concluir uma migração de 150 caixas de um Exchange on-premises para o Microsoft 365. Na segunda-feira seguinte, os tickets chegam: "todos os meus emails antigos estão datados de sexta-feira passada". A data da migração.

Esse é um problema bem documentado e completamente diferente do que acabamos de descrever. Aqui, ninguém quer falsificar nada. As datas originais reais ainda existem, intactas, no cabeçalho Date: de cada mensagem. O problema vem de outro lugar: a ferramenta de migração (BitTitan MigrationWiz, CloudM, imapsync, ou outra) inseriu um cabeçalho Received: com a data da migração no topo da cadeia. O Outlook, que em certos contextos se baseia nos cabeçalhos Received: mais recentes em vez do INTERNALDATE, exibe essa data no lugar.

Nesse caso, a "correção" consiste em restaurar a coerência entre o que a mensagem diz (o cabeçalho Date: original, ainda presente) e o que o servidor registra (o INTERNALDATE, definido no momento da migração). Isso não é falsificação. É restauração.

É exatamente o problema que uma migração mal configurada impõe a milhares de caixas. E é isso que o Redate.io resolve.

Por que fazer você mesmo falha em escala

Entender o problema é uma coisa. Corrigi-lo em 40.000 emails distribuídos por 150 caixas sem perder um único, é outra completamente diferente.

Os scripts que circulam no GitHub ou no Stack Overflow funcionam em 20 emails de teste. Em produção, eles travam por motivos que o autor do script não antecipou:

Emails assinados com S/MIME ou criptografados com PGP têm estruturas que não se manipulam como mensagens comuns
Mensagens multipart com delimitadores MIME não padronizados causam erros de parsing
Cabeçalhos codificados em RFC 2047 (caracteres não-ASCII nos campos From: ou Subject:) quebram parsers simples
As APIs do Google e da Microsoft impõem limites de taxa (rate limiting): às 3h da manhã durante um lote de 30.000 emails, o erro 429 Too Many Requests não é tratado, o script para, e ninguém sabe onde parou
Nenhum mecanismo de rollback: se uma mensagem for corrompida durante o processamento, não há como voltar atrás

O Redate.io mantém uma cópia de cada email original numa pasta de backup visível por 30 dias. Cada correção é verificada individualmente. O pipeline de análise lida com centenas de assinaturas de ferramentas de migração conhecidas, além de todos os casos limítrofes que um script caseiro não trataria.

Para aprofundar as especificidades por ferramenta: BitTitan MigrationWiz e as datas de e-mail, ou CloudM Migrate: como corrigir datas de email erradas.

O que muda, o que nunca muda

Ação	Exibição no cliente local	INTERNALDATE no servidor	Logs do provedor	Verificação DKIM
Editar um arquivo .eml	Às vezes alterada	Inalterado	Inalterado	Inválida se Date: assinado
Alterar o relógio do sistema	Nenhum efeito	Inalterado	Inalterado	Inalterado
Manipulação via Thunderbird (IMAP)	Alterada temporariamente	Inalterado	Inalterado	Inalterado
Correção Redate.io (pós-migração)	Corrigida	Corrigido	Inalterado	Preservada

A distinção é clara. As três primeiras linhas da tabela descrevem modificações superficiais ou detectáveis. A última descreve uma correção legítima dos metadados, alinhada com o conteúdo original da mensagem, após uma migração que introduziu uma inconsistência.

Se você está na situação descrita na última linha da tabela, depois de uma migração com imapsync, BitTitan, CloudM ou outra ferramenta, o Redate.io foi feito para isso.

Seus emails estão mostrando a data da migração no lugar das datas reais? Escaneie suas caixas gratuitamente com o Redate.io e veja exatamente quantos emails foram afetados antes de decidir.

Alterar a data de um email recebido: verdade ou mito?