Corregir fechas de migración imapsync en Microsoft 365

Migrar a Microsoft 365 con imapsync suena razonable. La herramienta es gratuita, permite automatización mediante scripts y maneja bien las transferencias IMAP a IMAP en la mayoría de los escenarios. Pero en Microsoft 365, un detalle decide la fecha con la que termina cada correo electrónico.

Exchange Online conserva la fecha que se le entrega: cuando imapsync escribe un mensaje por IMAP, transmite con él la fecha interna de cada correo (--syncinternaldates está activado por defecto), y la copia conserva esa fecha. Ahora bien, lo que imapsync transmite es la fecha que el servidor de ORIGEN guarda para cada mensaje, no la fecha en que el correo fue enviado. En un buzón sano, ambas coinciden. En un buzón que ya fue migrado antes o restaurado desde una copia de seguridad, el origen puede conservar la fecha de esa operación anterior, e imapsync la copia tal cual.

Esto no es un error de Microsoft 365 ni de imapsync. Cada copia conserva fielmente la fecha que se le transmitió. Cuando esa fecha ya estaba equivocada en el origen, ya sea que se migren 500 correos o 500.000, cada correo afectado muestra la fecha de esa operación anterior en lugar de la fecha en que fue recibido.

Imagine explicar a su director de TI que la migración del fin de semana acaba de aplanar 6 años de historial de correo en una sola fecha. Esa es la realidad que enfrentan los administradores después de una migración con imapsync a Microsoft 365. Y a diferencia de Google Workspace (donde la interfaz web de Gmail puede enmascarar el problema), Microsoft 365 muestra la fecha incorrecta en todas partes - Outlook de escritorio, OWA, Outlook móvil, Microsoft Search. No hay escapatoria del lado del cliente.

En Microsoft 365, el daño es total y visible. Cada cliente - Outlook para Windows, Outlook para Mac, OWA, Outlook móvil en iOS y Android - muestra la marca temporal de migración. Los usuarios no pueden ordenar por fecha, no pueden encontrar correos cronológicamente, no pueden confiar en los resultados de búsqueda con filtro por fecha. Un buzón con 80.000 correos que muestran "12 de noviembre de 2024" resulta inutilizable para el trabajo diario.

Las implicaciones de cumplimiento son peores. Exchange Online Protection, Microsoft Purview y las políticas de retención indexan la marca temporal de entrega corrupta. Una política de retención configurada para eliminar correos de más de 7 años opera con la fecha equivocada - lo que significa que correos de 2018 que deberían estar cerca de su eliminación ahora parecen ser de 2024. Las organizaciones sujetas al RGPD, HIPAA o regulaciones de la SEC enfrentan una exposición regulatoria real cuando la retención de correos no es fiable. Y si llega una solicitud de retención legal para "todos los correos del tercer trimestre de 2023," las fechas corruptas hacen que Purview no devuelva nada - porque según los metadatos, no existen correos de ese período.

Redate.io se conecta a Microsoft 365 y aplica su análisis de cadena de encabezados y proceso de reconstrucción de metadatos de fecha a cada mensaje afectado. No necesita saber qué herramienta hizo la migración: encuentra los correos cuya fecha mostrada no coincide con su fecha original. Cada mensaje se corrige y verifica individualmente, conservando el original en una carpeta de respaldo. Redate.io no impone ningún límite de tamaño de buzón: un buzón de 100.000 correos se corrige igual que uno más pequeño.