Por qué imapsync es popular (y por qué las fechas siguen rompiéndose)
imapsync es la herramienta de referencia para la migración de correo entre administradores de sistemas Linux, proveedores de hosting y todos aquellos que prefieren soluciones de código abierto. Creada por Gilles Lamiral, imapsync se mantiene activamente desde 2001 y se ha utilizado para millones de migraciones de buzones en todo el mundo. Soporta prácticamente todos los servidores IMAP: Dovecot, Courier, Cyrus, Zimbra, Exchange, Gmail y decenas más.
imapsync tiene la reputación de ser completa y configurable. Los administradores aprecian su control granular sobre las carpetas a migrar, la gestión de duplicados y el mapeo de nombres de carpetas entre distintos servidores IMAP. Pero a pesar de todo ese control, un problema persiste: las fechas de los correos con frecuencia no se preservan tras una migración imapsync. Los usuarios abren su buzón tras la migración y constatan que cada correo muestra la fecha de migración. Es exasperante, sobre todo porque se supone que imapsync gestiona las fechas correctamente.
Cómo imapsync gestiona el INTERNALDATE
El intento de preservación del INTERNALDATE
imapsync intenta efectivamente preservar el INTERNALDATE de cada correo durante la migración. El INTERNALDATE es la marca de tiempo que el servidor IMAP almacena como metadato para cada mensaje, separada de las cabeceras del correo. Cuando imapsync copia un mensaje del origen al destino, lee el INTERNALDATE del servidor fuente y lo transmite al servidor destino en el comando IMAP APPEND.
En teoría, esto debería preservar la fecha original. En la práctica, el resultado depende del comportamiento del servidor destino y de cómo los clientes de correo interpretan los distintos campos relacionados con la fecha en el mensaje.
El problema de la cabecera "Received"
Incluso cuando imapsync logra preservar el INTERNALDATE, el servidor de correo destino añade una nueva cabecera "Received" a cada mensaje durante la operación APPEND. Esta cabecera "Received" contiene la marca de tiempo actual, la fecha de migración. Clientes de correo como Outlook, Apple Mail y Thunderbird determinan la fecha de "recepción" leyendo la cabecera "Received" superior, no el INTERNALDATE. Así que a pesar del esfuerzo de imapsync por preservar el INTERNALDATE, la fecha visible en la mayoría de clientes sigue siendo incorrecta.
Es esta desconexión fundamental la que causa la confusión. imapsync preserva un valor de fecha (INTERNALDATE), pero los clientes de correo muestran otro (la marca de tiempo de la cabecera "Received"). Para una explicación técnica detallada de este mecanismo, consulte por qué los correos muestran la fecha incorrecta tras migración IMAP.
El malentendido de la FAQ de imapsync
La documentación y la FAQ de imapsync abordan el problema de fecha pero lo presentan como una limitación inherente. La FAQ sugiere que "las fechas pueden no preservarse" durante la migración IMAP e implica que simplemente así funciona el protocolo IMAP. Aunque es cierto que el protocolo IMAP exige a los servidores añadir cabeceras "Received" al insertar mensajes, la FAQ crea la impresión de que el problema es permanente e irreparable.
Eso no es exacto. Las cabeceras "Received" añadidas durante la migración pueden identificarse y eliminarse a posteriori, restaurando la visualización de la fecha original en los clientes de correo. La cabecera "Date" original (que registra cuándo se envió el correo) siempre se preserva por imapsync y sirve de referencia para la fecha correcta.
Identificar la cabecera de migración imapsync
Aspecto de la cabecera
imapsync no añade directamente una cabecera "Received"; es el servidor IMAP destino el que lo hace. La cabecera añadida durante una migración imapsync se parece generalmente a una cabecera de inserción IMAP estándar del servidor destino. Por ejemplo, al migrar a un servidor Dovecot, la cabecera podría parecerse a:
Received: from localhost by mail.example.com;
Wed, 15 Jan 2025 09:14:22 +0100El identificador clave es que esta cabecera "Received" es la superior en la cadena, su marca de tiempo coincide con la fecha de ejecución de la migración imapsync, y generalmente referencia "localhost" o el hostname del servidor destino en vez de un servidor de correo externo.
Comparar las fechas
Para confirmar el problema, compare la marca de tiempo de la cabecera "Received" superior con la cabecera "Date" del correo. Si la cabecera "Received" indica enero de 2025 pero la cabecera "Date" indica marzo de 2020, la cabecera "Received" de migración es la causa de la fecha incorrecta. Esta comparación puede hacerse visualizando la fuente en bruto del mensaje en cualquier cliente de correo.
Por qué las opciones habituales de imapsync no resuelven el problema
El flag --syncinternaldates
imapsync ofrece el flag --syncinternaldates, que establece el INTERNALDATE en el servidor destino para que coincida con la cabecera "Date" del correo. Es útil cuando el INTERNALDATE del servidor fuente ya es incorrecto, pero no impide que el servidor destino añada una cabecera "Received". La fecha visible en Outlook y otros clientes sigue siendo la fecha de migración independientemente del valor del INTERNALDATE.
La opción --addheader
imapsync puede añadir cabeceras personalizadas a los mensajes durante la migración, pero no puede impedir que el servidor destino añada su propia cabecera "Received". El protocolo IMAP exige a los servidores que registren la marca de tiempo de inserción, y ninguna opción de imapsync puede anular este comportamiento a nivel de servidor.
Scripts post-migración
Algunos administradores escriben scripts post-migración personalizados para eliminar las cabeceras "Received" no deseadas. Suena razonable, especialmente para el tipo de persona que eligió imapsync en primer lugar (alguien cómodo con la línea de comandos). Pero la realidad es mucho más compleja que un buscar-reemplazar en texto de cabeceras. ¿Qué pasa cuando el script se encuentra con un correo firmado con S/MIME? ¿O un mensaje multipart con límites MIME anidados y adjuntos codificados en base64? ¿O una cabecera con caracteres no ASCII codificados según RFC 2047? Un solo byte mal colocado en un límite MIME puede corromper silenciosamente un mensaje entero, destruyendo adjuntos o haciendo el correo ilegible. ¿Y cómo confirmar que 10.000 correos corregidos están todos intactos? Para miles de correos en múltiples buzones, el scripting casero supone un riesgo considerable.
Corregir las fechas imapsync con Redate.io
Cómo Redate.io gestiona las migraciones imapsync
El motor de corrección propietario de Redate.io está diseñado específicamente para esta categoría de problema. Tras conectarse al buzón, Redate.io analiza cada correo y pasa cada mensaje por un pipeline de análisis multietapa. Para migraciones imapsync, Redate.io detecta la cabecera "Received" insertada por el servidor aplicando coincidencia de patrones en cientos de firmas de migración conocidas, analizando la cadena completa de cabeceras y cruzando marcas de tiempo con la cabecera "Date" original.
No es una simple edición de cabeceras. El motor de corrección gestiona validación de conformidad RFC, preservación de la estructura del mensaje (incluyendo estructuras multipart/alternative, adjuntos en línea y variaciones de Content-Transfer-Encoding) y detección de firmas digitales. Los correos con firmas S/MIME o PGP se identifican automáticamente y se tratan de forma adecuada para preservar la integridad de las firmas.
Lo que se obtiene tras la corrección
Cada correo corregido muestra su fecha de recepción original en todos los clientes de correo. El orden cronológico queda restaurado. Cada corrección pasa por una verificación de integridad antes de finalizarse. El mensaje original se mueve a una carpeta "Redate.io - Originals" y se conserva durante 30 días como red de seguridad.
Compatibilidad con todos los servidores destino
Dado que imapsync se utiliza para migrar a prácticamente cualquier servidor IMAP, Redate.io soporta la misma amplitud de plataformas destino. Ya sea que la migración imapsync haya tenido como destino Dovecot, Courier, Cyrus, Zimbra, Google Workspace, Microsoft 365 u otro servidor IMAP, Redate.io se conecta y corrige las fechas.
Cómo corregir las fechas tras una migración imapsync
Conectar el buzón
Inicie sesión en Redate.io y añada el buzón. Para Google Workspace o Microsoft 365, utilice la opción de delegación de administrador. Para otros servidores IMAP (habituales en escenarios imapsync), introduzca la dirección del servidor, el nombre de usuario y la contraseña. Redate.io se conecta vía IMAP estándar.
Análisis gratuito
Ejecute el análisis gratuito para identificar los correos afectados. El informe del análisis muestra el número total de correos, cuántos tienen la fecha incorrecta y qué fecha de migración se detectó. Este análisis no cuesta nada y da una imagen clara antes de cualquier compromiso.
Corregir y verificar
Seleccione un plan en función del número de correos afectados e inicie la corrección. El progreso es visible en tiempo real. Tras completarse, verifique los resultados consultando las fechas de los correos en su cliente. Las fechas deberían haber vuelto a su lugar.
Guías de corrección imapsync por plataforma
Preguntas frecuentes
¿Debo usar --syncinternaldates de imapsync antes de usar Redate.io?
No es necesario. Redate.io establece el INTERNALDATE correcto durante el proceso de corrección, independientemente del valor actual. Tanto si imapsync preservó el INTERNALDATE original como si no, Redate.io deriva el valor correcto de la cabecera "Date" original.
¿Se pueden corregir las fechas en el servidor fuente antes de migrar con imapsync?
Si el servidor fuente ya tiene fechas incorrectas (tras una migración anterior), Redate.io puede corregirlas antes o después de la migración imapsync. Pero corregir las fechas en el servidor destino tras la migración es el enfoque más común y práctico.
¿Cuántos correos puede procesar Redate.io?
Redate.io gestiona buzones de cualquier tamaño. Hay planes disponibles para hasta 100.000 correos por buzón. Para organizaciones con muchos buzones, Redate.io ofrece tarifas por volumen.
¿La migración imapsync rompió las fechas? Inicie un análisis gratuito para ver cuántos correos están afectados y corríjalos con Redate.io.