Takeout mbox importado: e-mails com a data de hoje

Abriu o arquivo do Google Takeout, importou o ficheiro mbox no Thunderbird com o ImportExportTools NG (ou no Apple Mail) e depois arrastou as pastas para a nova conta IMAP. No cliente, os e-mails estavam organizados ano a ano. Na conta de destino, estão todos com a data de hoje. Este artigo explica o que acontece com um Takeout mbox importado, porque é que a data apresentada é a da cópia, como o confirmar em poucos minutos e como o corrigir no servidor.

Primeira coisa a saber: os seus e-mails estão intactos. A data de origem continua dentro da mensagem. Só que já não é aquela que a conta de destino põe em evidência.

O cenário típico de um Takeout mbox importado

Acabou de encerrar uma conta Gmail pessoal, aberta há quinze anos. Pediu a exportação em takeout.google.com, esperou pela mensagem da Google (dois dias para uma caixa grande) e transferiu quatro arquivos zip. Em cada um, um ficheiro .mbox por etiqueta. Importa-os no Thunderbird: a pasta local enche-se, a ordenação por data está impecável, 2009 lá em baixo, ontem lá em cima.

Faz então o que qualquer pessoa faria. Seleciona as pastas e arrasta-as para a conta IMAP de destino, seja um Microsoft 365, um alojamento ou um Google Workspace. A tranferência demora uma noite inteira. Na segunda-feira de manhã, abre o webmail.

O problema? Os 18 400 e-mails estão datados do fim de semana, numa janela de poucas horas. Um contrato de 2014 fica ao lado de uma newsletter da semana passada, e ninguém consegue encontrar nada por ordem cronológica.

O caso é muito parecido com o dos e-mails antigos que ficaram todos com a mesma data, com uma diferença de peso: aqui, nenhuma ferramenta de migração está em causa. Basta arrastar e largar.

Três datas num único e-mail

Para perceber, é preciso deixar de falar em "a data" de um e-mail. Uma mensagem importada a partir de um ficheiro mbox tem pelo menos três, e não servem para o mesmo.

O cabeçalho Date: a data do remetente

É o cabeçalho Date: definido pela RFC 2822 (retomada pela RFC 5322). O cliente do remetente escreve-o no momento do envio, por exemplo Date: Tue, 14 Mar 2017 09:12:45 +0100. Faz parte da mensagem, viaja com ela, e o Takeout conserva-o tal e qual. É ele que torna a correção possível, precisamente porque continua intacto.

A linha From do ficheiro mbox: uma data de fachada

Num ficheiro mbox, cada mensagem é precedida de uma linha que começa por From (com um espaço, sem dois pontos). Não é um cabeçalho: é um separador próprio do formato de ficheiro, que não faz parte da mensagem. Nenhuma ferramenta séria deveria basear-se nela para datar um e-mail.

O INTERNALDATE: a data de depósito no servidor

Terceira data, e a mais discreta: o INTERNALDATE, definido pela RFC 3501. É um atributo que o servidor IMAP guarda ao lado da mensagem (não dentro dela) e que corresponde ao momento em que a mensagem foi depositada na caixa de correio. O Outlook, os webmails e os telemóveis usam-no para apresentar e ordenar a data de receção. Para o detalhe do mecanismo, o artigo sobre o INTERNALDATE e as datas erradas em IMAP vai mais longe.

Uma precisão sobre os cabeçalhos Received:, muitas vezes acusados sem razão. As linhas Received de um e-mail do Gmail exportado contam o trajeto real da mensagem em 2017: trazem datas antigas e legítimas. Neste caso concreto, a data errada não vive, portanto, na mensagem, mas nos metadados que o servidor atribui à cópia.

Porque é que a conta de destino mostra a data da cópia

Quando um cliente deposita uma mensagem num servidor IMAP, usa o comando APPEND. Este comando aceita, como opção, uma data a atribuir à mensagem. Se o cliente a fornecer, o servidor guarda-a como INTERNALDATE. Caso contrário, o servidor aplica a regra prevista na RFC 3501: a data e a hora do momento. Ou seja, a data apresentada depende da forma como a ferramenta escreveu o e-mail. Uma ferramenta que não transmite a data de origem fica com a data da cópia.

Resultado: enquanto arrasta as pastas, cada mensagem recebe a data do seu próprio depósito. Uma pasta de 3000 e-mails copiada em 40 minutos cai numa janela de 40 minutos.

E a pasta local do Thunderbird, então? Parecia perfeita porque o Thunderbird ordena aí pelo cabeçalho Date, e não por uma data de servidor, já que uma pasta local não tem servidor. O comportamento do Apple Mail com as caixas importadas é comparável: está tudo bem enquanto as mensagens ficam no Mac. A verdade aparece quando outro programa, o Outlook por exemplo, lê a caixa IMAP.

Na verdade, não é bem exato dizer que todos os clientes se enganam sempre. Algumas versões transmitem a data, outras não, e o comportamento mudou ao longo das atualizações. Por isso, dois colegas que seguem o mesmo método podem obter resultados diferentes, o que torna o diagnóstico mais desconcertante do que parece.

Arrastar e largar não é uma migração. É uma cópia, e uma cópia traz a data em que foi feita.

Como reconhecer este caso em cinco minutos

Antes de procurar uma solução, confirme que está mesmo neste cenário e não noutro. Quatro verificações bastam.

• Compare os dois locais. A pasta local do Thunderbird (ou a caixa importada do Apple Mail) mostra datas certas, a conta IMAP mostra datas recentes para as mesmas mensagens.
• Veja o intervalo. Numa pasta da conta IMAP, as datas de receção cabem em poucas horas, ou até em poucos minutos, à volta do momento em que moveu as pastas.
• Abra a origem de uma mensagem. No Thunderbird, Ver e depois Origem da mensagem; no Outlook, as propriedades da mensagem mostram os cabeçalhos. Deve encontrar aí uma linha Date: antiga, enquanto o ecrã indica uma data recente.
• Verifique a ordem. As mensagens aparecem pela ordem em que o cliente as copiou, não pela ordem cronológica.

Eis o que dá a comparação numa mensagem real:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (dentro da mensagem, intacta)
Data apresentada pela conta IMAP: dia da cópia   (metadado do servidor)

Se estas duas linhas não contam a mesma história, é este o seu caso. E se as datas apresentadas estão erradas mas o Date: também está, é outro problema, mais raro, que não é tratado neste artigo.

(Aliás, se nunca leu os cabeçalhos em bruto de um e-mail, prepare um café: não é propriamente leitura de praia.)

Ordenar por data de envio: um penso rápido

O reflexo é passar a ordenação para a data de envio. No Outlook, funciona mais ou menos, desde que se repita em cada pasta e em cada dispositivo. Mas a pesquisa, as notificações, as regras baseadas na antiguidade e as vistas no telemóvel continuam a usar a data de receção. Quem procura "o e-mail de setembro passado" no telemóvel não vai ver nada de lógico.

Outra pista tentadora: recomeçar a cópia. Numa conta que já está a ser usada, isso produz sobretudo duplicados ao lado das mensagens já presentes, com as mesmas datas erradas ou com outras. Umas boas cem pastas depois, já não tem uma única caixa limpa.

A correção no servidor

A boa notícia é que a data de origem continua lá. A correção consiste em fazer com que a conta de destino a apresente, sem tocar no conteúdo das suas mensagens.

É isso que o Redate faz. O serviço liga-se à caixa de correio (Google Workspace por delegação ao nível do domínio, Microsoft 365, Outlook.com e Hotmail com a conta Microsoft de cada pessoa, ou IMAP direto com o endereço e a palavra-passe). O Redate não precisa de saber que ferramenta causou o problema: encontra os e-mails cuja data apresentada não corresponde à data original, quer a causa seja um arrastar e largar a partir de um Takeout mbox, quer seja outra coisa. A análise é gratuita e mostra-lhe a dimensão do estrago antes de qualquer decisão.

Quanto à correção propriamente dita, o Redate apoia-se num motor de correção proprietário, um pipeline de análise em várias etapas que examina a cadeia de cabeçalhos de cada mensagem e devolve a cada e-mail a sua data original. Cada e-mail corrigido é depois verificado individualmente, com validação da conformidade com as RFC e preservação da estrutura da mensagem. Os originais nunca são eliminados: ficam numa pasta visível da sua caixa de correio até ser o utilizador a eliminá-los.

Porque é arriscado tratar disto por conta própria

Compreender o problema é uma coisa. Corrigir 15 000 e-mails sem perder um único é outra bem diferente.

Um script que funciona em dez mensagens de teste não sobrevive a uma caixa de produção de 30 000 mensagens. Encontra e-mails S/MIME assinados, cuja mínima modificação parte a assinatura. Mensagens PGP cifradas. Estruturas multipart/alternative aninhadas, fronteiras MIME incoerentes, Content-Transfer-Encoding inesperados, cabeçalhos não ASCII codificados em RFC 2047, anexos de 40 MB. Depois vêm as quotas de API, o erro 429 Too Many Requests às 3 da manhã em pleno batch, os timeouts de rede que interrompem a operação na mensagem 11 874.

E depois? Como saber se cada mensagem está intacta? Sem mecanismo de rollback, um erro deixa mensagens duplicadas, anexos perdidos, conversas partidas, etiquetas desaparecidas. O Redate controla cada e-mail automaticamente e mantém o original à mão, precisamente para que nunca tenha de apostar nisso.

Um último conselho, gratuito: guarde os arquivos Takeout de origem enquanto a caixa não estiver validada. O ficheiro mbox continua a ser a cópia de referência, mesmo quando a conta de destino parece correta.

Guias relacionados com o seu cliente

Consoante o cliente que usou para a cópia, os guias detalhados seguintes descrevem o caso concreto: corrigir as datas de uma cópia IMAP feita no Thunderbird e o mesmo caso no Apple Mail.

O seu Takeout já foi copiado para a conta IMAP e as datas estão erradas? Inicie a análise gratuita do Redate para ver quantos e-mails estão afetados e depois corrija-os com um pagamento único, sem limite de tamanho da caixa de correio.