Corrigir datas imapsync

A promessa do --syncinternaldates (e onde ela para)

Você executou o comando imapsync. Incluiu --syncinternaldates porque leu a documentação e é cuidadoso assim. A migração termina, o log diz que tudo foi transferido, zero erros. Então você abre a caixa no Outlook e cada email mostra a data de ontem.

Essa é uma das frustrações mais comuns com o imapsync, e tem confundido administradores de sistemas desde pelo menos 2017. O flag --syncinternaldates deveria preservar o INTERNALDATE do IMAP durante a migração. E de fato faz isso: dá a cada cópia a data interna que o servidor de origem guarda. É exatamente aí que está a armadilha.

imapsync é uma ferramenta open-source em Perl escrita por Gilles Lamiral, e é genuinamente boa no que faz. Lida com transferências de caixas de correio IMAP-para-IMAP com um nível de confiabilidade que a maioria das ferramentas comerciais inveja. Mas o imapsync só consegue copiar as datas que encontra, e é aí que as coisas complicam.

Como as datas IMAP realmente funcionam

Existem três "datas" diferentes envolvidas em cada email, e a maioria das pessoas (incluindo alguns administradores de TI) as confundem:

O cabeçalho Date: (RFC 2822) - a data que o cliente de email do remetente carimbou quando a mensagem foi composta. Vive dentro do corpo da mensagem e nunca é modificado pelos servidores de email.
Cabeçalhos Received: - cada servidor de email que trata a mensagem adiciona um com seu próprio timestamp. Formam uma cadeia do remetente ao destinatário. O cabeçalho Received mais acima (mais recente) é o que alguns clientes de email usam para exibição.
INTERNALDATE - um timestamp do lado do servidor IMAP que controla como as mensagens são ordenadas na caixa. É definido quando a mensagem é armazenada pela primeira vez via IMAP APPEND.

Quando o imapsync migra uma mensagem, lê a mensagem do servidor de origem (incluindo seu INTERNALDATE) e a escreve no servidor de destino usando IMAP APPEND. O flag --syncinternaldates diz ao imapsync para passar o INTERNALDATE de origem ao servidor de destino durante o APPEND.

A boa notícia: o Microsoft 365, o Outlook.com e o Gmail mantêm a data que recebem. Por isso, quando as datas saem erradas, o problema está noutro lugar.

Por que as datas ainda podem estar erradas

A especificação IMAP (RFC 3501) diz que se uma data-hora for fornecida com o comando APPEND, o servidor DEVERIA usá-la. "DEVERIA" em linguagem RFC significa "faça isso a menos que tenha uma boa razão para não fazer". O Microsoft 365, o Outlook.com e o Gmail mantêm-na: uma cópia que traz a sua data original conserva-a.

O que o imapsync transmite, porém, é a data que o servidor de ORIGEM guarda para cada mensagem, não a data em que o e-mail foi enviado. Numa caixa de correio saudável, as duas coincidem. Numa caixa que já foi migrada uma vez ou restaurada a partir de uma cópia de segurança, a origem pode guardar a data dessa operação anterior, e o imapsync copia-a tal como está.

O Gmail só é um caso aparte quando a cópia passa pela própria API de importação do Gmail em vez de IMAP: essa API adiciona uma linha Received: datada do dia da cópia, e o Outlook pode mostrar essa data. O imapsync fala IMAP, por isso não é afetado.

Dovecot e Cyrus, os dois servidores IMAP open-source mais comuns, também mantêm a data do APPEND. Por isso, seja qual for o destino, a pergunta é sempre a mesma: que data a origem guardava?

Erros comuns de linha de comando imapsync que quebram datas

Além das datas de origem, administradores frequentemente tropeçam nas opções de linha de comando do imapsync, ou culpam as erradas. Estes são os erros mais frequentes:

Copiar de uma origem cujas datas já estavam erradas

O --syncinternaldates está ativado por padrão: o imapsync dá a cada cópia a data interna que o servidor de origem guarda (a sua documentação: "Sets the internal dates on host2 as the same as host1"). Se a caixa de origem for, ela própria, o resultado de uma migração anterior ou de uma restauração, as suas datas internas já podem ser as dessa operação, e o imapsync copia fielmente a data errada. É a causa mais comum, e a mais fácil de passar despercebida, porque o log mostra duas datas idênticas.

Usar --syncinternaldates com --addheader

Alguns guias recomendam usar --addheader para injetar um cabeçalho personalizado durante a migração. Adicionar um cabeçalho modifica a mensagem (mais uma linha no topo), mas não a data que o imapsync transmite, por isso não explica datas erradas. A cópia deixa apenas de ser idêntica ao original, o que importa se comparar as duas.

Confundir --minage e --maxage com preservação de datas

Os flags --minage e --maxage filtram quais mensagens migrar com base na idade. Não afetam como as datas são tratadas no destino. Já vi administradores passarem horas ajustando esses flags achando que resolveriam o problema de datas. Não resolvem.

Culpar o TLS por datas desviadas

Sobre TLS (--ssl1, --ssl2), estabelecer as ligações adiciona latência, e numa migração grande (50.000+ mensagens) isso soma horas. Não afeta as datas: cada cópia leva a data que o imapsync transmite, seja qual for a hora em que realmente chega.

Lendo logs do imapsync: o que a saída realmente diz

O imapsync produz logs detalhados, o que é ótimo. Mas a saída do log pode ser enganosa quando se trata de datas.

Uma linha típica de transferência bem-sucedida se parece com:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

As duas datas conferem. Isso significa que o imapsync enviou o INTERNALDATE correto ao destino. E o Microsoft 365, o Outlook.com e o Gmail mantêm todos a data que recebem. Mas duas datas idênticas só provam que a cópia é fiel à ORIGEM: se a data de origem já estava errada, as duas colunas mostram a mesma data errada.

Quer verificar o que realmente aconteceu? Após a migração, conecte-se ao destino com um cliente IMAP e verifique o INTERNALDATE diretamente:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Se a data devolvida não for a data em que o e-mail foi enviado, veja a mesma mensagem na origem: vai encontrar lá a mesma data errada. O log não mentiu, copiou o que lhe foi dado.

Este é um dos aspetos mais frustrantes da depuração de problemas de datas: um ficheiro de log limpo, duas datas idênticas, e ainda assim a data errada no Outlook, porque o erro já existia antes de o imapsync ser executado.

Migrações imapsync em grande escala: onde os problemas de datas se multiplicam

Uma migração de caixa de correio individual com imapsync é irritante quando as datas quebram. Mas MSPs e departamentos de TI que executam imapsync em centenas de caixas enfrentam uma escala de problema completamente diferente.

Considere um cenário típico de migração empresarial. Você está movendo 200 caixas de correio de um servidor Zimbra para o Microsoft 365. Escreve um script wrapper que percorre um CSV de usuários, chamando imapsync para cada um. A migração roda durante o fim de semana. Na segunda-feira de manhã, você tem 200 caixas com datas quebradas e cerca de 1,2 milhão de emails no total mostrando o timestamp da migração.

Dá para reexecutar o imapsync para corrigir isto? Tecnicamente sim, mas o imapsync vai pular mensagens que já existem no destino (ele é projetado para ser idempotente). Precisaria de --delete2 para remover mensagens do destino e retransferi-las, o que é arriscado em uma caixa de produção. E se as datas de origem eram o problema, uma segunda execução copia de novo as mesmas datas erradas.

Alguns administradores tentam uma abordagem híbrida: executar imapsync com --dry primeiro para testar, depois a migração real. Mas o --dry apenas simula a transferência: mostra as datas que o imapsync transmitiria, não se são as datas em que os e-mails foram enviados. Nada avisa que as datas de origem já estão erradas.

Correções caseiras e seus limites

Se você pesquisar em fóruns e listas de discussão (a lista imapsync-devel no SourceForge ainda está ativa no início de 2026), encontrará sugestões que vão do criativo ao perigoso.

Alguns sugerem usar um one-liner em Perl para modificar o INTERNALDATE no servidor de destino diretamente. Outros recomendam exportar todas as mensagens para formato mbox, manipular as datas e reimportar. Alguns escreveram scripts Python que usam imaplib para buscar, modificar e reinserir mensagens.

Todas essas abordagens compartilham os mesmos problemas fundamentais. Como lidar com mensagens assinadas com S/MIME sem quebrar a assinatura? E as estruturas MIME multipart com limites aninhados? Cabeçalhos não-ASCII codificados com RFC 2047? Mensagens criptografadas com PGP onde não se pode nem inspecionar o conteúdo? Um script que lida com 50 mensagens de teste em um ambiente de desenvolvimento vai engasgar nos casos extremos de uma caixa de produção de 30.000 mensagens.

E a maior pergunta que ninguém faz até ser tarde demais: como verificar que cada mensagem modificada ainda está intacta? Que os anexos não foram corrompidos, que o encadeamento ainda funciona, que a planilha de 85 MB que alguém enviou por email em 2020 sobreviveu à manipulação?

(Se você já tentou parsear cabeçalhos de email brutos em Perl, sabe que não é exatamente uma atividade relaxante de tarde.)

Como Redate.io corrige problemas de datas do imapsync

O cabeçalho Date: original está sempre intacto após uma migração imapsync. O imapsync transfere a mensagem bruta fielmente; a data errada está nos metadados que a cópia recebeu, não na mensagem. Esse cabeçalho original é o que torna a correção possível.

Redate.io se conecta diretamente à caixa de correio (Google Workspace, Microsoft 365 ou qualquer servidor IMAP), escaneia em busca de emails com anomalias de data e aplica correção direcionada de metadados através de um pipeline proprietário de análise de cadeia de cabeçalhos e reconstrução de datas. Não precisa de saber qual ferramenta fez a migração: encontra os e-mails cuja data exibida não corresponde à sua data original.

Cada email corrigido é verificado individualmente: integridade da mensagem, preservação de anexos, posicionamento em pastas, encadeamento, labels. Originais são mantidos em uma pasta de backup visível Redate.io - Originals até serem eliminados por si. Se algo parecer errado, reverter é um clique.

O escaneamento gratuito se conecta à caixa, identifica cada email com anomalia de data e informa a contagem exata e o custo. Sem cartão de crédito, sem software para instalar. Para os detalhes da sua plataforma:

Redate.io também funciona para migrações que aconteceram meses ou anos atrás. O cabeçalho Date: não expira, e a capacidade de corrigir também não.

Migrou com imapsync e preso com datas erradas? Execute um escaneamento gratuito para ver exatamente quantos emails estão afetados.

imapsync: datas não preservadas? Como corrigi-las