Migração cPanel: emails mal datados

A segunda-feira de manhã que dói

Você acabou de finalizar a migração de um hospedagem compartilhada cPanel para o Google Workspace ou Microsoft 365. A operação correu bem, as caixas estão acessíveis, os usuários conseguem entrar. Aí, por volta das 9h15, chega o primeiro chamado: "Meus emails antigos estão todos com a mesma data, a do fim de semana passado." Depois um segundo. Depois dez.

Não é um bug isolado. É a consequência direta de como as migrações a partir do cPanel tratam (ou melhor, não tratam) os metadados de data dos emails.

cPanel, Roundcube, Horde: um contexto IMAP peculiar

Uma hospedagem compartilhada cPanel é um servidor Linux rodando um servidor IMAP (geralmente Dovecot) com Roundcube ou Horde como interface webmail. Nada de extraordinário nisso. Mas esse contexto tem algumas particularidades que tornam as migrações para plataformas enterprise mais delicadas do que parecem.

Primeiro, as caixas cPanel costumam acumular emails ao longo de anos, às vezes uma década inteira. Um cliente que hospedava seu domínio em um servidor compartilhado desde 2013 pode ter arquivos muito profundos. Esse volume, combinado com a forma como a migração é feita, cria um terreno fértil para o problema de datas.

Além disso, as ferramentas usadas nessas migrações costumam ser a ferramenta nativa do cPanel (o "Migrations" do WHM), o imapsync rodado via linha de comando pelo provedor ou pelo prestador de TI, ou soluções de mercado como o GSMMO para migrar para o Google Workspace.

Por que as datas ficam corrompidas após uma migração cPanel

Para entender o problema, é preciso conhecer dois conceitos distintos: o cabeçalho Date: de um email e o INTERNALDATE do IMAP.

O cabeçalho Date: é gravado no corpo bruto da mensagem no momento do envio, conforme a RFC 2822. Ele indica quando o email foi redigido e enviado. Esse cabeçalho nunca muda, salvo manipulação intencional da mensagem.

O INTERNALDATE, por sua vez, é um metadado que o servidor IMAP associa a cada mensagem armazenada. Ele é separado do conteúdo da mensagem. Quando um email chega normalmente em um servidor, o INTERNALDATE é definido a partir dos cabeçalhos Received: da mensagem, ou pela data de entrega se a mensagem for submetida diretamente. É esse valor que o Outlook, o Thunderbird e a maioria dos clientes de email usam para ordenar as mensagens.

Durante uma migração IMAP, as mensagens são copiadas de um servidor para outro. O problema: a ferramenta de migração precisa criar cada mensagem no servidor de destino. E para muitas ferramentas, o INTERNALDATE da mensagem recém-criada corresponde à data da migração, não à data original da mensagem. Ao mesmo tempo, um cabeçalho Received: com o horário da migração é adicionado no topo da cadeia de cabeçalhos, o que perturba ainda mais os clientes de email que o consultam para calcular a data a exibir.

Resultado: um email de 2019 chega ao Google Workspace com um INTERNALDATE fixado no dia da migração e um cabeçalho Received: carimbado com a data de ontem. O Outlook o exibe na caixa de entrada como se tivesse acabado de chegar. Toda a cronologia do arquivo é destruída.

A ferramenta de migração WHM / cPanel

A ferramenta integrada ao WHM para migrar contas cPanel para outra plataforma gera esse problema de forma quase sistemática quando o destino é um servidor IMAP externo (Google Workspace, Microsoft 365). Ela copia o conteúdo dos Maildir para o novo servidor via IMAP APPEND sem preservar o INTERNALDATE original. Cada mensagem recebe então o carimbo de data/hora do momento da operação.

imapsync e as migrações manuais a partir do cPanel

O imapsync é uma ferramenta poderosa, mas seu comportamento padrão nem sempre preserva as datas. Sem os parâmetros corretos (e a versão adequada), ele pode perfeitamente copiar 40.000 mensagens atribuindo a todas elas a data de execução do script. (Aliás, se você já percorreu os logs do imapsync linha por linha para diagnosticar um problema de datas em uma caixa de 25.000 mensagens, sabe que é uma experiência que não se quer repetir.)

Para ser preciso, o imapsync tem opções para tentar preservar a data, mas essas opções interagem de forma diferente dependendo dos servidores de origem e destino, e sua eficácia não é garantida em todas as configurações cPanel / Dovecot.

GSMMO e as ferramentas de mercado

O Google Workspace Migration for Microsoft Outlook (GSMMO) foi criado para migrar a partir do Outlook, não de um servidor IMAP puro. Quando é usado para migrar a partir do cPanel (via uma conta IMAP configurada no Outlook), as datas sofrem o mesmo tratamento: o INTERNALDATE no Google Workspace é fixado na data da migração. O problema do GSMMO com as datas de email é documentado separadamente, dado o quanto é recorrente.

Quais clientes de email são afetados?

A corrupção das datas não se manifesta da mesma forma dependendo do cliente usado.

O Outlook é o cliente mais afetado. Ele usa o INTERNALDATE (ou o cabeçalho Received: de migração) como critério de ordenação principal para as pastas. Após uma migração cPanel mal gerenciada, uma caixa no Outlook pode exibir milhares de emails arquivados com a data do fim de semana da migração. A correção das datas do imapsync no Outlook é uma das mais solicitadas.

O Gmail (Google Workspace) geralmente exibe a data do cabeçalho Date: na lista de emails, mas a ordenação pode ser afetada pelo INTERNALDATE em alguns casos. Os usuários relatam comportamentos erráticos na busca e na ordenação por data.

O Apple Mail e o Thunderbird têm comportamentos mais variados, mas nenhum dos dois é imune ao problema, especialmente quando o cabeçalho Received: de migração aparece no topo da cadeia.

Boa notícia: a data original ainda está lá

É o detalhe técnico que muda tudo. O cabeçalho Date: original da mensagem está gravado no corpo bruto do email. A migração não o toca. Quando você abre um email afetado e consulta os cabeçalhos brutos (no Gmail: "Mostrar original", no Outlook: Arquivo > Propriedades), você vê o Date: original intacto, seguido de um ou mais cabeçalhos Received: cujo primeiro traz a data da migração.

Essa informação sempre está lá. Ela pode ser usada para corrigir os metadados. É exatamente o que o motor de correção do Redate.io faz.

Por que "corrigir isso sozinho" é mais arriscado do que parece

A tentação é grande. O problema parece simples: ler a data original, corrigir os metadados, passar para o próximo. Mas entre entender o mecanismo e corrigir 12.000 emails em produção sem perder nenhum, há uma diferença considerável.

Algumas realidades que os scripts caseiros geralmente não antecipam:

Emails assinados com S/MIME ou criptografados com PGP: qualquer modificação na estrutura da mensagem invalida a assinatura criptográfica. Um email que passava na verificação de assinatura antes da correção pode deixar de passar depois. Usuários em conformidade regulatória (escritórios de advocacia, setor financeiro, saúde) descobrem esse problema no pior momento.
Cabeçalhos não-ASCII e codificação RFC 2047: as caixas cPanel acumulam anos de emails vindos de clientes de email muito variados. Alguns cabeçalhos contêm caracteres codificados conforme a RFC 2047. Um script mal escrito que reconstrói os cabeçalhos pode corromper essas codificações de forma invisível.
Estruturas MIME aninhadas: um email com três anexos e um corpo HTML alternativo tem uma estrutura multipart complexa. O menor erro nas fronteiras MIME torna a mensagem ilegível, ou pior: os anexos desaparecem sem nenhuma mensagem de erro.
Cotas de API e rate limiting: o Google Workspace e o Microsoft 365 impõem limites rígidos no número de operações IMAP por minuto. Um script que não implementa corretamente o backoff exponencial dispara erros 429 às 3h da manhã, e você acorda com uma migração pela metade sem saber exatamente onde ela parou.
Rollback impossível: se algo der errado no meio do caminho, a qual estado você volta? Os originais ainda estão lá? Há duplicatas? O Redate.io mantém os originais em uma pasta de backup visível por 30 dias, justamente para nunca se encontrar nessa situação.

Um script que funciona em 50 emails de teste em ambiente de desenvolvimento não vai necessariamente funcionar em 18.000 mensagens de uma caixa de produção herdada de uma hospedagem cPanel desde 2011.

Como o Redate.io corrige as datas após migração cPanel

O Redate.io se conecta diretamente à caixa de destino (Google Workspace via delegação de domínio, Microsoft 365 via Azure AD, ou servidor IMAP direto) e começa por um scan gratuito para identificar os emails cujos metadados de data são inconsistentes com o cabeçalho Date: original.

O pipeline de análise em múltiplos estágios aplica correspondência de padrões nas assinaturas dos cabeçalhos Received: para identificar os introduzidos pelas ferramentas de migração (e distingui-los dos cabeçalhos legítimos). A correção direcionada dos metadados é feita sem alterar o conteúdo da mensagem: o texto, os anexos, os cabeçalhos originais, tudo permanece intacto. Cada email corrigido é verificado individualmente antes que a operação seja validada.

Para migrações a partir do cPanel especificamente, o motor reconhece as assinaturas típicas de migrações Dovecot-para-IMAP e de scripts imapsync, incluindo as variantes de configuração comuns em provedores de hospedagem compartilhada.

Guias específicos por destino

Dependendo da plataforma de destino da sua migração cPanel, os guias abaixo descrevem as etapas detalhadas:

Você migrou a partir do cPanel e seus usuários estão vendo datas incorretas? Execute um scan gratuito no Redate.io para identificar exatamente quantos emails foram afetados, sem nenhuma modificação antes da sua aprovação.

Emails com datas erradas após migração cPanel / Roundcube