eM Client: datas erradas após import PST ou Thunderbird

O sintoma: todos os seus emails com a mesma data

Você acabou de concluir um import PST no eM Client, ou migrou do Thunderbird para a sua nova caixa de entrada. O processo transcorreu sem erros aparentes. Mas ao abrir a caixa, algo está errado: centenas, às vezes milhares de emails exibem todos a mesma data, a do dia do import. Um email de 2019 parece ter sido recebido ontem. Um contrato assinado há três anos aparece como se tivesse acabado de chegar.

A primeira reação natural é culpar o eM Client. Configuração errada, coluna de ordenação errada, bug de exibição... Você vai nas preferências. Alterna entre "Data de recebimento" e "Data de envio". Nada muda. Ou melhor, algo muda, mas o problema de fundo continua.

É porque o problema não está no eM Client. Está nos metadados do servidor.

A causa real: o INTERNALDATE IMAP sobrescrito durante o import

Para entender o que acontece, é preciso descer um nível e ver como o protocolo IMAP armazena os emails.

Cada mensagem em um servidor IMAP possui dois tipos de datas distintas:

• O cabeçalho Date: (definido pela RFC 2822): é a data que o remetente inscreveu na mensagem no momento do envio. Está encapsulada no corpo da mensagem, intocável em teoria.
• O INTERNALDATE: um metadado do servidor, externo à mensagem, que representa a data em que a mensagem foi depositada na caixa. É esse valor que os clientes de email usam prioritariamente para ordenar e exibir as mensagens.

Durante um import PST ou uma migração a partir do Thunderbird, a ferramenta de import (seja o módulo nativo do eM Client, uma ferramenta de terceiros ou uma cópia IMAP manual) deposita as mensagens no servidor IMAP de destino. E aí, se a ferramenta não preservar explicitamente o INTERNALDATE original no momento do depósito, o servidor atribui automaticamente o INTERNALDATE atual, ou seja, a data e hora do import.

Resultado: 8.000 emails arquivados desde 2017, todos carimbados como "recebidos" no momento da migração.

(Aliás, se você já tentou ler os cabeçalhos brutos de um email com Ver código-fonte no eM Client, deve ter notado que o cabeçalho Date: original ainda está lá, intacto. Isso é um sinal claro de que o problema vem do INTERNALDATE do servidor, não da mensagem em si.)

Por que mudar a coluna de ordenação não resolve nada

A confusão vem de uma distinção que pouca gente conhece. No eM Client, assim como no Outlook ou no Thunderbird, geralmente existem duas colunas de data:

• "Data de recebimento" (ou "Data de chegada"): baseada no INTERNALDATE do servidor.
• "Data" ou "Data de envio": baseada no cabeçalho Date: da mensagem.

Muitos administradores descobrem isso e pensam ter encontrado a solução: mudar para "Data de envio" e o problema some visualmente no eM Client. Mas não é bem assim.

Na verdade, mesmo ordenando por data de envio no eM Client, o problema persiste para todos os outros clientes e todas as outras interfaces que acessam a mesma caixa. Se os usuários consultam os emails pelo OWA, pelo Outlook no escritório, pelo aplicativo Gmail no celular ou por qualquer cliente configurado em IMAP, eles vão ver as datas do import. A configuração de ordenação do eM Client só se aplica ao eM Client, e não age sobre os metadados armazenados no servidor.

Além disso, no Microsoft 365 e no Google Workspace, a interface web nativa ordena por INTERNALDATE. Você não pode alterar esse comportamento a partir do cliente.

Ordenar por data de envio não é uma solução. É um curativo que esconde um problema real sem corrigi-lo.

O caso específico do import PST

O import de arquivos PST merece um parágrafo à parte. Um arquivo PST (Personal Storage Table) é um formato proprietário da Microsoft que armazena emails, contatos e calendários localmente. Quando você importa um PST no eM Client, dois cenários são possíveis:

• Import local para uma conta IMAP: o eM Client lê o PST e envia as mensagens para o servidor IMAP de destino. Se a data do depósito não for preservada, o INTERNALDATE é sobrescrito. É o caso mais frequente, e é aqui que as datas ficam corrompidas.
• Import para uma pasta local: as mensagens ficam na máquina, fora do servidor. O INTERNALDATE não existe nesse contexto, e o eM Client pode exibir a data Date: da mensagem. Menos problema de data aqui, mas também menos utilidade prática.

Para o Thunderbird, a situação é parecida. Se você usa a função de import integrada do eM Client (que lê os perfis do Thunderbird) ou copiou pastas mbox via IMAP, as mensagens são redepositadas no servidor sem garantia de preservação do INTERNALDATE. E um servidor que recebe uma mensagem sem instrução explícita de data para o INTERNALDATE vai sistematicamente registrar o horário de recebimento.

Quais plataformas são afetadas?

O problema é idêntico independentemente da plataforma de destino, porque se trata de um comportamento padrão do protocolo IMAP:

• Microsoft 365 / Exchange Online: o INTERNALDATE é sobrescrito em qualquer import que não use o comando IMAP APPEND com um parâmetro de data explícito. O mesmo vale para migrações a partir do Exchange on-premise.
• Google Workspace: mesmo comportamento. Os emails importados via eM Client ou ferramentas de terceiros exibem a data do import no Gmail e na interface administrativa.
• Hospedagens IMAP convencionais (OVH, Infomaniak, Ionos, o2switch, etc.): nenhum tratamento especial de data ao receber uma mensagem em APPEND. O INTERNALDATE será a data do depósito.

Um cliente nos contactou depois de migrar uma boa centena de caixas de um Exchange 2013 para o Microsoft 365, usando o eM Client como ferramenta de transição para algumas contas VIP. Resultado: as caixas migradas corretamente via MigrationWiz estavam certas, mas as caixas que passaram pelo eM Client tinham todas as datas do import. Os usuários afetados, é claro, não ficaram satisfeitos.

Por que um script caseiro não resolve isso facilmente

Tecnicamente, alguém que entende o protocolo IMAP poderia pensar em escrever um script para corrigir os INTERNALDATEs. O cabeçalho Date: original está lá, intacto em cada mensagem. Bastaria lê-lo e reconstruir os metadados do servidor a partir daí, certo?

Em teoria, sim. Na prática, é um campo minado.

Primeiro, os casos limítrofes se acumulam rapidamente em uma caixa de produção. Mensagens S/MIME com assinatura digital são particularmente sensíveis a qualquer manipulação de estrutura. Mensagens PGP criptografadas também. Emails com anexos volumosos, fronteiras MIME não padronizadas ou codificações Content-Transfer-Encoding incomuns podem se corromper silenciosamente se o processamento não for rigoroso. Um script que funciona em 50 emails de teste não vai funcionar de forma confiável em uma caixa com 20.000 mensagens e 6 anos de histórico.

Depois, a gestão de cotas de API. No Microsoft 365, os limites de taxa na API Graph ou no EWS às 3h da manhã durante um lote de correção de 8.000 mensagens precisam ser gerenciados. Um script não supervisionado que encontra um erro 429 Too Many Requests na mensagem número 3.741 pode continuar ou não. E você não vai necessariamente saber quais mensagens foram processadas.

E sobretudo: como verificar que cada email corrigido está intacto após o processamento? Um script caseiro geralmente não tem mecanismo de verificação individual. Redate.io faz isso automaticamente, para cada mensagem.

Corrigir as datas na raiz com o Redate.io

Redate.io ataca o problema onde ele está: no nível dos metadados do servidor, não no nível do cliente de email.

O processo começa por uma fase de scan gratuita. Redate.io se conecta à caixa em questão (Microsoft 365 via Azure AD, Google Workspace via delegação de domínio, ou IMAP direto para hospedagens convencionais) e identifica os emails cujos metadados de data são inconsistentes com o conteúdo da mensagem. Você vê o resultado antes de pagar qualquer coisa.

A correção usa um motor proprietário que analisa a cadeia completa de cabeçalhos de cada mensagem, aplica correspondência de padrões em centenas de assinaturas de ferramentas de import conhecidas (incluindo os comportamentos específicos do eM Client, do Thunderbird e dos imports PST) e reconstrói os metadados de data de forma direcionada, sem alterar o conteúdo da mensagem, seus anexos ou sua estrutura MIME.

Cada email corrigido é verificado individualmente. Os originais são mantidos em uma pasta de backup visível por 30 dias, algo que um script caseiro nunca fará por padrão.

A precificação é simples: pagamento único por caixa, baseado no volume de emails a corrigir. Sem assinatura, sem cobranças recorrentes. Acesse a página de início para ver os detalhes.

Para a próxima migração: o que verificar

Se você está planejando uma migração e quer evitar esse problema desde o início, o ponto de controle é simples: a ferramenta que você vai usar preserva explicitamente o INTERNALDATE ao depositar as mensagens no servidor de destino?

Para imports PST para o Microsoft 365, ferramentas certificadas pela Microsoft (como MigrationWiz em seus modos nativos, ou a ferramenta de migração do Exchange Online) geralmente cuidam dessa preservação. Para imports manuais via eM Client ou Thunderbird, raramente é o caso. Verifique a documentação da sua ferramenta antes de iniciar um import em caixas de produção.

Uma boa checklist de migração de email sempre inclui uma verificação pós-migração das datas em uma amostra de caixas. Para ir mais fundo, o artigo sobre a checklist de migração de email cobre esse ponto em detalhes.

Para administradores que gerenciam regularmente migrações para seus clientes, o artigo sobre a correção de datas de email para MSPs e o sobre o funcionamento do INTERNALDATE IMAP oferecem uma visão mais completa do problema.

As datas dos seus emails estão corrompidas após um import no eM Client? Inicie um scan gratuito no Redate.io para medir a extensão do problema antes de decidir o que fazer.