Migração iCloud para Office 365: datas de email erradas

Um cenário de migração que quebra as datas sistematicamente

Você acabou de terminar a transferência da sua caixa de entrada do iCloud para o Office 365. Os emails estão lá, as pastas estão no lugar, tudo parece perfeito. Segunda de manhã, a primeira reclamação chega: "Todos os meus emails antigos aparecem com a data de hoje." Depois uma segunda. Depois dez.

Não é um bug isolado. A migração do iCloud Mail para o Office 365 é um dos cenários mais documentados de corrupção de datas de email, por razões técnicas bem específicas que envolvem o comportamento do Apple Mail, o protocolo IMAP, e a forma como o Microsoft 365 trata as mensagens recebidas.

Por que a migração do iCloud para o Office 365 quebra as datas

Para entender o problema, é preciso distinguir três coisas que muita gente (inclusive admins de TI experientes) confunde: o cabeçalho Date:, o INTERNALDATE do IMAP, e a data de criação do arquivo.

O cabeçalho Date: (RFC 2822)

Todo email contém um cabeçalho Date: que indica quando a mensagem foi enviada. Esse cabeçalho está integrado ao corpo bruto da mensagem e nunca muda, em teoria. É a data "original" no sentido estrito do termo.

O INTERNALDATE do IMAP

O protocolo IMAP (definido na RFC 3501) associa a cada mensagem um metadado distinto chamado INTERNALDATE. É esse valor que a maioria dos clientes de email usa para ordenar e exibir as mensagens na caixa de entrada, não o cabeçalho Date:. O Outlook, em particular, depende muito do INTERNALDATE para exibição e ordenação.

O problema? Quando uma ferramenta de migração copia um email de um servidor IMAP para outro, o ideal seria preservar esse INTERNALDATE. Na prática, isso nem sempre acontece.

O comportamento particular do Apple Mail

O Apple Mail, ao sincronizar mensagens do iCloud, às vezes usa a data de criação do arquivo no servidor como referência para o INTERNALDATE. Não é um bug no sentido estrito, é uma interpretação da especificação IMAP que diverge do que outros clientes fazem. (Aliás, se você já tentou depurar um problema de INTERNALDATE lendo as RFC do IMAP em estado bruto, sabe que a especificação deixa uma margem de interpretação bem ampla nesse ponto.)

Resultado: quando você exporta ou migra do iCloud via Apple Mail, os INTERNALDATEs das mensagens podem já estar incorretos antes mesmo de chegar ao Office 365.

Os três métodos de migração do iCloud e suas armadilhas

Migração IMAP direta

O método mais comum consiste em configurar o iCloud como fonte IMAP e o Office 365 como destino, usando uma ferramenta de migração (imapsync, MigrationWiz, ou uma solução própria). A ferramenta se conecta aos dois servidores e copia as mensagens.

O problema aqui é duplo. Primeiro, os servidores IMAP da Apple têm limites de taxa que forçam as ferramentas a fazer pausas, criando janelas de tempo em que as conexões fecham e reabrem, o que pode gerar INTERNALDATEs espúrios. Segundo, cada mensagem copiada para o Exchange Online recebe por padrão uma data de depósito correspondente ao momento da migração, a menos que a ferramenta passe explicitamente o INTERNALDATE original no comando de inserção.

Algumas ferramentas fazem isso corretamente. Outras, não de forma consistente. E em uma caixa com 40.000 mensagens, mesmo uma taxa de erro de 2% representa 800 emails com a data errada.

Para migrações via imapsync, veja também: corrigir datas do imapsync no Microsoft 365.

Exportação .mbox ou .eml e depois importação

Alguns usuários exportam seus emails do iCloud via Apple Mail no formato .mbox e depois tentam importá-los no Outlook. É um método artesanal que produz resultados variáveis.

O formato .mbox codifica os emails como uma sequência de mensagens de texto. As datas estão presentes nos cabeçalhos Date: individuais, mas a linha de separação entre mensagens ("From ") inclui uma data que pode ser interpretada como data de criação por alguns importadores. O Outlook, ao importar um .mbox convertido em .pst, às vezes usa essa data de separação em vez do cabeçalho Date: da própria mensagem.

O arrastar e soltar via Outlook

Este é o método que causa mais estragos. O usuário configura as duas contas no Outlook (iCloud e Office 365) e arrasta as mensagens de uma pasta para outra. Parece simples. É uma catástrofe para as datas.

Quando o Outlook move uma mensagem por arrastar e soltar entre duas contas IMAP, ele gera na verdade um novo arquivo .EML, insere-o na conta de destino e exclui o original. Esse novo arquivo herda a data de criação do arquivo no Windows, ou seja, o momento exato do arrastar e soltar. O cabeçalho Date: original ainda está presente no corpo da mensagem, mas o INTERNALDATE registrado no servidor Exchange Online corresponde à data da operação. O Outlook exibe então essa data de migração para todas as mensagens movidas.

Para ser preciso, esse comportamento varia conforme a versão do Outlook. Desde a atualização do Outlook no outono de 2023, o comportamento melhorou ligeiramente em alguns cenários, mas o arrastar e soltar entre contas continua sendo uma fonte documentada de corrupção de datas.

O que o Office 365 e o Outlook exibem afinal

O Exchange Online armazena os emails com seu INTERNALDATE. O Outlook Desktop lê esse INTERNALDATE para exibir a data na coluna "Recebido" e ordenar a caixa de entrada. Se o INTERNALDATE foi sobrescrito durante a migração, o Outlook exibe a data de migração, ponto final.

O Outlook Web App (OWA) faz o mesmo. Não existe uma "visualização alternativa" que mostraria a data original do cabeçalho Date:. O que você vê na coluna de data é o INTERNALDATE.

O cabeçalho Date: original ainda está lá, intacto, legível se você exibir os cabeçalhos brutos de uma mensagem. Mas nenhuma exibição normal o mostra. Essa é a frustração central desse problema: a informação correta existe, só está inacessível sem correção técnica.

O que o suporte da Microsoft não resolve

Se você abrir um chamado no suporte da Microsoft para esse problema, provavelmente vai receber: uma confirmação de que as datas exibidas correspondem aos INTERNALDATEs armazenados, uma sugestão para verificar as configurações de ordenação no Outlook, e eventualmente um encaminhamento para a ferramenta de migração que você usou.

Não é má vontade. A Microsoft simplesmente não tem uma ferramenta nativa para corrigir retroativamente os INTERNALDATEs de milhares de mensagens já ingeridas no Exchange Online. A correção exige acessar as mensagens individualmente, analisar seus cabeçalhos e reconstruir os metadados de data, o que está fora do escopo do suporte padrão.

O suporte do iCloud, por sua vez, considera que as mensagens foram exportadas corretamente e que o problema está no destino. Os dois suportes jogam a responsabilidade um para o outro, e o usuário fica com 12.000 emails datados do dia da migração.

O problema de escala

Entender por que as datas estão quebradas é uma coisa. Corrigi-las manualmente em uma caixa de produção é outra.

Alguns admins de TI tentam criar scripts para a correção. A ideia básica não é difícil de conceitualizar, mas a execução em volumes reais traz problemas que scripts caseiros não tratam bem:

• Emails assinados com S/MIME ou criptografados com PGP não podem ser modificados sem invalidar a assinatura criptográfica
• Mensagens com estruturas multipart/alternative complexas (HTML + texto simples + anexos aninhados) são frágeis de manipular
• Cabeçalhos codificados em não-ASCII (RFC 2047, especialmente para caracteres japoneses, árabes ou cirílicos) podem ser corrompidos por ferramentas que não tratam corretamente esses encodings
• As cotas de API do Microsoft Graph e os limites de taxa do Exchange Online (erro 429 Too Many Requests) interrompem scripts não projetados para gerenciamento de backoff exponencial
• Um script que funciona bem em 500 emails de teste para no meio da madrugada na 8.000ª mensagem de uma caixa real, sem mecanismo de retomada

E a pergunta que não quer calar: como verificar que cada email corrigido está intacto após a correção? Que o anexo ainda está lá? Que o encadeamento da conversa não foi quebrado? Um script caseiro geralmente não faz essa verificação.

Como o Redate.io trata as migrações do iCloud para o Office 365

O Redate.io se conecta diretamente ao Office 365 via permissões do Microsoft 365 (Azure AD), sem necessitar de acesso aos servidores do iCloud. Os emails já estão no Exchange Online quando o Redate entra em ação.

O motor de correção do Redate analisa a cadeia de cabeçalhos de cada mensagem para identificar a data original, distinguindo os cabeçalhos Received: adicionados durante a migração dos metadados de data legítimos. Essa análise inclui correspondência de padrões em assinaturas de ferramentas de migração conhecidas, o que permite identificar cabeçalhos espúrios mesmo quando não são imediatamente evidentes.

Cada email corrigido é verificado individualmente após o processamento. Os originais são mantidos em uma pasta de backup visível por 30 dias, algo que nenhum script caseiro faz por padrão. O scan inicial é gratuito e permite quantificar exatamente o número de emails afetados antes de decidir pela correção.

O Redate também suporta migrações do Google Workspace para o Office 365 e correções após migração cPanel. Veja por exemplo: corrigir datas de email após migração Microsoft 365 ou datas erradas após migração IMAP para Exchange Online.

Escanear primeiro, corrigir depois

O ponto de partida recomendado para qualquer migração do iCloud para o Office 365 que produziu datas incorretas: executar o scan gratuito do Redate.io nas caixas afetadas. O scan identifica com precisão quantos emails têm um INTERNALDATE suspeito e em quais pastas estão.

Leva entre 12 e 45 minutos dependendo do volume, e dá uma imagem clara da extensão do problema antes de qualquer intervenção. Para MSPs que gerenciam várias caixas ao mesmo tempo após uma migração, esse scan em lote evita corrigir caixas que não precisam de correção.

Se as datas dos seus emails estão erradas após uma migração do iCloud, comece pelo scan gratuito no Redate.io para medir a extensão do problema nas suas caixas do Office 365.