Corrigir datas imapsync

A promessa do --syncinternaldates (e por que falha)

Voce executou o comando imapsync. Incluiu --syncinternaldates porque leu a documentacao e e cuidadoso assim. A migracao termina, o log diz que tudo foi transferido, zero erros. Entao voce abre a caixa no Outlook e cada email mostra a data de ontem.

Essa e uma das frustracoes 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 migracao. E tecnicamente, ele tenta. Mas "tenta" esta carregando muito peso nessa frase.

imapsync e uma ferramenta open-source em Perl escrita por Gilles Lamiral, e e genuinamente boa no que faz. Lida com transferencias de caixas de correio IMAP-para-IMAP com um nivel de confiabilidade que a maioria das ferramentas comerciais inveja. Mas a preservacao de datas nao esta inteiramente nas maos do imapsync, e e ai que as coisas complicam.

Como as datas IMAP realmente funcionam

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

O cabecalho 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 e modificado pelos servidores de email.
Cabecalhos Received: - cada servidor de email que trata a mensagem adiciona um com seu proprio timestamp. Formam uma cadeia do remetente ao destinatario. O cabecalho Received mais acima (mais recente) e o que alguns clientes de email usam para exibicao.
INTERNALDATE - um timestamp do lado do servidor IMAP que controla como as mensagens sao ordenadas na caixa. E definido quando a mensagem e armazenada pela primeira vez via IMAP APPEND.

Quando o imapsync migra uma mensagem, le 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.

O problema: o servidor de destino nao e obrigado a honrar essa data.

Por que os servidores de destino ignoram o INTERNALDATE

A especificacao IMAP (RFC 3501) diz que se uma data-hora for fornecida com o comando APPEND, o servidor DEVERIA usa-la. "DEVERIA" em linguagem RFC significa "faca isso a menos que tenha uma boa razao para nao fazer". Varias plataformas de email importantes decidiram que tem uma boa razao.

Microsoft 365 e o maior infrator. Quando uma mensagem chega via IMAP APPEND, o pipeline de transporte do Exchange carimba um novo cabecalho Received com a data atual e entao define o INTERNALDATE baseado nesse timestamp de entrega. Nao importa que data o imapsync solicitou. O servidor M365 sobrescreve.

Google Workspace (Gmail) se comporta de forma diferente, mas pode igualmente causar problemas. A implementacao IMAP do Gmail respeita o INTERNALDATE do APPEND na maioria dos casos, mas adiciona seu proprio cabecalho Received. Se o cliente de email que le a caixa prioriza cabecalhos Received sobre INTERNALDATE para exibicao (e o Outlook faz exatamente isso), as datas continuam aparecendo erradas.

Dovecot e Cyrus, os dois servidores IMAP open-source mais comuns, geralmente respeitam o INTERNALDATE do APPEND. Portanto, migracoes imapsync entre dois servidores Dovecot geralmente preservam as datas corretamente. Os problemas comecam quando o destino e uma plataforma hospedada com seu proprio processamento de transporte.

Erros comuns de linha de comando imapsync que quebram datas

Mesmo quando o servidor de destino cooperaria, administradores frequentemente tropecam nas opcoes de linha de comando do imapsync. Estes sao os erros mais frequentes:

Esquecer --syncinternaldates completamente

O flag nao e ativado por padrao. Se voce executa um imapsync --host1 source --host2 dest --user1 user --user2 user basico sem ele, o imapsync nao tenta preservar datas. O servidor de destino usa o timestamp atual para cada mensagem. E a causa mais comum, e a mais facil de passar despercebida porque o imapsync nao avisa.

Usar --syncinternaldates com --addheader

Alguns guias recomendam usar --addheader para injetar um cabecalho personalizado durante a migracao. Se voce esta adicionando cabecalhos, esta modificando a mensagem, o que pode fazer o servidor de destino trata-la como uma mensagem "nova" e carimba-la em conformidade. A interacao entre esses dois flags e mal documentada.

Confundir --minage e --maxage com preservacao de datas

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

Desvio de timestamp por negociacao SSL

Ao migrar sobre TLS com --ssl1 e --ssl2, a configuracao da conexao adiciona latencia. Em migracoes grandes (50.000+ mensagens), essa latencia acumula. Nao muda as datas em dias, mas pode fazer com que mensagens enviadas com minutos de diferenca cheguem com timestamps identicos no destino, perdendo sua ordenacao relativa.

Lendo logs do imapsync: o que a saida realmente diz

O imapsync produz logs detalhados, o que e otimo. Mas a saida do log pode ser enganosa quando se trata de datas.

Uma linha tipica de transferencia 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. Mas nao significa que o servidor de destino realmente armazenou essa data. O imapsync reporta o que solicitou, nao o que o servidor aceitou.

Quer verificar o que realmente aconteceu? Apos a migracao, conecte-se ao destino com um cliente IMAP e verifique o INTERNALDATE diretamente:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Se a data retornada for a data da migracao em vez de 2019-01-15, o servidor de destino ignorou a solicitacao do imapsync. O log mentiu para voce (bom, disse o que pediu, nao o que conseguiu).

Essa lacuna entre o que o imapsync reporta e o que realmente acontece e um dos aspectos mais frustrantes da depuracao de problemas de datas. Voce pode ficar olhando para um arquivo de log limpo por horas e nunca perceber que as datas estao erradas do outro lado.

Migracoes imapsync em grande escala: onde os problemas de datas se multiplicam

Uma migracao de caixa de correio individual com imapsync e 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 cenario tipico de migracao empresarial. Voce esta movendo 200 caixas de correio de um servidor Zimbra para o Microsoft 365. Escreve um script wrapper que percorre um CSV de usuarios, chamando imapsync para cada um. A migracao roda durante o fim de semana. Na segunda-feira de manha, voce tem 200 caixas com datas quebradas e cerca de 1,2 milhao de emails no total mostrando o timestamp da migracao.

Da para reexecutar o imapsync com --syncinternaldates se esqueceu na primeira vez? Tecnicamente sim, mas o imapsync vai pular mensagens que ja existem no destino (ele e projetado para ser idempotente). Precisaria de --delete2 para remover mensagens do destino e retransferi-las, o que e arriscado em uma caixa de producao. E mesmo assim, se o servidor de destino ignorar o INTERNALDATE, volta-se a estaca zero.

Alguns administradores tentam uma abordagem hibrida: executar imapsync com --dry primeiro para testar, depois a migracao real. Mas --dry nao testa o que o servidor de destino faz com o INTERNALDATE. Apenas simula a transferencia. O problema de datas e invisivel ate que as mensagens sejam realmente escritas no destino.

Correcoes caseiras e seus limites

Se voce pesquisar em foruns e listas de discussao (a lista imapsync-devel no SourceForge ainda esta ativa no inicio de 2026), encontrara sugestoes que vao 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? Cabecalhos nao-ASCII codificados com RFC 2047? Mensagens criptografadas com PGP onde nao se pode nem inspecionar o conteudo? Um script que lida com 50 mensagens de teste em um ambiente de desenvolvimento vai engasgar nos casos extremos de uma caixa de producao de 30.000 mensagens.

E a maior pergunta que ninguem faz ate ser tarde demais: como verificar que cada mensagem modificada ainda esta intacta? Que os anexos nao foram corrompidos, que o encadeamento ainda funciona, que a planilha de 85 MB que alguem enviou por email em 2020 sobreviveu a manipulacao?

(Se voce ja tentou parsear cabecalhos de email brutos em Perl, sabe que nao e exatamente uma atividade relaxante de tarde.)

Como Redate.io corrige problemas de datas do imapsync

O cabecalho Date: original esta sempre intacto apos uma migracao imapsync. O imapsync transfere a mensagem bruta fielmente; e o tratamento de metadados do servidor de destino que causa o problema de exibicao. Esse cabecalho original e o que torna a correcao possivel.

Redate.io se conecta diretamente a caixa de correio (Google Workspace, Microsoft 365 ou qualquer servidor IMAP), escaneia em busca de emails com anomalias de data e aplica correcao direcionada de metadados atraves de um pipeline proprietario de analise de cadeia de cabecalhos e reconstrucao de datas. A correcao lida com os padroes especificos que migracoes imapsync deixam para tras, incluindo as assinaturas caracteristicas de cabecalhos Received de servidores de destino que sobrescreveram o INTERNALDATE.

Cada email corrigido e verificado individualmente: integridade da mensagem, preservacao de anexos, posicionamento em pastas, encadeamento, labels. Originais sao mantidos em uma pasta de backup visivel Redate.io - Originals por 30 dias. Se algo parecer errado, reverter e um clique.

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

Redate.io tambem funciona para migracoes que aconteceram meses ou anos atras. O cabecalho Date: nao expira, e a capacidade de corrigir tambem nao.

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

imapsync: datas nao preservadas? Como corrigi-las