CloudM Migrate: como corrigir datas de email erradas

O problema das datas do CloudM Migrate de que ninguém avisa

O CloudM Migrate terminou o trabalho. O painel indica 100% concluído, todos os utilizadores migrados, zero erros. O ticket do projeto é encerrado e passa-se ao cliente seguinte.

Depois, uma semana mais tarde, o diretor de TI telefona. "Porque é que todos os e-mails na minha caixa de entrada mostram 2 de abril?"

Não são alguns e-mails. São todos. Cinco anos de correspondência com clientes, documentos jurídicos, registos de RH, pedidos de compra de 2020, todos a mostrar a data em que o CloudM executou a migração. As mensagens estão lá, o conteúdo está intacto, os anexos estão bem. Mas as datas estão erradas em cada uma delas.

Isto não é um erro do CloudM. A própria documentação de suporte do CloudM reconhece isso abertamente. O problema está na intersecção entre a forma como as ferramentas de migração transferem as mensagens e a forma como os servidores de correio de destino tratam os metadados dos e-mails recebidos. Mas saber isso não ajuda o cliente cuja caixa de correio se tornou impossível de ordenar cronologicamente.

Como o CloudM transfere realmente as mensagens de e-mail

O CloudM Migrate liga-se às plataformas de origem e de destino através das respetivas APIs. Para o Google Workspace, isso significa uma conta de serviço com delegação em todo o domínio (configurada na Google Admin Console, em Security > API Controls). Para o Microsoft 365, utiliza o Exchange Web Services ou a API do Microsoft Graph, dependendo do percurso de migração.

Quando o CloudM lê uma mensagem na origem, obtém o conteúdo RFC 2822 completo, incluindo todos os cabeçalhos originais e o corpo da mensagem. O cabeçalho Date: original (aquele que o servidor de correio do remetente carimbou quando o e-mail foi enviado pela primeira vez) chega intacto. O mesmo sucede com todos os cabeçalhos Received: originais que traçam o percurso de entrega da mensagem.

O problema acontece quando a cópia é escrita. O destino mantém a data que lhe é dada: o Microsoft 365 e o Gmail mantêm a data original quando a cópia a transporta. Quando não a transporta, a cópia recebe como data o momento da inserção. E no Google Workspace, cada mensagem escrita através da API do Gmail recebe também um novo cabeçalho Received: datado do momento da inserção.

Eis o que os cabeçalhos de um desses e-mails ainda transportam depois de uma migração CloudM para o Microsoft 365:

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

O cabeçalho Date: original de 2019 ainda ali está, tal como a cadeia Received: original. Mas no Microsoft 365, a data que o Outlook mostra como data de receção é o registo próprio da caixa de correio sobre o momento em que cada e-mail chegou: se o CloudM não transmitiu a data original, esse registo diz 2 de abril de 2026.

A definição "Strip Received Headers" do CloudM

O CloudM oferece de facto uma definição para resolver isto. Nas Advanced Settings da plataforma de destino, em Message Options, existe um interruptor "Strip Received Headers". Quando ativado, o CloudM remove os cabeçalhos received antes de inserir a mensagem e substitui-os por um único cabeçalho correspondente ao cabeçalho Date: do e-mail.

Parece resolver tudo, não é? Não bem assim.

Primeiro, é preciso conhecer esta definição antes de executar a migração. A maioria dos administradores descobre o problema das datas depois de a migração estar concluída. Nessa altura, as mensagens já se encontram no destino com as datas erradas. Voltar a executar o CloudM com a definição ativada apenas cria duplicados, não corrige o que já lá está.

Segundo, esta definição tem uma limitação rígida quando o Google Workspace é o destino. A própria documentação da Google confirma-o: o Gmail reescreve sempre os cabeçalhos Received: nas mensagens inseridas através da API, carimbando-os com o momento da inserção. Trata-se de uma restrição ao nível da plataforma que o CloudM não consegue contornar. Mesmo com "Strip Received Headers" ativado, o Google Workspace adiciona o seu próprio cabeçalho Received: com a data da migração.

Para destinos Microsoft 365, esta definição importa menos: o Microsoft 365 mantém a data que lhe é dada, por isso o que decide a data apresentada é se o CloudM transmite ou não a data original de cada e-mail.

Que migrações CloudM quebram as datas (e quais não quebram)

Nem toda a migração CloudM produz datas erradas. O resultado depende da combinação origem-destino e do percurso de API específico que o CloudM utiliza:

• Google Workspace para Microsoft 365: As datas podem quebrar. O CloudM lê através da API do Gmail e escreve no Exchange; quando não transmite a data original, o e-mail recebe a data da cópia.
• Microsoft 365 para Google Workspace: As datas quebram. Mesmo com Strip Received Headers, a API da Google reescreve o cabeçalho Received com a data de inserção. A documentação de suporte do CloudM chama a isto uma "limitação estrita da plataforma".
• Google Workspace para Google Workspace: As datas quebram. Mudanças de domínio, consolidações de tenant, fusões por aquisição: cada mensagem escrita através da API do Gmail recebe um cabeçalho Received: datado da migração.
• Exchange on-premises para Microsoft 365: Tudo depende da data que o CloudM transmite, quer a cópia passe por IMAP quer por EWS.
• Origem IMAP (genérica) para qualquer destino: A mesma regra: quando o CloudM se liga a um servidor IMAP genérico como origem, a cópia mostra a data da migração sempre que a data original não é transmitida ao destino.

A parte complicada? O painel de migração do CloudM não sinaliza nada disto. A barra de progresso enche-se, a coluna de estado diz "Completed", as contagens de itens coincidem. Do ponto de vista do CloudM, a migração foi bem sucedida. E, tecnicamente, foi. As mensagens foram transferidas. As datas é que não sobreviveram à viagem.

CloudM Managed vs. Self-Service: o mesmo problema de datas

O CloudM oferece dois modelos de implementação. A versão SaaS (CloudM Migrate hospedado) é executada inteiramente na infraestrutura do CloudM. A versão autoalojada permite implementar servidores de migração primários e secundários na própria rede, no Google Cloud, no Azure ou na AWS.

Alguns MSP assumem que a opção autoalojada dá mais controlo sobre o tratamento das datas, já que os servidores de migração são geridos diretamente. Não dá. O que decide a data é o que o motor de migração transmite com cada mensagem, e esse motor é o mesmo onde quer que seja executado. Quer a exploração de migração seja executada na nuvem do CloudM ou numa VM Azure própria, o resultado para as datas é o mesmo.

O CloudM também oferece o "Serviced Migration" totalmente gerido, em que a equipa deles conduz o projeto do início ao fim. O mesmo resultado para as datas. A engenharia é idêntica, só mudam as mãos no teclado. Aliás, já pagou por um serviço premium e recebeu a mesma limitação do plano gratuito? É exatamente essa a sensação.

A complicação do cabeçalho Date inválido

Há outro comportamento específico do CloudM que agrava as coisas. Quando o CloudM encontra, na origem, um e-mail com um cabeçalho Date: que não cumpre a norma RFC 822 (fuso horário malformado, dia da semana ausente, formato não padrão), modifica o cabeçalho para garantir que a mensagem pode ser migrada.

Isto significa que alguns e-mails perdem até a sua referência de data original. O cabeçalho Date: modificado pode não corresponder de forma alguma à data real de envio. A documentação de suporte do CloudM menciona este comportamento conhecido em "Possible Changes to Migrated Items", mas não especifica o que a data modificada se torna.

Numa caixa de correio com 12.000 mensagens acumuladas ao longo de oito anos, pode haver centenas de e-mails com cabeçalhos Date ligeiramente fora do padrão (especialmente mensagens de servidores de correio mais antigos, sistemas automatizados ou remetentes internacionais com peculiaridades na formatação do fuso horário). Depois da modificação do CloudM, somada a uma cópia que não transporta a data original, estas mensagens acabam com datas que não têm qualquer semelhança com a realidade.

Por que as correções manuais não escalam depois do CloudM

Seria possível corrigir isto por conta própria? Tecnicamente, o cabeçalho Date: original ainda está incorporado na maioria das mensagens (exceto as que o CloudM modificou para conformidade com a RFC). Alguns administradores tentaram escrever scripts para corrigir as datas depois de uma migração CloudM.

Eis a realidade dessa abordagem. Trata-se de ligar potencialmente a milhares de caixas de correio, cada uma com milhares de mensagens. Para cada e-mail, é preciso analisar a cadeia completa de cabeçalhos, identificar quais os cabeçalhos Received: que o CloudM ou o servidor de destino adicionaram, tratar dos casos extremos (mensagens assinadas com S/MIME em que a modificação do cabeçalho quebra a assinatura, conteúdo cifrado com PGP, estruturas MIME multipart com limites aninhados, cabeçalhos não ASCII codificados em RFC 2047 de remetentes japoneses ou coreanos), e fazer tudo isto sem perder um único anexo ou quebrar o encadeamento dos e-mails.

Um script que funciona com 50 e-mails de teste numa caixa limpa não sobrevive ao contacto com um ambiente de produção de 40.000 mensagens ao longo de uma década. O que acontece quando surge um e-mail de 47 MB com seis anexos aninhados? E os limites de taxa das APIs (250 unidades de quota por utilizador por segundo na Google, limitação da Microsoft em cerca de 10.000 pedidos por 10 minutos)? Qual é o plano de recuperação quando algo corre mal na mensagem número 8.347?

E a verdadeira questão que a maioria dos administradores só coloca quando já é tarde: como verificar que cada mensagem corrigida está mesmo intacta?

Corrigir as datas de migração do CloudM com o Redate.io

O Redate.io liga-se diretamente às caixas de correio afetadas (Google Workspace, Microsoft 365 ou IMAP) e analisa os e-mails cuja data apresentada não corresponde à sua data original. A análise é gratuita e demora alguns minutos por caixa de correio, mostrando o número exato de mensagens afetadas antes de qualquer compromisso.

A correção utiliza um motor proprietário de análise da cadeia de cabeçalhos, e não precisa de saber qual foi a ferramenta que fez a migração. O Redate.io realiza uma correção direcionada dos metadados sem alterar o conteúdo da mensagem, preservando anexos, encadeamento, etiquetas, pastas e assinaturas digitais. Cada mensagem corrigida passa por uma verificação individual, confirmando a integridade da mensagem em relação ao original antes de o processo avançar.

Os e-mails originais são mantidos numa pasta de cópia de segurança visível, Redate.io - Originals, até que os elimine. Se for necessário reverter algo, os originais estão ali mesmo na caixa de correio, e não escondidos num arquivo externo.

Para os MSP que utilizaram o CloudM em ambientes de clientes, o Redate.io trata correções de várias caixas de correio em escala, com a mesma verificação por mensagem, quer se esteja a corrigir 1 caixa ou 500. O problema das datas que o CloudM deixou não tem de se tornar uma característica permanente do ambiente de correio do seu cliente.

Guias específicos por plataforma para migrações CloudM

O processo de correção adapta-se à plataforma de destino. O Redate.io trata automaticamente das especificidades de cada plataforma, mas para detalhes sobre a sua configuração:

• Corrigir as datas de migração do CloudM no Gmail
• Corrigir as datas de migração do CloudM no Outlook
• Corrigir as datas de migração do CloudM no Google Workspace
• Corrigir as datas de migração do CloudM no Microsoft 365

Para uma explicação mais profunda sobre por que razão isto acontece em todas as ferramentas de migração, não só no CloudM, consulte por que os e-mails mostram datas erradas depois de uma migração.

Migrou com o CloudM e ficou com datas erradas em todos os e-mails? Faça uma análise gratuita para ver exatamente quantas mensagens estão afetadas e quanto custa corrigi-las.