Migração POP para IMAP: seus emails antigos datam de hoje

O cenário clássico da manhã de segunda-feira

Você acabou de migrar sua conta de email de POP3 para IMAP. A configuração foi simples, seu provedor te guiou, tudo correu bem. Até você reabrir a caixa de entrada. Seus emails de 2019, 2021, seus arquivos do ano passado... todos mostram a mesma data: hoje. Às vezes até o mesmo horário, com diferença de alguns segundos.

Não é um bug do seu cliente de email. Não é um problema de fuso horário. É o comportamento esperado do protocolo IMAP, e afeta qualquer pessoa que remonta emails armazenados localmente para um servidor via esse método.

POP3 vs IMAP: uma diferença fundamental de armazenamento

Para entender por que o problema acontece, é preciso primeiro entender como o POP3 funciona, e em que ele é radicalmente diferente do IMAP.

Com POP3, o servidor funciona apenas como uma caixa de correio temporária. Seu cliente (Outlook, Thunderbird, Apple Mail) se conecta, baixa as mensagens e as apaga do servidor (ou as mantém, dependendo da sua configuração). Os emails passam a viver exclusivamente em local: num arquivo .pst no Outlook, no perfil local do Thunderbird, num banco de dados no seu disco rígido.

Com IMAP, é o contrário: os emails vivem no servidor. Seu cliente só exibe o que está armazenado remotamente. Daí a sincronização transparente entre todos os seus dispositivos.

O problema surge na transição entre os dois. Quando você remonta seus emails POP locais para o servidor IMAP.

IMAP APPEND: o comando que muda tudo

Quando seu cliente de email remonta uma mensagem local para um servidor IMAP, ele usa o comando IMAP APPEND. Esse comando diz ao servidor: "armazene esta mensagem nesta pasta".

O servidor recebe a mensagem, a registra e atribui um timestamp. Esse timestamp é o INTERNALDATE. É a metadado central do IMAP: ele indica quando a mensagem foi depositada no servidor. E por padrão, se o cliente não especificar explicitamente uma data no comando APPEND, o servidor usa... o momento presente.

Em outras palavras: não importa que a mensagem contenha nos cabeçalhos uma data de 2018. Se ninguém disser ao servidor "este email é de 2018", o servidor conclui que foi depositado agora e atribui o INTERNALDATE de hoje.

(Aliás, se você já olhou os cabeçalhos brutos de um email, viu a linha Date: no meio de uma dezena de outras linhas Received:. É esse campo Date:, definido pela RFC 2822, que contém a data real de envio. Mas o INTERNALDATE do IMAP é uma metadado separada, armazenada no servidor, que não tem nada a ver com o conteúdo da mensagem em si.)

Por que é diferente de uma migração IMAP para IMAP

Numa migração clássica de um servidor IMAP para outro (com BitTitan, CloudM, imapsync, etc.), o problema é ligeiramente diferente. A ferramenta de migração copia as mensagens de um servidor para o outro e, nesse caso, pode (em teoria) transmitir o INTERNALDATE original para o servidor de destino via o comando APPEND. O problema lá é que certas ferramentas adicionam um cabeçalho Received: com a data da migração, o que perturba a exibição em clientes como o Outlook.

No seu caso, você parte de dados puramente locais. Não há INTERNALDATE de origem para copiar. O arquivo .pst ou o perfil do Thunderbird armazena as mensagens em seu próprio formato proprietário, com seus próprios metadados internos. Quando o cliente de email relê essas mensagens para remontar ao servidor IMAP, ele reconstrói o comando APPEND a partir do conteúdo da mensagem. E na maioria das vezes, não transmite nenhuma data explícita.

Resultado: o servidor IMAP recebe centenas ou milhares de mensagens nos minutos seguintes e atribui a todas o mesmo intervalo de tempo: agora.

É exatamente por isso que o problema se propaga para todos os seus dispositivos instantaneamente. Seu celular, seu tablet, seu segundo computador: todos se conectam ao mesmo servidor IMAP e veem exatamente a mesma coisa. Sem possibilidade de correção do lado do cliente.

Qual cliente exibe o quê, e por quê

Nem todos os clientes de email reagem da mesma forma. Esse é um ponto que muitos admins de TI descobrem depois do fato.

Outlook (nas versões recentes, especialmente desde as atualizações de 2023-2024) usa o INTERNALDATE do servidor para a coluna "Recebido". Exibe então a data da remontagem, não a data de envio original. Para saber mais sobre esse comportamento específico do Outlook, veja: Outlook: data recebida IMAP vs data de envio.

Gmail / Google Workspace e Thunderbird têm comportamentos um pouco mais variados. O Gmail, por exemplo, pode às vezes usar o campo Date: do cabeçalho da mensagem para exibição, o que dá a impressão de que está tudo bem... até você tentar ordenar por data e perceber que a ordem está completamente fora de sequência.

Apple Mail geralmente exibe a data extraída do cabeçalho Date:, mas a ordenação e a busca passam pelo INTERNALDATE em segundo plano. Com isso, seus emails podem "parecer" bem datados visualmente, mas a funcionalidade de ordenação não funciona mais corretamente. Para detalhes sobre o comportamento do Apple Mail, veja Apple Mail: data errada após migração.

A boa notícia: a data original está intacta

O cabeçalho Date: de cada email, aquele que contém a data real de envio (ou de recebimento), não foi tocado. Ele ainda está lá, no corpo da mensagem. É ele que você vê quando abre um email e olha os detalhes.

O que o servidor IMAP "quebrou" é apenas o INTERNALDATE, esse metadado externo à mensagem. A mensagem em si está intacta.

É o que torna a correção possível. E também explica por que o problema pode passar despercebido por um tempo: os emails parecem corretos quando você os abre um a um. Só ao olhar a lista da sua caixa de entrada, ordenada por data, o problema fica visível. Emails de 2019 aparecem no topo como se tivessem acabado de chegar. Todos com a mesma data.

O problema de escala: 3.000 emails é diferente de 3

Você pode estar pensando: "É só apagar e reimportar, desta vez corretamente." Com 5 ou 10 emails de teste, funciona. Numa caixa com 8.000 mensagens, pastas aninhadas, anexos volumosos, emails assinados com S/MIME e conversas que remontam a 2015... é outra história.

Um script caseiro que funciona num lote de teste de 50 emails pode muito bem gerar duplicatas, perder anexos ou quebrar conversas numa caixa de produção. A gestão de cotas de API, timeouts de rede, mensagens com estruturas MIME atípicas... são casos extremos que uma ferramenta não especializada simplesmente não trata.

E se algo der errado no meio do processo? Sem mecanismo de backup e rollback, você perde dados sem como recuperá-los.

O problema é bem conhecido dos admins que gerenciam migrações em volume. Entender por que as datas estão quebradas é uma coisa. Corrigir corretamente 15.000 emails preservando cada estrutura de mensagem é outra. Para aprofundar esse tema, o artigo É possível corrigir as datas dos emails após migração? detalha as diferentes abordagens e seus limites.

Como o Redate.io trata este caso específico

Redate.io foi desenvolvido precisamente para esse tipo de situação. O motor de análise identifica os emails cujo INTERNALDATE não corresponde à data contida nos cabeçalhos da mensagem, seja numa migração POP para IMAP, numa migração entre servidores IMAP, ou numa remontagem manual de arquivos locais.

O pipeline de análise em múltiplas etapas inspeciona a cadeia de cabeçalhos de cada mensagem, valida a conformidade com a RFC e reconstrói os metadados de data sem alterar o conteúdo da mensagem: nem o texto, nem os anexos, nem a estrutura MIME, nem eventuais assinaturas digitais. Cada email corrigido é verificado individualmente antes da validação.

Os originais são mantidos numa pasta de backup visível por 30 dias. Se algo não estiver do jeito que você esperava, é possível restaurar.

O scan inicial é gratuito: Redate analisa sua caixa, identifica os emails afetados e informa o número exato antes de você decidir qualquer coisa. Sem compromisso às cegas.

Redate.io se conecta diretamente às suas caixas via Google Workspace (delegação de domínio), Microsoft 365 (Azure AD) ou IMAP direto. Nenhuma instalação local. Nenhum arquivo .pst para manipular manualmente.

Para admins que gerenciam várias caixas e querem um retorno de experiência sobre esse tipo de caso, o artigo MSP: corrigir as datas de email dos clientes é uma boa leitura complementar. E para as especificidades da correção no Thunderbird, que tem seu próprio comportamento na transição POP/IMAP, veja Thunderbird: data errada após migração.

Se ainda está por fazer: como antecipar o problema

Se você ainda não remontou seus arquivos locais para o servidor IMAP, ou se planeja migrar outras contas POP na sua organização, eis o que ter em mente.

• Verifique se seu cliente de email suporta o envio explícito da data no comando APPEND. O Thunderbird, por exemplo, teve comportamentos variáveis dependendo da versão nesse ponto.
• Faça primeiro um teste numa conta de validação com 50 a 100 mensagens representativas: emails antigos, com anexos, emails assinados. Verifique as datas exibidas em diferentes clientes.
• Planeje a correção antes que os usuários finais comecem a trabalhar na caixa migrada. Corrigir as datas numa caixa ativa é mais complexo do que numa caixa recém-migrada e ainda sem uso.
• Documente o número de emails antes e depois da migração. É a única forma de detectar perdas silenciosas.

Para um checklist completo dos pontos a verificar antes e depois de uma migração, o artigo Checklist migração de email: prevenir problemas de datas cobre todos os casos.

Seus emails antigos estão exibindo a data de hoje após a migração de POP para IMAP? Inicie um scan gratuito no Redate.io para medir a extensão do problema e corrigir os metadados de data sem tocar no conteúdo das suas mensagens.