Por que o imapsync e popular (e por que as datas quebram mesmo assim)
O imapsync e a ferramenta de migracao de email de referencia para administradores de sistemas Linux, provedores de hospedagem e todos que preferem solucoes open source. Criado por Gilles Lamiral, o imapsync e mantido ativamente desde 2001 e ja foi usado para milhoes de migracoes de caixas em todo o mundo. Ele suporta praticamente todos os servidores IMAP: Dovecot, Courier, Cyrus, Zimbra, Exchange, Gmail e dezenas de outros.
O imapsync tem reputacao de ser completo e configuravel. Os administradores apreciam seu controle granular sobre as pastas a migrar, a gestao de duplicatas e o mapeamento de nomes de pastas entre diferentes servidores IMAP. Mas apesar de todo esse controle, um problema persiste: as datas dos emails frequentemente nao sao preservadas apos uma migracao imapsync. Os usuarios abrem sua caixa apos a migracao e constatam que cada email exibe a data da migracao. E exasperante, especialmente porque o imapsync deveria lidar com as datas corretamente.
Como o imapsync lida com o INTERNALDATE
A tentativa de preservacao do INTERNALDATE
O imapsync efetivamente tenta preservar o INTERNALDATE de cada email durante a migracao. O INTERNALDATE e o timestamp que o servidor IMAP armazena como metadado para cada mensagem, separado dos cabecalhos do email. Quando o imapsync copia uma mensagem da origem para o destino, ele le o INTERNALDATE do servidor de origem e o transmite ao servidor de destino no comando IMAP APPEND.
Em teoria, isso deveria preservar a data original. Na pratica, o resultado depende do comportamento do servidor de destino e de como os clientes de email interpretam os diferentes campos relacionados a datas na mensagem.
O problema do cabecalho "Received"
Mesmo quando o imapsync consegue preservar o INTERNALDATE, o servidor de email de destino adiciona um novo cabecalho "Received" a cada mensagem durante a operacao APPEND. Esse cabecalho "Received" contem o timestamp atual - a data da migracao. Clientes de email como Outlook, Apple Mail e Thunderbird determinam a data de "recebimento" exibida lendo o cabecalho "Received" mais alto, nao o INTERNALDATE. Entao apesar do esforco do imapsync para preservar o INTERNALDATE, a data visivel na maioria dos clientes esta errada mesmo assim.
E essa desconexao fundamental que causa a confusao. O imapsync preserva um valor de data (INTERNALDATE), mas os clientes de email exibem outro (o timestamp do cabecalho "Received"). Para um mergulho tecnico nesse mecanismo, veja por que os emails mostram a data errada apos migracao IMAP.
O equivoco da FAQ do imapsync
A documentacao e a FAQ do imapsync abordam o problema de data mas o apresentam como uma limitacao inerente. A FAQ sugere que "as datas podem nao ser preservadas" durante a migracao IMAP e implica que e simplesmente assim que o protocolo IMAP funciona. Embora seja verdade que o protocolo IMAP exige que os servidores adicionem cabecalhos "Received" na insercao de mensagens, a FAQ cria a impressao de que o problema e permanente e irreparavel.
Isso nao e exato. Os cabecalhos "Received" adicionados durante a migracao podem ser identificados e tratados posteriormente, restaurando a exibicao da data original nos clientes de email. O cabecalho "Date" original (que registra quando o email foi enviado) e sempre preservado pelo imapsync e serve como referencia para a data correta.
Identificar o cabecalho de migracao imapsync
Como o cabecalho se parece
O imapsync em si nao adiciona um cabecalho "Received" - e o servidor IMAP de destino que o faz. O cabecalho adicionado durante uma migracao imapsync geralmente se parece com um cabecalho de insercao IMAP padrao do servidor de destino. Por exemplo, ao migrar para um servidor Dovecot, o cabecalho pode ser algo como:
Received: from localhost by mail.example.com;
Wed, 15 Jan 2025 09:14:22 +0100O identificador-chave e que esse cabecalho "Received" e o mais alto na cadeia, seu timestamp corresponde a data de execucao da migracao imapsync, e geralmente referencia "localhost" ou o hostname do servidor de destino em vez de um servidor de email externo.
Comparar as datas
Para confirmar o problema, compare o timestamp do cabecalho "Received" mais alto com o cabecalho "Date" do email. Se o cabecalho "Received" indica janeiro de 2025 mas o cabecalho "Date" indica marco de 2020, o cabecalho "Received" de migracao e a causa da exibicao errada da data. Essa comparacao pode ser feita visualizando o codigo-fonte bruto da mensagem em qualquer cliente de email.
Por que as opcoes comuns do imapsync nao resolvem o problema
O flag --syncinternaldates
O imapsync oferece o flag --syncinternaldates, que define o INTERNALDATE no servidor de destino para corresponder ao cabecalho "Date" do email. Isso e util quando o INTERNALDATE do servidor de origem ja esta errado, mas nao impede o servidor de destino de adicionar um cabecalho "Received". A data visivel no Outlook e outros clientes permanece a data de migracao independentemente do valor do INTERNALDATE.
A opcao --addheader
O imapsync pode adicionar cabecalhos personalizados as mensagens durante a migracao, mas nao pode impedir o servidor de destino de adicionar seu proprio cabecalho "Received". O protocolo IMAP exige que os servidores registrem o timestamp de insercao, e nenhuma opcao do imapsync pode anular esse comportamento no nivel do servidor.
Scripts pos-migracao
Alguns administradores escrevem scripts pos-migracao personalizados para tratar os cabecalhos "Received" indesejados. Parece razoavel, especialmente para o tipo de pessoa que escolheu o imapsync em primeiro lugar (alguem confortavel com a linha de comando). Mas a realidade e muito mais complexa do que um buscar-substituir em texto de cabecalho. O que acontece quando o script encontra um email assinado com S/MIME? Ou uma mensagem multipart com fronteiras MIME aninhadas e anexos codificados em base64? Ou um cabecalho com caracteres non-ASCII codificados em RFC 2047? Um unico byte mal posicionado em uma fronteira MIME pode corromper silenciosamente uma mensagem inteira, destruindo os anexos ou tornando o email ilegivel. E como confirmar que 10.000 emails corrigidos estao todos intactos? Para milhares de emails em multiplas caixas, o scripting DIY representa um risco substancial.
Corrigir as datas imapsync com o Redate.io
Como o Redate.io lida com migracoes imapsync
O motor de correcao proprietario do Redate.io e projetado especificamente para essa categoria de problema. Apos conectar a caixa, o Redate.io analisa cada email e passa cada mensagem por um pipeline de analise multistagio. Para migracoes imapsync, o Redate.io detecta o cabecalho "Received" inserido pelo servidor aplicando correspondencia de assinaturas em centenas de perfis de migracao conhecidos, analisando a cadeia completa de cabecalhos e cruzando os timestamps com o cabecalho "Date" original.
Nao e uma simples edicao de cabecalho. O motor de correcao lida com validacao de conformidade RFC, preservacao da estrutura da mensagem (incluindo estruturas multipart/alternative, anexos em linha e variacoes de Content-Transfer-Encoding) e deteccao de assinaturas digitais. Emails com assinaturas S/MIME ou PGP sao automaticamente identificados e tratados de forma apropriada para preservar a integridade das assinaturas.
O que voce obtem apos a correcao
Cada email corrigido exibe sua data de recebimento original em todos os clientes de email. A ordem cronologica e restaurada. Cada correcao passa por uma verificacao de integridade antes de ser finalizada. A mensagem original e movida para uma pasta "Redate.io - Originals" e mantida por 30 dias como rede de seguranca.
Compatibilidade com todos os servidores de destino
Como o imapsync e usado para migrar para praticamente qualquer servidor IMAP, o Redate.io suporta a mesma amplitude de plataformas de destino. Quer a migracao imapsync tenha visado Dovecot, Courier, Cyrus, Zimbra, Google Workspace, Microsoft 365 ou qualquer outro servidor IMAP, o Redate.io se conecta e corrige as datas.
Como corrigir as datas apos uma migracao imapsync
Conectar a caixa
Faca login no Redate.io e adicione a caixa. Para Google Workspace ou Microsoft 365, use a opcao de delegacao admin. Para outros servidores IMAP (comuns em cenarios imapsync), insira o endereco do servidor, o nome de usuario e a senha. O Redate.io se conecta via IMAP padrao.
Analise gratuita
Inicie a analise gratuita para identificar os emails afetados. O relatorio mostra o numero total de emails, quantos tem a data errada e qual data de migracao foi detectada. Essa analise nao custa nada e da uma imagem clara antes de qualquer compromisso.
Corrigir e verificar
Selecione um plano com base no numero de emails afetados e inicie a correcao. O progresso e visivel em tempo real. Apos a conclusao, verifique os resultados consultando as datas dos emails no seu cliente. As datas devem ter voltado ao lugar certo.
Guias de correcao imapsync por plataforma
Perguntas frequentes
Devo usar --syncinternaldates do imapsync antes de usar o Redate.io?
Nao e necessario. O Redate.io define o INTERNALDATE correto durante o processo de correcao, independentemente do valor atual. Quer o imapsync tenha preservado o INTERNALDATE original ou nao, o Redate.io deriva o valor correto a partir do cabecalho "Date" original.
Posso corrigir as datas no servidor de origem antes de migrar com imapsync?
Se o servidor de origem ja tem datas erradas (resultado de uma migracao anterior), o Redate.io pode corrigi-las antes ou apos a migracao imapsync. Mas corrigir as datas no servidor de destino apos a migracao e a abordagem mais comum e pratica.
Quantos emails o Redate.io pode processar?
O Redate.io lida com caixas de qualquer tamanho. Planos estao disponiveis para ate 100.000 emails por caixa. Para organizacoes com muitas caixas, o Redate.io oferece precos por volume.
A migracao imapsync quebrou as datas? Inicie uma analise gratuita para ver quantos emails estao afetados e corrija-os com o Redate.io.