Corregir fechas imapsync

La promesa de --syncinternaldates (y por que falla)

Ejecuto el comando imapsync. Incluyo --syncinternaldates porque leyo la documentacion y es cuidadoso asi. La migracion termina, el log dice que todo se transfirio, cero errores. Entonces abre el buzon en Outlook y cada email muestra la fecha de ayer.

Esta es una de las frustraciones mas 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 migracion. Y tecnicamente, lo intenta. Pero "intenta" esta haciendo mucho trabajo pesado en esa frase.

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 mayoria de herramientas comerciales envidian. Pero la preservacion de fechas no esta enteramente en manos de imapsync, y ahi es donde las cosas se complican.

Como funcionan realmente las fechas IMAP

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

El encabezado Date: (RFC 2822) - la fecha que el cliente de correo del remitente estampo 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 mas alto (mas reciente) es lo que algunos clientes de correo usan para la visualizacion.
INTERNALDATE - una marca de tiempo del lado del servidor IMAP que controla como se ordenan los mensajes en el buzon. Se establece cuando el mensaje se almacena por primera vez via 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.

Aqui esta el problema: el servidor de destino no esta obligado a respetar esa fecha.

Por que los servidores de destino ignoran el INTERNALDATE

La especificacion IMAP (RFC 3501) dice que si se proporciona una fecha-hora con el comando APPEND, el servidor DEBERIA usarla. "DEBERIA" en lenguaje RFC significa "hagalo a menos que tenga una buena razon para no hacerlo". Varias plataformas de correo importantes han decidido que tienen una buena razon.

Microsoft 365 es el mayor infractor. Cuando un mensaje llega via IMAP APPEND, el pipeline de transporte de Exchange le estampa un nuevo encabezado Received con la fecha actual, y luego establece el INTERNALDATE basado en esa marca de tiempo de entrega. No importa que fecha solicito imapsync. El servidor M365 la sobreescribe.

Google Workspace (Gmail) se comporta diferente pero puede igualmente causar problemas. La implementacion IMAP de Gmail respeta el INTERNALDATE del APPEND en la mayoria de los casos, pero agrega su propio encabezado Received. Si el cliente de correo que lee el buzon prioriza los encabezados Received sobre el INTERNALDATE para la visualizacion (y Outlook hace exactamente esto), las fechas siguen apareciendo mal.

Dovecot y Cyrus, los dos servidores IMAP open-source mas comunes, generalmente respetan el INTERNALDATE del APPEND. Asi que las migraciones imapsync entre dos servidores Dovecot usualmente preservan las fechas correctamente. Los problemas comienzan cuando el destino es una plataforma alojada con su propio procesamiento de transporte.

Errores comunes de linea de comandos imapsync que rompen las fechas

Incluso cuando el servidor de destino cooperaria, los administradores a menudo tropiezan con las opciones de linea de comandos de imapsync. Estos son los errores que veo con mas frecuencia:

Olvidar --syncinternaldates completamente

El flag no esta habilitado por defecto. Si ejecuta un imapsync --host1 source --host2 dest --user1 user --user2 user basico sin el, imapsync no intenta preservar fechas en absoluto. El servidor destino usa la marca de tiempo actual para cada mensaje. Es la causa mas comun, y la mas facil de pasar por alto porque imapsync no le advierte al respecto.

Usar --syncinternaldates con --addheader

Algunas guias recomiendan usar --addheader para inyectar un encabezado personalizado durante la migracion. Si esta agregando encabezados, esta modificando el mensaje, lo cual puede hacer que el servidor destino lo trate como un mensaje "nuevo" y lo estampe en consecuencia. La interaccion entre estos dos flags esta pobremente documentada.

Confundir --minage y --maxage con preservacion de fechas

Los flags --minage y --maxage filtran que mensajes migrar basandose en su edad. No afectan como se manejan las fechas en el destino. He visto administradores pasar horas ajustando estos flags pensando que corregiran el problema de fechas. No lo haran.

Desviacion de timestamps por negociacion SSL

Al migrar sobre TLS con --ssl1 y --ssl2, la configuracion de la conexion agrega latencia. En migraciones grandes (50.000+ mensajes), esta latencia se acumula. No cambia las fechas por dias, pero puede causar que mensajes enviados con minutos de diferencia lleguen con timestamps identicos al destino, perdiendo su orden relativo.

Leer los logs de imapsync: que dice realmente la salida

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

Una linea tipica de transferencia exitosa se ve asi:

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. Eso significa que imapsync envio el INTERNALDATE correcto al destino. Pero no significa que el servidor destino realmente almaceno esa fecha. imapsync reporta lo que solicito, no lo que el servidor acepto.

?Quiere verificar que paso realmente? Despues de la migracion, conectese al destino con un cliente IMAP y verifique el INTERNALDATE directamente:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Si la fecha devuelta es la fecha de migracion en lugar de 2019-01-15, el servidor destino ignoro la solicitud de imapsync. El log le mintio (bueno, le dijo lo que pidio, no lo que obtuvo).

Esta brecha entre lo que imapsync reporta y lo que realmente sucede es uno de los aspectos mas frustrantes del debugging de problemas de fechas. Puede mirar fijamente un archivo de log limpio durante horas y nunca darse cuenta de que las fechas estan mal del otro lado.

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

Una migracion de buzon individual con imapsync es molesta cuando las fechas se rompen. Pero los MSP y departamentos de IT que ejecutan imapsync a traves de cientos de buzones enfrentan una escala de problema completamente diferente.

Considere un escenario tipico de migracion empresarial. Esta 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 migracion corre durante el fin de semana. El lunes por la manana, tiene 200 buzones con fechas rotas y alrededor de 1,2 millones de emails en total mostrando el timestamp de migracion.

?Se puede volver a ejecutar imapsync con --syncinternaldates si se olvido la primera vez? Tecnicamente si, pero imapsync saltara los mensajes que ya existen en el destino (esta disenado para ser idempotente). Necesitaria --delete2 para eliminar los mensajes del destino y retransferirlos, lo cual es arriesgado en un buzon de produccion. E incluso entonces, si el servidor destino ignora el INTERNALDATE, se vuelve al punto de partida.

Algunos administradores intentan un enfoque hibrido: ejecutar imapsync con --dry primero para probar, luego la migracion real. Pero --dry no prueba lo que el servidor destino hace con el INTERNALDATE. Solo simula la transferencia. El problema de fechas es invisible hasta que los mensajes se escriben realmente en el destino.

Correcciones caseras y sus limites

Si busca en foros y listas de correo (la lista imapsync-devel en SourceForge sigue activa a principios de 2026), encontrara 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. ?Como manejar mensajes firmados con S/MIME sin romper la firma? ?Que pasa con las estructuras MIME multiparte con limites 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 ahogara con los casos limite de un buzon de produccion de 30.000 mensajes.

Y la pregunta mas grande que nadie hace hasta que es demasiado tarde: ?como se verifica que cada mensaje modificado sigue intacto? ?Que los adjuntos no se corrompieron, que el hilo de conversacion sigue funcionando, que la hoja de calculo de 85 MB que alguien envio por email en 2020 sobrevivio a la manipulacion?

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

Como Redate.io corrige los problemas de fechas de imapsync

El encabezado Date: original siempre esta intacto despues de una migracion imapsync. imapsync transfiere el mensaje crudo fielmente; es el manejo de metadatos del servidor de destino lo que causa el problema de visualizacion. Ese encabezado original es lo que hace posible la correccion.

Redate.io se conecta directamente al buzon (Google Workspace, Microsoft 365 o cualquier servidor IMAP), escanea en busca de emails con anomalias de fecha y aplica correccion dirigida de metadatos a traves de un pipeline propietario de analisis de cadena de encabezados y reconstruccion de fechas. La correccion maneja los patrones especificos que las migraciones imapsync dejan atras, incluyendo las firmas caracteristicas de encabezados Received de servidores destino que sobreescribieron el INTERNALDATE.

Cada email corregido se verifica individualmente: integridad del mensaje, preservacion de adjuntos, ubicacion en carpetas, hilos de conversacion, etiquetas. Los originales se conservan en una carpeta de respaldo visible Redate.io - Originals durante 30 dias. Si algo no se ve bien, revertir esta a un clic de distancia.

El escaneo gratuito se conecta al buzon, identifica cada email con una anomalia de fecha y reporta el conteo exacto y el costo. Sin tarjeta de credito, sin software que instalar. Para los detalles de su plataforma:

Redate.io tambien funciona para migraciones que ocurrieron hace meses o anos. El encabezado Date: no caduca, y la capacidad de corregir tampoco.

?Migro con imapsync y tiene fechas incorrectas? Ejecute un escaneo gratuito para ver exactamente cuantos emails estan afectados.

imapsync: ?fechas no conservadas? Como corregirlas