Hospedagem compartilhada para M365: o problema oculto de datas

O problema que ninguém te avisou

Você acabou de concluir a migração da sua caixa de e-mails do OVH, Infomaniak, Ionos ou o2switch para o Microsoft 365. O assistente de migração do EAC (Exchange Admin Center) rodou a noite toda, está tudo verde, as caixas estão cheias. Segunda-feira de manhã, chega o primeiro ticket: "Todos os meus e-mails antigos têm a data de hoje." Depois o segundo. Depois dez.

Não é um bug do Microsoft 365. Também não é coincidência. É o resultado mecânico de uma migração IMAP, e no caso de um servidor de hospedagem compartilhada, o problema costuma ser duas vezes mais grave do que em uma migração convencional. Veja por quê.

Como o IMAP gerencia datas (e onde tudo desanda)

Cada e-mail armazenado em um servidor IMAP tem dois tipos distintos de datação. De um lado, o cabeçalho Date: (definido pela RFC 2822), presente no próprio corpo da mensagem, que indica quando ela foi enviada ou recebida. Do outro, o INTERNALDATE, um metadado no nível do servidor que registra em que data aquela mensagem foi depositada na caixa. É esse valor que clientes de e-mail como o Outlook usam por padrão para ordenar e exibir as mensagens.

(Aliás, se você já tentou ler os cabeçalhos brutos de um e-mail no EAC, sabe que não é exatamente uma leitura leve. Facilmente vinte a trinta linhas de cabeçalhos antes de chegar ao conteúdo.)

Quando uma ferramenta de migração IMAP transfere uma mensagem de uma caixa para outra, ela precisa recriar esse INTERNALDATE no destino. Algumas ferramentas fazem isso corretamente. Muitas não fazem, ou fazem com limitações. E os servidores de destino têm sua própria lógica: o servidor de destino mantém o que recebe: quando uma cópia traz consigo a sua data original, o Exchange Online mantém essa data. Por isso, quando as datas saem erradas, o problema está na ferramenta, não no Microsoft 365.

Resultado: cada e-mail migrado parece ter sido "recebido" no dia da migração. Não importa se ele é de 2019.

A corrupção em duas etapas: por que hospedagens compartilhadas pioram tudo

É aqui que a situação fica realmente problemática nas migrações a partir de hospedagens compartilhadas como OVH, Infomaniak, Gandi, Ionos ou o2switch.

Esses provedores geralmente usam servidores compartilhados com Postfix, Dovecot ou cPanel e configurações IMAP padrão. Muitas pequenas empresas acumularam anos de e-mails neles, às vezes desde 2010 ou 2012. Quando decidem migrar para o Microsoft 365, o processo normalmente acontece em duas fases.

Etapa 1: a primeira corrupção (antes mesmo do Microsoft 365)

Em muitos casos, os e-mails já sofreram uma migração anterior. A empresa trocou de provedor de hospedagem compartilhada uma ou duas vezes ao longo dos anos: do Gandi para o OVH em 2018, depois do OVH para o Infomaniak em 2022, por exemplo. Cada transferência IMAP pode ter reiniciado o INTERNALDATE original para o dia da transferência, sempre que a ferramenta não transmitiu a data original, e algumas ferramentas também deixam cabeçalhos de migração próprios, datados desse dia.

Quando os e-mails chegam ao Microsoft 365, eles já carregam cicatrizes. O cabeçalho Date: original está intacto (faz parte do corpo da mensagem, ninguém o altera), mas os metadados de data já foram perturbados uma primeira vez.

Etapa 2: a segunda corrupção na passagem para o Exchange Online

A ferramenta de migração IMAP do EAC, ou uma ferramenta de terceiros como o BitTitan MigrationWiz configurado em modo IMAP, ingere então esses e-mails já danificados. Se essa ferramenta também não transmitir a data original de cada e-mail, o Exchange Online arquiva o e-mail com a data da transferência, e é essa "data de receção" que o Outlook acaba por exibir.

Um e-mail enviado em março de 2017 pode carregar duas camadas de datas erradas: os cabeçalhos de migração deixados pela mudança de 2022 e a data de receção da migração para o Microsoft 365 em 2024. O Outlook exibe 2024. O usuário vê 2024. Isso está errado em dois níveis.

Para ser preciso: o Outlook determina a data de exibição a partir de uma combinação entre o INTERNALDATE registado pelo Exchange Online e os cabeçalhos presentes. Mas sempre que a ferramenta de migração não transmite as datas originais, a mudança para o Exchange Online acrescenta uma nova camada de erros por cima da anterior.

Ferramentas de migração e provedores: as combinações de risco

Algumas combinações aparecem com muita frequência nas migrações a partir de hospedagens compartilhadas:

• OVH / Infomaniak / Ionos + ferramenta IMAP do EAC: a ferramenta nativa da Microsoft é prática, mas é conhecida por não preservar corretamente as datas em migrações IMAP de grande volume.
• cPanel (o2switch, LWS, etc.) + BitTitan MigrationWiz em modo IMAP: o MigrationWiz em modo IMAP adiciona seus próprios cabeçalhos de migração. O resultado está documentado, entre outros casos, em nossa página corrigir datas do BitTitan no Microsoft 365.
• Gandi / Mailcow + imapsync: o imapsync é uma ferramenta poderosa, mas seu gerenciamento do INTERNALDATE depende da configuração. Sem a opção adequada, as datas não são preservadas. Veja também imapsync: datas não preservadas.
• Qualquer migração manual por arrastar e soltar no Outlook: se alguém copiou pastas inteiras fazendo drag-and-drop entre duas contas configuradas no Outlook, o INTERNALDATE de cada e-mail foi reescrito com a data da cópia. Sem exceção.

O denominador comum: todos esses métodos resultam em e-mails no Exchange Online cuja data exibida no Outlook não corresponde a nada real.

Por que "corrigir sozinho" é uma má ideia em grande escala

Entender o problema é uma coisa. Corrigir 8.000 e-mails distribuídos em 40 caixas do Exchange Online, com estruturas de pastas complexas, e-mails assinados com S/MIME, anexos volumosos e threads de conversa aninhados, é outra completamente diferente.

Um script PowerShell que parece funcionar em dez e-mails de teste pode falhar silenciosamente na mensagem número 4.237 por causa de uma fronteira MIME corrompida ou de um cabeçalho codificado em RFC 2047 (aquele formato =?UTF-8?B?...?= para caracteres não-ASCII em nomes de remetentes). Sem um mecanismo de verificação individual, você não vai saber. Vai ter apenas um e-mail perdido.

Os riscos concretos do DIY nesse tipo de migração:

• Mensagens duplicadas se a lógica de inserção falhar no meio do processo
• Anexos faltando se a estrutura multipart for mal reconstruída
• Threads de conversa quebradas no Outlook (as conversas dependem dos cabeçalhos References: e In-Reply-To:, que podem ser alterados)
• Erros 429 (Too Many Requests) da API do Microsoft Graph às 3h da manhã, interrompendo o processamento sem rollback
• Nenhuma forma simples de verificar que as 8.000 correções foram todas aplicadas corretamente

E no caso específico das migrações a partir de hospedagens compartilhadas, há uma dificuldade adicional: os e-mails carregam várias camadas de cabeçalhos Received: parasitas, não apenas uma. Um script simples que remove "o último Received:" não é suficiente. É preciso analisar a cadeia completa para identificar qual cabeçalho corresponde a qual migração e qual representa de fato a data de recebimento original.

O que o Redate.io faz de diferente

Cada pessoa inicia sessão com a sua própria conta Microsoft, e o Redate.io acede a essa caixa de correio com o acesso que essa autenticação concede. O scan inicial é gratuito: o Redate.io identifica todos os e-mails cuja data exibida não corresponde à data real, e fornece uma estimativa precisa por caixa.

A correção é feita por um motor proprietário que analisa a cadeia completa de cabeçalhos de cada mensagem, seja qual for a ferramenta de migração utilizada, e reconstrói os metadados de data corretamente, mesmo quando várias camadas de corrupção se sobrepõem. Cada e-mail corrigido é verificado individualmente. O Redate.io nunca elimina os originais: ficam numa pasta visível da própria caixa de correio, até serem eliminados manualmente.

Para migrações a partir de hospedagens compartilhadas, o pipeline de análise em múltiplas etapas do Redate.io trata explicitamente os cenários de dupla corrupção: ele não se limita a olhar o último cabeçalho Received:, mas percorre todo o histórico para encontrar a data de recebimento real. Veja também como corrigir datas após migração no Microsoft 365 de forma geral, e o guia específico sobre INTERNALDATE quebrado no IMAP para entender a mecânica por trás do problema.

Antes de migrar ou depois: dois momentos para agir

Duas situações, duas posturas.

Você ainda não migrou. A boa notícia: dá para limitar os danos. Algumas ferramentas de migração (MigrationWiz em modo Exchange, CloudM com as opções certas) preservam melhor as datas do que outras. Mas mesmo no melhor cenário, uma migração a partir de uma hospedagem compartilhada sem histórico limpo provavelmente vai deixar rastros. Planeje uma passagem pelo Redate.io após a migração, antes de entregar as caixas aos usuários.

Você já migrou e os tickets estão chegando. O Redate.io corrige caixas existentes no Microsoft 365, independentemente de quando a migração foi feita. O scan oferece uma imagem precisa do estado real de cada caixa antes de qualquer intervenção. Consulte também o checklist de migração de e-mail para evitar os mesmos problemas no futuro.

Você migrou do OVH, Infomaniak, Ionos ou o2switch para o Microsoft 365 e as datas estão erradas? Crie uma conta no Redate.io para escanear suas caixas gratuitamente e ver exatamente a extensão do problema antes de decidir qualquer coisa.