Fechas incorrectas tras migración IMAP a Exchange Online

El clásico escenario del lunes por la mañana

Acaba de finalizar la migración IMAP hacia Exchange Online. El batch terminó sin errores en el centro de administración de Exchange, los buzones están sincronizados, los usuarios pueden conectarse. Cierra el ordenador el viernes por la tarde con la satisfacción del trabajo hecho.

El lunes por la mañana llegan los tickets. "Todos mis correos tienen fecha del viernes." "Mi historial de bandeja de entrada es inútil." "Faltan correos antiguos." No falta nada, en realidad: los correos están ahí, pero Outlook los muestra todos con la fecha de migración en lugar de su fecha de envío original. Un email de 2019 aparece fechado el viernes pasado. Resultado: el buzón entero parece contener solo mensajes recientes.

Es uno de los problemas más frustrantes de las migraciones IMAP hacia Exchange Online, y Microsoft lo documenta de forma casi sistemáticamente insuficiente.

Por qué la migración via el EAC rompe las fechas

Cuando utiliza el centro de administración de Exchange (EAC) para configurar una migración IMAP desde un servidor local (Dovecot, Courier, Cyrus, UW-IMAP, lo que sea), Exchange Online se conecta a su servidor origen via IMAP, recupera los mensajes y los inyecta en los buzones de destino a través de su propio pipeline de transporte interno.

Ahí es donde se crea el problema.

Cada correo que pasa por el pipeline de transporte de Exchange recibe automáticamente una cabecera Received: con marca de tiempo. Es un comportamiento estándar de los servidores SMTP e IMAP desde hace décadas: cada servidor que toca un mensaje añade su firma temporal. El problema es que Outlook (y en particular Outlook para Windows, en las versiones recientes) usa la cabecera Received: más reciente como referencia de visualización cuando otros metadatos resultan ambiguos.

La cabecera Date: original (la que indica cuándo se envió realmente el correo, en el sentido de la RFC 2822) sigue presente en el mensaje. No ha sido eliminada. Pero queda "eclipsada" por esta nueva cabecera Received: que Exchange añade durante la inyección.

Al mismo tiempo, el INTERNALDATE de IMAP (el metadato que los servidores IMAP usan para fechar los mensajes internamente y que controla la ordenación en la mayoría de los clientes) se sitúa en la fecha de inyección, no en la fecha original del correo. Exchange Online no tiene ningún mecanismo nativo para preservar el INTERNALDATE del servidor origen durante una migración por batch via el EAC.

EAC vs. herramientas de terceros: una diferencia importante

Hay que distinguir dos situaciones. Con herramientas como BitTitan MigrationWiz o CloudM Migrate, el problema también existe, pero estas herramientas tienen a veces opciones de configuración (parcialmente documentadas, a menudo escondidas en los ajustes avanzados) que intentan preservar ciertos metadatos de fecha.

La migración nativa via el EAC, en cambio, no ofrece ninguna opción de ese tipo. Microsoft no expone ningún parámetro para controlar la preservación del INTERNALDATE en el pipeline de migración por batch. Es una caja negra: configura el batch, lo lanza, Exchange hace lo que quiere internamente. Y lo que hace, de forma sistemática, es fechar los mensajes con la fecha de su inyección.

(Por cierto, si alguna vez ha intentado leer las cabeceras brutas de un correo migrado via el EAC, sabe que la cabecera Received: añadida por Exchange es inconfundible: contiene referencias a servidores internos de Microsoft como *.protection.outlook.com o *.prod.exchangelabs.com, con una marca de tiempo que corresponde exactamente a la ventana de migración.)

Por qué recrear el batch no resuelve nada

La reacción instintiva de muchos administradores IT ante este problema es pensar: "Si elimino los buzones migrados y relanz o el batch desde cero, quizás esta vez las fechas sean correctas."

Es comprensible. Pero no funciona.

El problema no está en la configuración del batch. No está en un parámetro que se olvidó marcar. Está en la propia arquitectura del pipeline de transporte de Exchange, que es idéntica en cada migración. Relanzar el batch producirá exactamente el mismo resultado: las mismas cabeceras Received: con la nueva fecha de migración, y los mismos INTERNALDATE incorrectos. Habrá perdido tiempo y los usuarios habrán sido molestados una segunda vez sin motivo.

Algunos administradores también intentan modificar los parámetros de ordenación en Outlook ("ordenar por fecha de envío" en lugar de "fecha de recepción"). Ordenar por fecha de envío no es una solución. Es un parche. La cabecera Date: y el INTERNALDATE siguen siendo incorrectos para los clientes que no permiten ese ajuste, para OWA, para Outlook Mobile, y para cualquier aplicación de terceros que acceda al buzón via IMAP o EWS.

Lo que ocurre realmente en las cabeceras

Aquí un ejemplo simplificado de lo que contiene un correo después de la migración via el EAC. La cabecera original:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@antiguodominio.com
Subject: Informe Q1 2019

Tras la migración, el mensaje recibe al inicio de la cadena algo como:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook ve esta cabecera Received: en primer lugar (se añade al inicio del bloque de cabeceras), la interpreta como la fecha más reciente de procesamiento del mensaje, y la muestra como fecha de recepción. La cabecera Date: original de 2019 sigue ahí, intacta, unas líneas más abajo. Pero Outlook no la usa para la visualización en la lista de mensajes.

Para ser preciso: el comportamiento varía ligeramente según las versiones de Outlook. Las versiones posteriores a 2021 (y sobre todo el nuevo Outlook para Windows desplegado desde finales de 2023) son especialmente sensibles a este problema porque se apoyan más en los metadatos de Exchange Graph que en la cabecera Date: bruta. Lo que significa que migraciones que no causaban ningún problema visible con Outlook 2016 pueden plantear dificultades ahora con el nuevo Outlook.

Quién se ve realmente afectado

Los servidores IMAP origen más habituales en este tipo de migración son Dovecot (muy extendido en entornos Linux/cPanel) y Courier. Los dos exponen INTERNALDATE via IMAP que el EAC no preserva. Si migra desde un servidor Exchange on-premises hacia Exchange Online (migración híbrida o cutover), el comportamiento es diferente porque Microsoft usa un protocolo de transporte interno (MAPI/EWS) que preserva mejor los metadatos. El problema es la migración IMAP genérica via el EAC.

Los usuarios más afectados son los que tienen buzones con un historial largo (5 años o más) y un volumen elevado de mensajes. Un usuario con 300 correos en su buzón lo supera rápido. Un director comercial con 12.000 correos clasificados por fecha, de los que depende a diario para recuperar intercambios con clientes, queda paralizado.

Por qué un script casero es mala idea aquí

Algunos administradores IT que comprenden el problema técnico se ven tentados de escribir un script PowerShell o Python para corregir las cabeceras manualmente. El concepto básico puede parecer sencillo una vez identificado el mecanismo. Pero la realidad de una corrección en producción es otra historia.

Primero, los casos límite. Los correos firmados con S/MIME y los mensajes cifrados con PGP tienen una estructura que no tolera la modificación de cabeceras sin invalidar la firma. Los mensajes multipart/alternative con límites MIME mal formados (frecuentes en servidores Courier antiguos) pueden corromperse con un script que modifique el mensaje sin reconstruir correctamente la estructura. Las cabeceras no-ASCII codificadas según la RFC 2047 (nombres de remitentes con caracteres acentuados o japoneses, por ejemplo) son una fuente clásica de errores.

Luego, el volumen. Un script que funciona con 50 correos de prueba en entorno de desarrollo no gestiona los límites de tasa de la API de Exchange Online en producción. El error 429 Too Many Requests a las 2 de la mañana durante un batch de 8.000 mensajes, sin mecanismo de reanudación, es una noche en blanco y potencialmente mensajes duplicados o perdidos.

Y sobre todo: ¿cómo verificar que cada correo corregido está intacto? ¿Que ningún archivo adjunto fue truncado, que ningún hilo de conversación quedó roto, que las etiquetas y carpetas se preservaron? Sin un mecanismo de validación individual, solo se puede esperar que todo haya salido bien.

La corrección de fechas tras una migración es un problema que parece un script de 50 líneas pero que requiere miles para ser fiable en producción.

Lo que Redate.io hace de forma diferente

Redate.io se conecta a Exchange Online via las API de Microsoft 365 (Azure Active Directory, permisos de delegación a nivel de tenant) y analiza los buzones afectados para identificar los correos cuyos metadatos de fecha han sido corrompidos por la migración. Este análisis inicial es gratuito y ofrece una visión exacta del alcance del problema: número de mensajes afectados, buzones involucrados, rango de fechas corruptas.

El motor de corrección propio de Redate.io procesa después cada correo individualmente a través de un pipeline de análisis multietapa que incluye correspondencia de patrones sobre firmas de herramientas de migración conocidas (entre ellas el pipeline de transporte de Exchange Online), validación de conformidad RFC y verificación de la integridad estructural del mensaje antes y después de la corrección. Los correos firmados con S/MIME, las estructuras MIME complejas, las codificaciones no estándar: todos se gestionan mediante rutas de procesamiento específicas.

Cada mensaje corregido se verifica individualmente. Los originales se conservan en una carpeta de copia de seguridad visible durante 30 días. Si algo falla con un mensaje concreto, no se modifica: Redate.io señala la anomalía en lugar de arriesgarse a una corrupción.

La tarificación se basa en el volumen, con pago único por buzón. Sin suscripción, sin cargos recurrentes. Se corrige el problema una vez y listo.

Para las migraciones a Exchange Online específicamente, Redate.io admite la conexión via permisos de aplicación de Azure AD (sin necesidad de crear credenciales individuales por buzón), lo que hace que el tratamiento de grandes conjuntos de buzones sea mucho más fácil de gestionar para un administrador IT o un MSP.

Si gestiona varios clientes que han sufrido este tipo de migración, consulte también la guía completa sobre la corrección de fechas tras migración a Microsoft 365 para una visión de conjunto de los distintos escenarios cubiertos.

Los correos están ahí, y las fechas originales también. Lance un análisis gratuito en Redate.io para ver exactamente cuántos mensajes están afectados en sus buzones de Exchange Online, antes de decidir qué hacer.