Las tres fechas dentro de cada correo electrónico
Cada correo almacenado en un servidor IMAP lleva al menos tres valores de fecha distintos. Comprender cómo funcionan estas fechas, y cómo los clientes de correo eligen cuál mostrar, es la clave para entender por qué la migración rompe las fechas. Este artículo es un análisis técnico en profundidad del sistema de fechas IMAP, dirigido a administradores informáticos y a toda persona que desee comprender la causa raíz de los problemas de fechas post-migración.
1. La cabecera "Date" RFC 2822
La cabecera "Date" se define en la RFC 2822 (formato de mensajes de Internet). La establece el cliente de correo del remitente en el momento en que el mensaje se compone y envía. Esta cabecera forma parte del cuerpo del mensaje, viaja con él y nunca es modificada por los servidores de correo en la ruta de entrega. Una cabecera Date típica tiene este aspecto:
Date: Mon, 15 Jan 2024 09:32:17 +0100
La cabecera Date representa la "fecha de envío" del mensaje. Es la fecha más fiable porque se define una sola vez y nunca se altera. Sin embargo, refleja el reloj del remitente, que puede estar mal configurado. En casos raros, la cabecera Date puede estar totalmente ausente (en particular en notificaciones de sistema automatizadas o mensajes malformados).
2. El IMAP INTERNALDATE
El INTERNALDATE se define en la RFC 3501 (protocolo IMAP4rev1). Es un valor de metadato del lado del servidor que representa la fecha y hora en que el mensaje fue entregado al servidor. A diferencia de la cabecera Date, el INTERNALDATE no forma parte del mensaje de correo en sí. Se almacena por separado por el servidor IMAP como metadato.
Cuando un correo se entrega normalmente (no migrado), el servidor IMAP define el INTERNALDATE a la hora actual en el momento de la entrega. Este valor se corresponde de cerca con la cabecera Date, generalmente con pocos segundos o minutos de diferencia. Los clientes de correo utilizan a menudo el INTERNALDATE como "fecha de recepción" porque refleja el momento en que el servidor recibió realmente el mensaje.
Y aquí es donde la cosa se pone interesante. Cuando un mensaje se inserta mediante el comando IMAP APPEND (lo que usan las herramientas de migración), el comando APPEND da la posibilidad al cliente de especificar el INTERNALDATE explícitamente. Las herramientas de migración bien diseñadas utilizan esta funcionalidad para preservar el INTERNALDATE original del servidor fuente. Pero incluso cuando el INTERNALDATE se define correctamente, el problema de la cabecera "Received" (descrito a continuación) puede igualmente sobreescribir la fecha mostrada en muchos clientes.
3. La cadena de cabeceras "Received"
Cada vez que un correo pasa por un servidor de correo, ese servidor añade una cabecera "Received" al principio del mensaje. Esto crea una cadena de cabeceras Received que registra el recorrido del correo desde el remitente al destinatario. La más reciente (arriba) muestra el último servidor que procesó el mensaje, y la más antigua (abajo) muestra el primero.
Un correo normal puede tener de 3 a 6 cabeceras Received, documentando el viaje desde el servidor saliente del remitente a través de los relés hasta el servidor entrante del destinatario. Cada cabecera Received incluye una marca de tiempo. A ver, un ejemplo simplificado:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Cómo los clientes de correo eligen qué fecha mostrar
Outlook (Escritorio, Web, Móvil)
Microsoft Outlook utiliza una combinación del INTERNALDATE y de la cabecera "Received" más reciente para determinar la fecha de "Recepción" mostrada en la bandeja de entrada. En la práctica, Outlook tiende a priorizar la marca de tiempo de la cabecera Received más reciente para la columna "Recibido". La columna "Enviado" utiliza la cabecera Date. Como Outlook ordena por defecto por la columna "Recibido", es la marca de tiempo de la cabecera Received lo que los usuarios ven primero.
Apple Mail
Apple Mail en macOS e iOS utiliza principalmente el IMAP INTERNALDATE para mostrar la fecha. Si el INTERNALDATE se preservó correctamente durante la migración, Apple Mail puede mostrar la fecha correcta, pero solo si el INTERNALDATE se definió explícitamente durante la operación APPEND. Si la herramienta de migración no definió el INTERNALDATE, el servidor usa por defecto la hora de inserción (la fecha de migración). Para detalles sobre el impacto en usuarios de Apple Mail, consulte Apple Mail: fecha incorrecta tras migración.
Thunderbird
Mozilla Thunderbird ofrece la mayor flexibilidad. Puede mostrar tanto "Fecha" (desde la cabecera Date) como "Recibido" (desde las cabeceras Received). Por defecto, Thunderbird muestra el valor de la cabecera Date, lo que significa que las fechas pueden aparecer correctas en Thunderbird incluso cuando son incorrectas en Outlook. La columna "Recibido" en Thunderbird muestra siempre la fecha de migración. Consulte Thunderbird: fecha incorrecta tras migración para más detalles.
Interfaz web de Gmail
El cliente web de Gmail utiliza la cabecera Date para su visualización principal de fecha. Esto significa que Gmail web muestra a menudo fechas correctas incluso tras la migración. Pero el IMAP INTERNALDATE en el servidor de Gmail sigue siendo incorrecto, lo que afecta a cada cliente IMAP que se conecte a esa cuenta de Gmail. La diferencia entre Gmail web y Outlook o Apple Mail es una fuente frecuente de confusión, y una que hace perder mucho tiempo de depuración a los administradores.
Por qué IMAP APPEND rompe las fechas
Lo que ocurre durante la migración
Cuando una herramienta de migración traslada un correo del Servidor A al Servidor B, la herramienta se conecta al Servidor A vía IMAP y descarga el mensaje en bruto, luego se conecta al Servidor B y utiliza el comando APPEND para insertarlo. Durante esta inserción, el Servidor B procesa el mensaje entrante y añade una nueva cabecera Received con la marca de tiempo actual: la fecha de migración. Es el comportamiento IMAP estándar definido en el protocolo. El servidor trata cada APPEND como una nueva entrega de mensaje.
El resultado: una cadena de cabeceras contaminada
Tras la migración, las cabeceras Received del correo tienen este aspecto:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
La cabecera Received de la herramienta de migración es ahora la entrada más alta. Cualquier cliente de correo que utilice la cabecera Received más reciente para determinar la fecha de visualización (Outlook, en particular) mostrará "11 de abril de 2025" en lugar de "15 de enero de 2024". La cabecera Date original y las cabeceras Received originales siguen intactas debajo, pero ya no están en la posición que los clientes de correo priorizan.
Incluso una buena gestión del INTERNALDATE no previene esto
Algunas herramientas de migración definen correctamente el INTERNALDATE durante el APPEND. Por ejemplo, imapsync preserva explícitamente el INTERNALDATE del servidor fuente. Pero la cabecera Received la añade el servidor destino, no la herramienta de migración. La herramienta de migración no tiene control sobre este comportamiento. Incluso con una preservación perfecta del INTERNALDATE, la cabecera Received más alta sigue conteniendo la fecha de migración, y clientes como Outlook siguen mostrando la fecha incorrecta.
¿Entonces qué se puede hacer concretamente al respecto?
Qué herramientas de migración añaden cabeceras Received
Todas las herramientas de migración IMAP causan este problema porque la cabecera Received la añade el servidor destino, no la propia herramienta. El contenido de la cabecera añadida varía según la herramienta y el servidor.
BitTitan MigrationWiz añade una cabecera Received que contiene "mx.migrationwiz.com". CloudM Migrate añade cabeceras que referencian "cloudm.io". imapsync desencadena una cabecera Received genérica del servidor destino. GSMMO añade cabeceras con referencias a "gmailapi.google.com".
La corrección: restaurar las fechas correctas
La buena noticia es que la información de fecha correcta sigue existiendo en cada correo. La cabecera Date original está intacta. Las cabeceras Received originales están intactas. El problema es que una cabecera contaminante se sitúa por encima de ellas.
El motor de corrección propietario de Redate.io analiza la cadena completa de cabeceras de cada correo afectado, aplicando coincidencia de patrones en cientos de firmas de herramientas de migración conocidas para identificar exactamente qué cabeceras necesitan corrección. El pipeline de análisis multietapa gestiona los casos límite que hacen fracasar los enfoques más simples: mensajes firmados con S/MIME, contenido cifrado con PGP, estructuras multipart/alternative, problemas de Content-Transfer-Encoding, cabeceras no ASCII (RFC 2047), adjuntos sobredimensionados y límites MIME corruptos.
Tras la corrección, cada correo pasa por un proceso de verificación de integridad para confirmar que la estructura, el contenido y los adjuntos del mensaje se preservan de forma idéntica. Los originales se conservan en una carpeta de copia de seguridad visible durante 30 días.
¿Podría escribirse un script para intentar esta corrección por cuenta propia? Técnicamente, sí. Pero la diferencia entre "funciona en el 95% de los correos" y "funciona en el 100% de los correos sin corromper ni uno solo" representa meses de desarrollo. Y cuando se habla del buzón completo de alguien, un 5% de tasa de fallo significa cientos de mensajes silenciosamente dañados sin forma de verificar qué salió mal.
¿Quiere saber cuántos correos en su buzón tienen fechas incorrectas? Inicie un análisis gratuito con Redate.io para obtener un recuento instantáneo de los correos afectados, sin pago requerido.