Corregir fechas de migración de imapsync en Microsoft 365
Por qué las migraciones de imapsync muestran la fecha incorrecta en Microsoft 365
Las migraciones de imapsync a Microsoft 365 (Exchange Online) enfrentan un doble desafío con la preservación de fechas. Primero, la pasarela IMAP de Exchange Online tiene comportamientos específicos que pueden sobrescribir la INTERNALDATE proporcionada por el indicador --syncinternaldates de imapsync. Segundo, Exchange Online agrega su propio encabezado Received durante el proceso de IMAP APPEND, marcando cada mensaje con la marca de tiempo de migración.
La implementación IMAP de Microsoft 365 es limitada en comparación con los protocolos completos de Exchange (EWS, MAPI). Cuando imapsync sube vía IMAP, el mensaje pasa por la canalización de transporte de Exchange Online, que lo procesa de manera similar a un nuevo mensaje entrante. Esta canalización agrega encabezados de transporte, ejecuta verificaciones de cumplimiento y marca el mensaje con metadatos de entrega que reflejan la hora de subida real en lugar de la INTERNALDATE solicitada.
Los administradores que eligen imapsync para migraciones a Microsoft 365 (a menudo porque es gratuito y scriptable) descubren después de la migración que la preservación de fechas no funcionó como se esperaba. El indicador --syncinternaldates, que funciona correctamente con muchos servidores IMAP estándar, no produce los resultados esperados con la implementación IMAP particular de Exchange Online. Todo el buzón migrado muestra la fecha de migración en todos los clientes de Microsoft 365.
Cómo afecta esto a Microsoft 365
En Microsoft 365, la fecha de migración aparece uniformemente en Outlook de escritorio, OWA, Outlook móvil y Microsoft Search. A diferencia de Gmail (donde el cliente web puede enmascarar el problema), los clientes de Microsoft 365 hacen referencia a la misma marca de tiempo de entrega. Los usuarios no tienen solución alternativa y no tienen ningún cliente que muestre la fecha correcta hasta que se corrijan los encabezados Received y la INTERNALDATE subyacentes a nivel del servidor.
Las funciones administrativas y de cumplimiento de Microsoft 365 se ven igualmente afectadas. Exchange Online Protection, las políticas de Prevención de Pérdida de Datos y las búsquedas de cumplimiento de Microsoft Purview indexan todas la marca de tiempo de migración. Para organizaciones sujetas a regulaciones de retención de datos, las fechas corruptas significan que las políticas de retención basadas en la antigüedad del mensaje operan con datos incorrectos, potencialmente causando la eliminación prematura de mensajes que deberían retenerse o la retención indefinida de mensajes que deberían haberse purgado.
Preguntas frecuentes
¿Por qué falla imapsync --syncinternaldates con Microsoft 365?
La implementación IMAP de Exchange Online procesa los mensajes subidos a través de su canalización de transporte, que puede sobrescribir la INTERNALDATE solicitada. Además, Exchange Online agrega encabezados Received que llevan la marca de tiempo de subida. Estos comportamientos del lado del servidor están fuera del control de imapsync.
¿Debería haber usado una herramienta de migración diferente para Microsoft 365?
La mayoría de las herramientas de migración (incluidas las comerciales como BitTitan y CloudM) producen el mismo problema de fechas porque la causa raíz está en cómo Exchange Online procesa los mensajes subidos. La elección de la herramienta de migración no previene el problema. Redate.io lo soluciona independientemente de la herramienta utilizada.
¿Puede Redate.io corregir buzones migrados con imapsync de forma masiva?
Sí. Redate.io admite el procesamiento masivo de buzones para Microsoft 365. Los administradores pueden escanear y corregir múltiples buzones desde un único panel de control. El plan Enterprise admite hasta 100.000 correos por buzón.