Takeout mbox importado: todos los correos con fecha de hoy

Ha abierto su archivo de Google Takeout, ha importado el fichero mbox en Thunderbird con ImportExportTools NG (o en Apple Mail) y después ha arrastrado las carpetas hasta su nueva cuenta IMAP. En el cliente, los correos estaban ordenados año por año. En la cuenta de destino, todos llevan la fecha de hoy. Este artículo explica qué ocurre con un Takeout mbox importado, por qué la fecha que se muestra es la de la copia, cómo confirmarlo en unos minutos y cómo corregirlo en el servidor.

Lo primero que debe saber: sus correos no están dañados. La fecha original sigue dentro del mensaje. Simplemente ya no es la que la cuenta de destino pone en primer plano.

El escenario típico de un Takeout mbox importado

Acaba de cerrar una cuenta personal de Gmail abierta hace quince años. Pidió la exportación en takeout.google.com, esperó el aviso de Google (dos días para un buzón grande) y descargó cuatro archivos zip. En cada uno, un fichero .mbox por etiqueta. Los importa en Thunderbird: la carpeta local se llena, la ordenación por fecha es impecable, 2009 abajo del todo, ayer arriba.

Entonces hace lo que haría cualquiera. Selecciona las carpetas y las arrastra a la cuenta IMAP de destino, sea un Microsoft 365, un proveedor de hosting o un Google Workspace. La transferencia dura toda una tarde-noche. El lunes por la mañana abre el webmail.

¿El problema? Los 18.400 correos llevan fecha del fin de semana, dentro de un intervalo de pocas horas. Un contrato de 2014 aparece junto a un boletín de la semana pasada, y nadie encuentra nada por orden cronológico.

El caso se parece mucho al de los correos antiguos que tienen todos la misma fecha, con una diferencia importante: aquí no interviene ninguna herramienta de migración. Basta con arrastrar y soltar.

Tres fechas en un solo correo

Para entenderlo hay que dejar de hablar de "la fecha" de un correo. Un mensaje importado desde un fichero mbox lleva al menos tres, y no sirven para lo mismo.

La cabecera Date: la del remitente

Es la cabecera Date: definida por la RFC 2822 (recogida en la RFC 5322). El cliente del remitente la escribe en el momento del envío, por ejemplo Date: Tue, 14 Mar 2017 09:12:45 +0100. Forma parte del mensaje, viaja con él y Takeout la conserva tal cual. Es la que hace posible la corrección, precisamente porque sigue intacta.

La línea From del fichero mbox: una fecha de fachada

En un fichero mbox, cada mensaje va precedido de una línea que empieza por From (con un espacio, sin dos puntos). No es una cabecera: es un separador propio del formato de fichero, que no forma parte del mensaje. Ninguna herramienta seria debería fiarse de ella para fechar un correo.

La INTERNALDATE: la fecha de depósito en el servidor

Tercera fecha, y la más discreta: la INTERNALDATE, definida por la RFC 3501. Es un atributo que el servidor IMAP almacena junto al mensaje (no dentro) y que corresponde al momento en que el mensaje se depositó en el buzón. Outlook, los webmails y los teléfonos la usan para mostrar y ordenar la fecha de recepción. Para el detalle del mecanismo, el artículo sobre la INTERNALDATE y las fechas incorrectas en IMAP profundiza más.

Una precisión sobre las cabeceras Received:, a las que aquí se culpa a menudo sin razón. Las líneas Received de un correo de Gmail exportado cuentan el trayecto real del mensaje en 2017: llevan fechas antiguas y legítimas. En este caso concreto, la fecha errónea no vive en el mensaje, sino en los metadatos que el servidor asigna a la copia.

Por qué la cuenta de destino muestra la fecha de la copia

Cuando un cliente deposita un mensaje en un servidor IMAP, usa el comando APPEND. Este comando acepta, de forma opcional, una fecha para el mensaje. Si el cliente la proporciona, el servidor la conserva como INTERNALDATE. Si no, el servidor aplica la regla prevista por la RFC 3501: la fecha y la hora del momento. Dicho de otro modo, la fecha que se muestra depende de cómo la herramienta escribió el correo. Una herramienta que no transmite la fecha original obtiene la fecha de la copia.

El resultado: mientras arrastra sus carpetas, cada mensaje toma la fecha de su propio depósito. Una carpeta de 3000 correos copiada en 40 minutos cae dentro de una ventana de 40 minutos.

¿Y la carpeta local de Thunderbird? Parecía perfecta porque Thunderbird ordena ahí por la cabecera Date y no por una fecha de servidor, ya que una carpeta local no tiene servidor. Apple Mail se comporta de forma parecida con los buzones importados: todo va bien mientras los mensajes se quedan en el Mac. La verdad sale a la luz cuando otro programa, Outlook por ejemplo, lee el buzón IMAP.

Aunque, para ser precisos, no es del todo exacto decir que todos los clientes fallan siempre. Algunas versiones transmiten la fecha y otras no, y el comportamiento ha cambiado con las actualizaciones. Por eso dos compañeros que siguen el mismo método pueden obtener resultados distintos, y el diagnóstico resulta más desconcertante de lo que parece.

Arrastrar y soltar no es una migración. Es una copia, y una copia lleva la fecha de su fabricación.

Cómo reconocer este caso en cinco minutos

Antes de buscar una solución, confirme que está en este escenario y no en otro. Bastan cuatro comprobaciones.

• Compare los dos sitios. La carpeta local de Thunderbird (o el buzón importado de Apple Mail) muestra fechas correctas, mientras que la cuenta IMAP muestra fechas recientes para los mismos mensajes.
• Mire el intervalo. En una carpeta de la cuenta IMAP, las fechas de recepción caben en unas pocas horas, o incluso minutos, alrededor del momento en que movió las carpetas.
• Abra el código fuente de un mensaje. En Thunderbird, Ver y después Código fuente del mensaje; en Outlook, las propiedades del mensaje muestran las cabeceras. Debe encontrar una línea Date: antigua aunque la pantalla indique una fecha reciente.
• Verifique el orden. Los mensajes aparecen en el orden en que el cliente los copió, no en orden cronológico.

Así se ve la comparación en un mensaje real:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (dentro del mensaje, intacta)
Fecha mostrada por la cuenta IMAP: día de la copia   (metadato del servidor)

Si esas dos líneas no cuentan la misma historia, es este caso. Y si las fechas mostradas son erróneas pero Date: también lo es, se trata de otro problema, más raro, que no corresponde a este artículo.

(Por cierto, si nunca ha leído las cabeceras en bruto de un correo, prepare un café: no es precisamente lectura de playa.)

Ordenar por fecha de envío: un parche

El primer reflejo es cambiar la ordenación a la fecha de envío. En Outlook funciona más o menos, a condición de repetirlo en cada carpeta y en cada dispositivo. Pero la búsqueda, las notificaciones, las reglas basadas en la antigüedad y las vistas en el móvil siguen usando la fecha de recepción. Un usuario que busca "el correo de septiembre pasado" en su teléfono no verá nada lógico.

Otra vía tentadora: repetir la copia. En una cuenta que ya se usa, eso produce sobre todo duplicados junto a los mensajes existentes, con las mismas fechas erróneas u otras. Un centenar de carpetas después, ya no le queda un solo buzón limpio.

La corrección en el servidor

La buena noticia es que la fecha original sigue ahí. La corrección consiste en lograr que la cuenta de destino la muestre, sin tocar el contenido de sus mensajes.

Eso es lo que hace Redate. El servicio se conecta al buzón (Google Workspace mediante delegación de dominio, Microsoft 365, Outlook.com y Hotmail con la cuenta de Microsoft de cada persona, o IMAP directo con la dirección y la contraseña). No necesita saber qué herramienta causó el problema: localiza los correos cuya fecha mostrada no coincide con su fecha original, ya sea por arrastrar y soltar desde un Takeout mbox o por cualquier otra causa. Redate escanea el buzón de forma gratuita y le muestra el alcance del problema antes de que tome ninguna decisión.

Para la corrección en sí, Redate se apoya en un motor de corrección propio, un pipeline de análisis en varias etapas que examina la cadena de cabeceras de cada mensaje y devuelve a cada correo su fecha original. Después se verifica cada correo corregido de forma individual, con validación de conformidad RFC y preservación de la estructura del mensaje. Los originales nunca se eliminan: permanecen en una carpeta visible de su buzón hasta que usted mismo los borre.

Por qué hacerlo por su cuenta es arriesgado

Entender el problema es una cosa. Corregir 15.000 correos sin perder ni uno solo es otra muy distinta.

Un script que funciona con diez mensajes de prueba no sobrevive a un buzón de producción de 30.000 mensajes. Se topa con correos S/MIME firmados, en los que la mínima modificación rompe la firma. Con mensajes PGP cifrados. Con estructuras multipart/alternative anidadas, límites MIME incoherentes, Content-Transfer-Encoding inesperados, cabeceras no ASCII codificadas según la RFC 2047, adjuntos de 40 MB. Y luego llegan las cuotas de API, el error 429 Too Many Requests a las 3 de la madrugada en pleno lote, los tiempos de espera de red que cortan la operación en el mensaje 11.874.

¿Y después? ¿Cómo saber que cada mensaje está intacto? Sin mecanismo de reversión, un error deja mensajes duplicados, adjuntos perdidos, hilos de conversación deshechos, etiquetas desaparecidas. Redate controla cada correo de forma automática y mantiene el original a mano, precisamente para que usted nunca tenga que jugársela.

Un último consejo, gratuito: conserve sus archivos Takeout originales mientras el buzón no esté validado. El fichero mbox sigue siendo la copia de referencia, incluso cuando la cuenta de destino parece correcta.

Guías relacionadas con su cliente

Según el cliente que haya usado para la copia, las siguientes guías detalladas describen el caso concreto: corregir las fechas de una copia IMAP hecha en Thunderbird y el mismo caso en Apple Mail.

¿Su Takeout ya está copiado en la cuenta IMAP y las fechas son incorrectas? Lance el escaneo gratuito de Redate para ver cuántos correos están afectados y luego corríjalos con un pago único, sin límite de tamaño de buzón.