Corregir fechas imapsync

La promesa de --syncinternaldates (y dónde se detiene)

Ejecuto el comando imapsync. Incluyo --syncinternaldates porque leyó la documentación y es cuidadoso así. La migración termina, el log dice que todo se transfirió, cero errores. Entonces abre el buzón en Outlook y cada email muestra la fecha de ayer.

Esta es una de las frustraciones más comunes con imapsync, y ha confundido a administradores de sistemas desde al menos 2017. El flag --syncinternaldates se supone que preserva el INTERNALDATE de IMAP durante la migración. Y lo hace: le da a cada copia la fecha interna que tiene el servidor de origen. Ahí está exactamente la trampa.

imapsync es una herramienta open-source en Perl escrita por Gilles Lamiral, y es genuinamente buena en lo que hace. Maneja transferencias de buzones IMAP-a-IMAP con un nivel de fiabilidad que la mayoría de herramientas comerciales envidian. Pero imapsync solo puede copiar las fechas que encuentra, y ahí es donde las cosas se complican.

Cómo funcionan realmente las fechas IMAP

Hay tres "fechas" diferentes involucradas en cada email, y la mayoría de las personas (incluidos algunos administradores de IT) las confunden:

El encabezado Date: (RFC 2822) - la fecha que el cliente de correo del remitente estampó cuando el mensaje fue compuesto. Vive dentro del cuerpo del mensaje y nunca es modificado por los servidores de correo.
Encabezados Received: - cada servidor de correo que maneja el mensaje agrega uno con su propia marca de tiempo. Forman una cadena del remitente al destinatario. El encabezado Received más alto (más reciente) es lo que algunos clientes de correo usan para la visualización.
INTERNALDATE - una marca de tiempo del lado del servidor IMAP que controla cómo se ordenan los mensajes en el buzón. Se establece cuando el mensaje se almacena por primera vez vía IMAP APPEND.

Cuando imapsync migra un mensaje, lo lee del servidor origen (incluyendo su INTERNALDATE) y lo escribe en el servidor destino usando IMAP APPEND. El flag --syncinternaldates le dice a imapsync que pase el INTERNALDATE de origen al servidor destino durante el APPEND.

Aquí está la buena noticia: Microsoft 365, Outlook.com y Gmail conservan la fecha que reciben. Así que, cuando las fechas salen mal, el problema está en otra parte.

Por qué las fechas pueden seguir estando mal

La especificación IMAP (RFC 3501) dice que si se proporciona una fecha-hora con el comando APPEND, el servidor DEBERÍA usarla. "DEBERÍA" en lenguaje RFC significa "hágalo a menos que tenga una buena razón para no hacerlo". Microsoft 365, Outlook.com y Gmail sí lo hacen: una copia que lleva su fecha original la conserva.

Lo que imapsync transmite, sin embargo, es la fecha que el servidor de ORIGEN tiene para cada mensaje, no la fecha en que se envió el correo. En un buzón sano, ambas coinciden. En un buzón que ya se migró una vez o se restauró desde una copia de seguridad, el origen puede conservar la fecha de esa operación anterior, e imapsync la copia tal cual.

Gmail es un caso aparte solo cuando la copia pasa por la propia API de importación de Gmail en lugar de IMAP: esa API añade una línea Received: fechada el día de la copia, y Outlook puede mostrar esa fecha. imapsync habla IMAP, así que no se ve afectado.

Dovecot y Cyrus, los dos servidores IMAP open-source más comunes, también conservan la fecha del APPEND. Así que, sea cual sea el destino, la pregunta es la misma: ¿qué fecha tenía el origen?

Errores comunes de línea de comandos imapsync que rompen las fechas

Más allá de las fechas de origen, los administradores a menudo tropiezan con las opciones de línea de comandos de imapsync, o culpan a las que no son. Estos son los errores que veo con más frecuencia:

Copiar desde un origen cuyas fechas ya estaban mal

--syncinternaldates está activado por defecto: imapsync le da a cada copia la fecha interna que tiene el servidor de origen (su documentación dice: "Sets the internal dates on host2 as the same as host1"). Si el buzón de origen es a su vez el resultado de una migración o restauración anterior, sus fechas internas pueden ya ser las de esa operación, e imapsync copia fielmente la fecha equivocada. Es la causa más común, y la más fácil de pasar por alto, porque el log muestra dos fechas idénticas.

Usar --syncinternaldates con --addheader

Algunas guías recomiendan usar --addheader para inyectar un encabezado personalizado durante la migración. Agregar un encabezado modifica el mensaje (una línea más al principio) pero no la fecha que imapsync transmite, así que no explica fechas equivocadas. La copia simplemente deja de ser idéntica al original, lo cual importa si compara ambos.

Confundir --minage y --maxage con preservación de fechas

Los flags --minage y --maxage filtran qué mensajes migrar basándose en su edad. No afectan cómo se manejan las fechas en el destino. He visto administradores pasar horas ajustando estos flags pensando que corregirán el problema de fechas. No lo harán.

Culpar a TLS de fechas desviadas

Sobre TLS (--ssl1, --ssl2), establecer las conexiones agrega latencia, y en una migración grande (50.000+ mensajes) eso suma horas. No afecta las fechas: cada copia lleva la fecha que imapsync transmite, sin importar a qué hora llegue realmente.

Leer los logs de imapsync: qué dice realmente la salida

imapsync produce logs detallados, lo cual es bueno. Pero la salida del log puede ser engañosa en lo que respecta a fechas.

Una línea típica de transferencia exitosa se ve así:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Ambas fechas coinciden. Y Microsoft 365, Outlook.com y Gmail conservan la fecha que reciben. Pero dos fechas idénticas solo prueban que la copia es fiel al ORIGEN: si la fecha de origen ya estaba mal, ambas columnas muestran la misma fecha equivocada.

?Quiere verificar qué pasó realmente? Después de la migración, conéctese al destino con un cliente IMAP y verifique el INTERNALDATE directamente:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Si la fecha devuelta no es la fecha en que se envió el correo, mire ese mismo mensaje en el origen: encontrará ahí la misma fecha equivocada. El log no mintió, copió lo que se le dio.

Este es uno de los aspectos más frustrantes del debugging de problemas de fechas: un archivo de log limpio, dos fechas idénticas, y aun así la fecha equivocada en Outlook, porque el error ya estaba ahí antes de que imapsync se ejecutara.

Migraciones imapsync a gran escala: donde los problemas de fechas se multiplican

Una migración de buzón individual con imapsync es molesta cuando las fechas se rompen. Pero los MSP y departamentos de IT que ejecutan imapsync a través de cientos de buzones enfrentan una escala de problema completamente diferente.

Considere un escenario típico de migración empresarial. Está moviendo 200 buzones de un servidor Zimbra a Microsoft 365. Escribe un script wrapper que itera sobre un CSV de usuarios, llamando a imapsync para cada uno. La migración corre durante el fin de semana. El lunes por la mañana, tiene 200 buzones con fechas incorrectas y alrededor de 1,2 millones de emails en total mostrando el timestamp de migración.

¿Se puede volver a ejecutar imapsync para corregirlo? Técnicamente sí, pero imapsync saltará los mensajes que ya existen en el destino (está diseñado para ser idempotente). Necesitaría --delete2 para eliminar los mensajes del destino y retransferirlos, lo cual es arriesgado en un buzón de producción. Y si el problema eran las fechas de origen, una segunda ejecución copia otra vez las mismas fechas equivocadas.

Algunos administradores intentan un enfoque híbrido: ejecutar imapsync con --dry primero para probar, luego la migración real. Pero --dry solo simula la transferencia: muestra las fechas que imapsync transmitiría, no si son las fechas en que se enviaron los correos. Nada le advierte que las fechas de origen ya están mal.

Correcciones caseras y sus límites

Si busca en foros y listas de correo (la lista imapsync-devel en SourceForge sigue activa a principios de 2026), encontrará sugerencias que van desde creativas hasta peligrosas.

Algunos sugieren usar un one-liner de Perl para modificar el INTERNALDATE en el servidor destino directamente. Otros recomiendan exportar todos los mensajes a formato mbox, manipular las fechas y reimportar. Algunos han escrito scripts en Python que usan imaplib para recuperar, modificar y reinsertar mensajes.

Todos estos enfoques comparten los mismos problemas fundamentales. ?Cómo manejar mensajes firmados con S/MIME sin romper la firma? ?Qué pasa con las estructuras MIME multiparte con límites anidados? ?Encabezados no-ASCII codificados con RFC 2047? ?Mensajes cifrados con PGP donde ni siquiera se puede inspeccionar el contenido? Un script que maneja 50 mensajes de prueba en un entorno de desarrollo se ahogará con los casos límite de un buzón de producción de 30.000 mensajes.

Y la pregunta más grande que nadie hace hasta que es demasiado tarde: ?cómo se verifica que cada mensaje modificado sigue intacto? ?Que los adjuntos no se corrompieron, que el hilo de conversación sigue funcionando, que la hoja de cálculo de 85 MB que alguien envió por email en 2020 sobrevivió a la manipulación?

(Si alguna vez ha intentado parsear encabezados de email crudos en Perl, sabe que no es precisamente una actividad relajante para la tarde.)

Cómo Redate.io corrige los problemas de fechas de imapsync

El encabezado Date: original siempre está intacto después de una migración imapsync. imapsync transfiere el mensaje crudo fielmente; la fecha equivocada está en los metadatos que recibió la copia, no en el mensaje. Ese encabezado original es lo que hace posible la corrección.

Redate.io se conecta directamente al buzón (Google Workspace, Microsoft 365 o cualquier servidor IMAP), escanea en busca de emails con anomalías de fecha y aplica corrección dirigida de metadatos a través de un pipeline propietario de análisis de cadena de encabezados y reconstrucción de fechas. No necesita saber qué herramienta hizo la migración: encuentra los correos cuya fecha mostrada no coincide con su fecha original.

Cada email corregido se verifica individualmente: integridad del mensaje, preservación de adjuntos, ubicación en carpetas, hilos de conversación, etiquetas. Los originales se conservan en una carpeta de respaldo visible Redate.io - Originals hasta que usted decida eliminarlos. Si algo no se ve bien, revertir está a un clic de distancia.

El escaneo gratuito se conecta al buzón, identifica cada email con una anomalía de fecha y reporta el conteo exacto y el costo. Sin tarjeta de crédito, sin software que instalar. Para los detalles de su plataforma:

Redate.io también funciona para migraciones que ocurrieron hace meses o años. El encabezado Date: no caduca, y la capacidad de corregir tampoco.

?Migró con imapsync y tiene fechas incorrectas? Ejecute un escaneo gratuito para ver exactamente cuántos emails están afectados.

imapsync: ?fechas no conservadas? Cómo corregirlas