eM Client: fechas incorrectas tras importar PST o Thunderbird

El síntoma: todos sus correos tienen la misma fecha

Acaba de terminar un import de PST en eM Client, o ha migrado desde Thunderbird a su nueva bandeja de entrada. El proceso ha transcurrido sin errores aparentes. Pero al abrir el buzón, algo no encaja: cientos, a veces miles de correos muestran todos la misma fecha, la del día de la importación. Un correo de 2019 parece haber llegado ayer. Un contrato firmado hace tres años aparece como si acabara de entrar.

La reacción natural es culpar a eM Client. Algún parámetro mal configurado, una columna de ordenación incorrecta, un fallo de visualización... Se busca en las preferencias. Se alterna entre "Fecha de recepción" y "Fecha de envío". Nada cambia. O mejor dicho, algo cambia, pero no resuelve el problema de fondo.

Es porque el problema no está en eM Client. Está en los metadatos del servidor.

La causa real: el INTERNALDATE IMAP sobrescrito durante la importación

Para entender qué ocurre, hay que bajar un nivel y ver cómo el protocolo IMAP almacena los correos.

Cada mensaje en un servidor IMAP tiene dos tipos de fechas distintas:

• La cabecera Date: (definida por la RFC 2822): es la fecha que el remitente inscribió en el mensaje al enviarlo. Está encapsulada en el cuerpo del mensaje, en teoría intocable.
• El INTERNALDATE: un metadato del servidor, externo al mensaje, que representa la fecha en que el mensaje fue depositado en el buzón. Es este valor el que los clientes de correo usan de forma prioritaria para ordenar y mostrar los mensajes.

Al importar un PST o migrar desde Thunderbird, la herramienta de importación (ya sea el módulo nativo de eM Client, una herramienta de terceros, o una copia IMAP manual) deposita los mensajes en el servidor IMAP de destino. Y ahí, si la herramienta no preserva explícitamente el INTERNALDATE original en el momento del depósito, el servidor asigna automáticamente el INTERNALDATE actual, es decir, la fecha y hora de la importación.

Resultado: 8.000 correos archivados desde 2017, todos con sello de "recibidos" el día de la migración.

(Por cierto, si alguna vez ha intentado leer las cabeceras en bruto de un correo con Ver fuente en eM Client, habrá comprobado que la cabecera Date: original sigue ahí, intacta. Eso confirma que el problema viene del INTERNALDATE del servidor, no del mensaje en sí.)

Por qué cambiar la columna de ordenación no sirve de nada

La confusión viene de una distinción que poca gente conoce. En eM Client, como en Outlook o Thunderbird, existen generalmente dos columnas de fecha:

• "Fecha recibida" (o "Fecha de llegada"): basada en el INTERNALDATE del servidor.
• "Fecha" o "Fecha de envío": basada en la cabecera Date: del mensaje.

Muchos administradores descubren esto y creen haber encontrado la solución: cambiar a "Fecha de envío" y el problema desaparece visualmente en eM Client. Pero eso no es del todo exacto.

A ver: incluso ordenando por fecha de envío en eM Client, el problema persiste para todos los demás clientes y todas las demás interfaces que acceden al mismo buzón. Si los usuarios consultan sus correos desde OWA, desde Outlook en el escritorio, desde la aplicación de Gmail en el móvil, o desde cualquier cliente configurado en IMAP, verán las fechas de importación. El parámetro de ordenación de eM Client solo aplica a eM Client, y no actúa sobre los metadatos almacenados en el servidor.

Además, en Microsoft 365 y Google Workspace, la vista web nativa ordena por INTERNALDATE. Ese comportamiento no se puede cambiar desde el cliente.

Ordenar por fecha de envío no es una solución. Es un parche que oculta un problema real sin corregirlo.

El caso particular del import PST

La importación de archivos PST merece un párrafo aparte. Un archivo PST (Personal Storage Table) es un formato propietario de Microsoft que almacena correos, contactos y calendarios de forma local. Al importar un PST en eM Client, hay dos escenarios posibles:

• Import local hacia una cuenta IMAP: eM Client lee el PST y sube los mensajes al servidor IMAP de destino. Si la fecha de depósito no se preserva, el INTERNALDATE queda sobrescrito. Es el caso más frecuente, y es ahí donde las fechas aparecen corrompidas.
• Import hacia una carpeta local: los mensajes permanecen en la máquina, fuera del servidor. El INTERNALDATE no existe en este contexto, y eM Client puede mostrar la fecha Date: del mensaje. Menos problemas de fecha aquí, pero también menos utilidad práctica.

Para Thunderbird, la situación es similar. Si usa la función de importación integrada de eM Client (que lee los perfiles de Thunderbird), o si ha copiado carpetas mbox mediante IMAP, los mensajes se vuelven a depositar en el servidor sin ninguna garantía de preservación del INTERNALDATE. Y un servidor que recibe un mensaje sin instrucción de fecha explícita en el INTERNALDATE lo va a marcar sistemáticamente con la hora de recepción.

¿Qué plataformas se ven afectadas?

El problema es idéntico independientemente de la plataforma de destino, porque se trata de un comportamiento estándar del protocolo IMAP:

• Microsoft 365 / Exchange Online: el INTERNALDATE queda sobrescrito en cualquier importación que no use el comando IMAP APPEND con un parámetro de fecha explícito. Lo mismo ocurre en una migración desde Exchange on-premise.
• Google Workspace: mismo comportamiento. Los correos importados mediante eM Client o herramientas de terceros muestran la fecha de importación tanto en Gmail como en la consola de administración.
• Proveedores IMAP clásicos (OVH, Infomaniak, Ionos, o2switch, etc.): ningún tratamiento especial de la fecha al recibir un mensaje en APPEND. El INTERNALDATE será la fecha del depósito.

Un cliente se puso en contacto después de migrar algo más de un centenar de buzones desde Exchange 2013 a Microsoft 365, usando eM Client como herramienta de transición para algunas cuentas VIP. Resultado: los buzones migrados correctamente mediante MigrationWiz estaban bien, pero los que pasaron por eM Client tenían todos las fechas de importación. Los usuarios afectados, como era de esperar, no lo recibieron con agrado.

Por qué un script casero no resolverá esto fácilmente

Técnicamente, alguien que entiende el protocolo IMAP podría pensar en escribir un script para corregir los INTERNALDATE. La cabecera Date: original está ahí, intacta en cada mensaje. Bastaría con leerla y reconstruir los metadatos del servidor en consecuencia, ¿no?

En teoría, sí. En la práctica, es un campo minado.

Para empezar, los casos límite se acumulan rápidamente en un buzón de producción. Los mensajes firmados digitalmente con S/MIME son especialmente sensibles a cualquier manipulación de estructura. Los mensajes cifrados con PGP también. Los correos con archivos adjuntos voluminosos, límites MIME no estándar, o codificaciones Content-Transfer-Encoding inusuales pueden corromperse silenciosamente si el tratamiento no es riguroso. Un script que funciona sobre 50 correos de prueba no funcionará de forma fiable en un buzón de 20.000 mensajes con 6 años de historial.

Luego está la gestión de cuotas de API. En Microsoft 365, los límites de tasa sobre la API Graph o sobre EWS a las 3 de la madrugada en un lote de corrección de 8.000 mensajes se pueden gestionar. Pero no se gestionan solos. Un script no supervisado que encuentre un error 429 Too Many Requests en el mensaje número 3.741 puede continuar o no. Y no siempre sabrá qué mensajes se han procesado.

Y sobre todo: ¿cómo verificar que cada correo corregido está intacto tras el tratamiento? Un script casero generalmente no tiene mecanismo de verificación individual. Redate.io lo hace de forma automática, para cada mensaje.

Corregir las fechas en el origen con Redate.io

Redate.io ataca el problema donde se encuentra: en los metadatos del servidor, no en el cliente de correo.

El proceso comienza con una fase de análisis gratuita. Redate.io se conecta al buzón afectado (Microsoft 365 mediante Azure AD, Google Workspace mediante delegación de dominio, o IMAP directo para los proveedores clásicos) e identifica los correos cuyos metadatos de fecha son incoherentes con el contenido del mensaje. Se puede ver el resultado antes de pagar nada.

La corrección utiliza un motor propietario que analiza la cadena de cabeceras completa de cada mensaje, aplica una correspondencia de patrones sobre cientos de firmas de herramientas de importación conocidas (incluidos los comportamientos específicos de eM Client, Thunderbird y los imports de PST), y reconstruye los metadatos de fecha de forma precisa sin alterar el contenido del mensaje, sus archivos adjuntos ni su estructura MIME.

Cada correo corregido se verifica de forma individual. Los originales se conservan en una carpeta de copia de seguridad visible durante 30 días, algo que un script casero no hará nunca por defecto.

La tarificación es simple: pago único por buzón, basado en el volumen de correos a corregir. Sin suscripción, sin costes recurrentes. Consulte la página de inicio para ver los detalles.

Para la próxima migración: qué hay que verificar

Si está planificando una migración y quiere evitar este problema desde el principio, el punto de control es simple: ¿la herramienta que va a usar preserva explícitamente el INTERNALDATE al depositar los mensajes en el servidor de destino?

Para los imports de PST hacia Microsoft 365, las herramientas certificadas por Microsoft (como MigrationWiz en sus modos nativos, o la herramienta de migración de Exchange Online) suelen gestionar esta preservación. Para los imports manuales mediante eM Client o Thunderbird, rara vez es el caso. Revise la documentación de su herramienta antes de lanzar un import sobre buzones de producción.

Una buena checklist de migración de correo electrónico incluye siempre una verificación post-migración de las fechas sobre una muestra de buzones. Si quiere profundizar, la checklist de migración email cubre este punto en detalle.

Para los administradores que gestionan regularmente migraciones para sus clientes, el artículo sobre la corrección de fechas de correo en el contexto MSP y el dedicado a el funcionamiento del INTERNALDATE IMAP ofrecen una visión más completa del problema.

¿Las fechas de sus correos están corrompidas tras una importación con eM Client? Lance un análisis gratuito en Redate.io para medir el alcance del problema antes de decidir qué hacer.