Migración de iCloud a Office 365: fechas de emails incorrectas

Una migración que rompe sistemáticamente las fechas

Acaba de terminar la transferencia de su correo de iCloud a Office 365. Los emails están ahí, las carpetas en su sitio, todo parece perfecto. El lunes por la mañana llega la primera queja: "Todos mis emails antiguos muestran la fecha de hoy." Luego una segunda. Luego diez.

No es un fallo aislado. La migración desde iCloud Mail a Office 365 es uno de los escenarios más documentados de corrupción de fechas en correo electrónico, por razones técnicas muy concretas que tienen que ver con el comportamiento de Apple Mail, el protocolo IMAP, y la forma en que Microsoft 365 procesa los mensajes entrantes.

Por qué iCloud hacia Office 365 rompe las fechas

Para entender el problema, hay que distinguir tres cosas que mucha gente (incluidos administradores IT con experiencia) confunde: la cabecera Date:, el INTERNALDATE de IMAP, y la fecha de creación del archivo.

La cabecera Date: (RFC 2822)

Cada email contiene una cabecera Date: que indica cuándo se envió el mensaje. Esta cabecera está integrada en el cuerpo bruto del mensaje y, en teoría, nunca cambia. Es la fecha "original" en sentido estricto.

El INTERNALDATE de IMAP

El protocolo IMAP (definido en la RFC 3501) asocia a cada mensaje un metadato separado llamado INTERNALDATE. Es este valor el que la mayoría de los clientes de correo usan para ordenar y mostrar los mensajes en la bandeja de entrada, no la cabecera Date:. Outlook, en particular, depende en gran medida del INTERNALDATE tanto para el orden como para la visualización.

¿El problema? Cuando una herramienta de migración copia un email de un servidor IMAP a otro, debería preservar ese INTERNALDATE. En la práctica, eso no siempre ocurre.

El comportamiento particular de Apple Mail

Apple Mail, cuando sincroniza mensajes desde iCloud, utiliza a veces la fecha de creación del archivo en el servidor como referencia para el INTERNALDATE. No es exactamente un error: es una interpretación de la especificación IMAP que diverge de lo que hacen otros clientes. (Por cierto, si alguna vez ha intentado depurar un problema de INTERNALDATE leyendo las RFC de IMAP en bruto, sabe que la especificación deja un margen de interpretación bastante amplio en este punto.)

El resultado: cuando exporta o migra desde iCloud via Apple Mail, los INTERNALDATE de los mensajes pueden estar ya incorrectos antes incluso de llegar a Office 365.

Los tres métodos de migración desde iCloud y sus trampas

Migración IMAP directa

El método más habitual consiste en configurar iCloud como fuente IMAP y Office 365 como destino, y usar una herramienta de migración (imapsync, MigrationWiz, o una solución propia). La herramienta se conecta a ambos servidores y copia los mensajes.

El problema aquí es doble. Por un lado, los servidores IMAP de Apple tienen límites de velocidad que obligan a las herramientas a hacer pausas, creando ventanas de tiempo en que las conexiones se cierran y se reabren, lo que puede generar INTERNALDATE erróneos. Por otro, cada mensaje copiado hacia Exchange Online recibe por defecto una fecha de depósito correspondiente al momento de la migración, salvo que la herramienta pase explícitamente el INTERNALDATE original en el comando de inserción.

Algunas herramientas lo hacen correctamente. Otras, no de forma sistemática. Y en una bandeja de 40.000 mensajes, incluso una tasa de error del 2% son 800 emails con la fecha equivocada.

Para las migraciones via imapsync, véase también: corregir fechas de migración imapsync en Microsoft 365.

Exportación .mbox o .eml y posterior importación

Algunos usuarios exportan sus emails de iCloud a través de Apple Mail en formato .mbox y luego intentan importarlos en Outlook. Es un método artesanal que produce resultados variables.

El formato .mbox codifica los emails como una secuencia de mensajes de texto. Las fechas están presentes en las cabeceras Date: individuales, pero la línea de separación entre mensajes ("From ") incluye una fecha que algunos importadores pueden interpretar como fecha de creación. Outlook, al importar un .mbox convertido a .pst, usa a veces esa fecha de separación en lugar de la cabecera Date: del propio mensaje.

El arrastrar y soltar en Outlook

Este es el método que más daño causa. El usuario configura las dos cuentas en Outlook (iCloud y Office 365), luego arrastra y suelta sus mensajes de una carpeta a otra. Parece sencillo. Es una catástrofe para las fechas.

Cuando Outlook mueve un mensaje mediante arrastrar y soltar entre dos cuentas IMAP, en realidad genera un nuevo archivo .EML, lo inserta en la cuenta de destino, y elimina el original. Ese nuevo archivo hereda la fecha de creación del archivo en Windows, es decir, el momento exacto del arrastre. La cabecera Date: original sigue presente en el cuerpo del mensaje, pero el INTERNALDATE registrado en el servidor Exchange Online corresponde a la fecha de la operación. Outlook muestra entonces esa fecha de migración para todos los mensajes desplazados.

Para ser preciso: este comportamiento varía según la versión de Outlook. Desde la actualización de otoño de 2023, la situación mejoró ligeramente en algunos escenarios, pero el arrastrar y soltar entre cuentas sigue siendo una fuente documentada de corrupción de fechas.

Lo que Office 365 y Outlook terminan mostrando

Exchange Online almacena los emails con su INTERNALDATE. Outlook Desktop lee ese INTERNALDATE para mostrar la fecha en la columna "Recibido" y para ordenar la bandeja de entrada. Si el INTERNALDATE fue sobreescrito durante la migración, Outlook muestra la fecha de migración, sin más.

Outlook Web App (OWA) hace lo mismo. No existe ninguna "vista alternativa" que muestre la fecha original de la cabecera Date:. Lo que aparece en la columna de fecha es el INTERNALDATE.

La cabecera Date: original sigue ahí, intacta, legible si se muestran las cabeceras brutas de un mensaje. Pero ninguna vista normal la muestra. Esa es la frustración central de este problema: la información correcta existe, solo que es inaccesible sin una corrección técnica.

Lo que el soporte de Microsoft no resuelve

Si abre un ticket en el soporte de Microsoft por este problema, esto es probablemente lo que obtendrá: una confirmación de que las fechas mostradas corresponden a los INTERNALDATE almacenados, una sugerencia de revisar los parámetros de ordenación en Outlook, y eventualmente una derivación hacia la herramienta de migración que utilizó.

No es mala voluntad. Microsoft sencillamente no dispone de ninguna herramienta nativa para corregir de forma retroactiva los INTERNALDATE de miles de mensajes ya ingresados en Exchange Online. La corrección requiere acceder a cada mensaje individualmente, analizar sus cabeceras y reconstruir los metadatos de fecha, lo que está fuera del alcance del soporte estándar.

El soporte de iCloud, por su parte, considera que los mensajes fueron exportados correctamente y que el problema está en el destino. Ambos soportes se pasan la pelota, y el usuario se queda con 12.000 emails fechados el día de la migración.

El problema de escala

Entender por qué las fechas están rotas es una cosa. Corregirlas manualmente en una bandeja de producción es otra muy distinta.

Algunos administradores IT intentan escribir scripts para la corrección. La idea básica no es difícil de conceptualizar, pero la ejecución sobre volúmenes reales plantea problemas que los scripts caseros no gestionan bien:

• Los emails firmados con S/MIME o cifrados con PGP no pueden modificarse sin invalidar la firma criptográfica
• Los mensajes con estructuras multipart/alternative complejas (HTML + texto plano + adjuntos anidados) son frágiles de manipular
• Las cabeceras codificadas en non-ASCII (RFC 2047, especialmente para caracteres japoneses, árabes o cirílicos) pueden corromperse con herramientas que no gestionan correctamente esos encodings
• Las cuotas de la API de Microsoft Graph y los límites de velocidad de Exchange Online (error 429 Too Many Requests) detienen los scripts no diseñados para gestionar un backoff exponencial
• Un script que funciona bien con 500 emails de prueba se detiene a las 3 de la madrugada en el mensaje número 8.000 de una bandeja real, sin ningún mecanismo de reanudación

¿Y la pregunta que lo cambia todo? ¿Cómo verificar que cada email corregido está intacto después de la corrección? ¿Que el adjunto sigue ahí? ¿Que el hilo de conversación no está roto? Un script casero no suele hacer esa verificación.

Cómo Redate.io trata las migraciones de iCloud a Office 365

Redate.io se conecta directamente a Office 365 a través de los permisos de Microsoft 365 (Azure AD), sin necesidad de acceder a los servidores de iCloud. Los emails ya están en Exchange Online cuando Redate interviene.

El motor de corrección de Redate analiza la cadena de cabeceras de cada mensaje para identificar la fecha original, distinguiendo las cabeceras Received: añadidas durante la migración de los metadatos de fecha legítimos. Este análisis incluye una correspondencia de patrones sobre firmas de herramientas de migración conocidas, lo que permite identificar cabeceras parasitarias incluso cuando no son evidentes a simple vista.

Cada email corregido se verifica individualmente después del procesamiento. Los originales se conservan en una carpeta de copia de seguridad visible durante 30 días, algo que ningún script casero hace por defecto. El análisis inicial es gratuito y permite cuantificar exactamente cuántos emails están afectados antes de decidir si corregir.

Redate también es compatible con las migraciones desde Google Workspace a Office 365 y las correcciones tras migración desde cPanel. Véase también: corregir fechas tras migración a Microsoft 365 o fechas incorrectas tras migración IMAP a Exchange Online.

Primero analizar, luego corregir

El punto de partida recomendado para cualquier migración de iCloud a Office 365 que haya producido fechas incorrectas: ejecutar el análisis gratuito de Redate.io en las bandejas afectadas. El análisis identifica con precisión cuántos emails tienen un INTERNALDATE sospechoso y en qué carpetas se encuentran.

Tarda entre 12 y 45 minutos según el volumen, y ofrece una imagen clara del alcance del problema antes de cualquier intervención. Para los MSPs que gestionan varias bandejas a la vez después de una migración, este análisis por lotes evita corregir bandejas que no lo necesitan.

Si las fechas de sus emails son incorrectas tras migrar desde iCloud, empiece por el análisis gratuito en Redate.io para medir el alcance del problema en sus bandejas de Office 365.