Paso de POP a IMAP: sus emails antiguos tienen fecha de hoy

El escenario clásico del lunes por la mañana

Acaba de cambiar su cuenta de correo de POP3 a IMAP. La configuración era sencilla, su proveedor le guió paso a paso, todo fue bien. Hasta que volvió a abrir su bandeja de entrada. Sus correos de 2019, de 2021, sus archivos del año pasado... todos muestran la misma fecha: hoy. A veces incluso la misma hora, con segundos de diferencia.

No es un error de su cliente de correo. No es un problema de zona horaria. Es el comportamiento esperado del protocolo IMAP, y afecta a cualquiera que suba mensajes almacenados localmente a un servidor mediante este método.

POP3 vs IMAP: una diferencia fundamental de almacenamiento

Para entender por qué ocurre el problema, primero hay que entender cómo funciona POP3 y en qué se diferencia radicalmente de IMAP.

Con POP3, el servidor actúa únicamente como buzón temporal. Su cliente (Outlook, Thunderbird, Apple Mail) se conecta, descarga los mensajes y luego los elimina del servidor (o los conserva, según su configuración). Los correos viven entonces exclusivamente en local: en un archivo .pst en Outlook, en el perfil local de Thunderbird, en una base de datos en su disco duro.

Con IMAP es al revés: los correos viven en el servidor. El cliente solo muestra lo que está almacenado de forma remota. De ahí la sincronización transparente entre todos sus dispositivos.

El problema aparece en la transición entre ambos protocolos. Concretamente, cuando sube sus correos POP locales al servidor IMAP.

IMAP APPEND: el comando que lo cambia todo

Cuando su cliente de correo sube un mensaje local a un servidor IMAP, utiliza el comando IMAP APPEND. Este comando le dice al servidor: "almacena este mensaje en tal carpeta".

El servidor recibe el mensaje, lo guarda y le asigna una marca de tiempo. Esa marca de tiempo es el INTERNALDATE. Es la metadato central de IMAP: indica cuándo se depositó el mensaje en el servidor. Y por defecto, si el cliente no especifica explícitamente una fecha en el comando APPEND, el servidor usa... el momento actual.

Dicho de otro modo: no importa que el mensaje contenga en sus cabeceras una fecha de 2018. Si nadie le dice al servidor "este correo es de 2018", el servidor concluye que acaba de llegar y le asigna el INTERNALDATE de hoy.

(Por cierto, si alguna vez ha visto las cabeceras en bruto de un correo, habrá visto la línea Date: entre una decena de líneas Received:. Ese campo Date:, definido por la RFC 2822, contiene la fecha de envío real. Pero el INTERNALDATE de IMAP es una metadato separada, almacenada en el servidor, que no tiene nada que ver con el contenido del mensaje.)

Por qué es diferente a una migración IMAP a IMAP

En una migración clásica de un servidor IMAP a otro (con BitTitan, CloudM, imapsync, etc.), el problema es ligeramente distinto. La herramienta de migración copia los mensajes de un servidor al otro y, en ese caso, puede (en teoría) transmitir el INTERNALDATE original al servidor de destino mediante el comando APPEND. El problema allí es que ciertas herramientas añaden una cabecera Received: con la fecha de migración, lo que perturba la visualización en clientes como Outlook.

En su caso, parte de datos puramente locales. No hay ningún INTERNALDATE de origen que copiar. El archivo .pst o el perfil de Thunderbird almacena los mensajes en su propio formato propietario, con sus propias metadatos internas. Cuando el cliente de correo relee esos mensajes para subirlos al servidor IMAP, reconstruye el comando APPEND a partir del contenido del mensaje. Y la mayor parte de las veces, no transmite ninguna fecha explícita.

Resultado: el servidor IMAP recibe cientos o miles de mensajes en cuestión de minutos y les asigna a todos el mismo rango horario: ahora.

Por eso el problema se propaga instantáneamente a todos sus dispositivos. Su teléfono, su tableta, su segundo ordenador: todos se conectan al mismo servidor IMAP y ven exactamente lo mismo. No hay corrección posible desde el lado del cliente.

Qué muestra cada cliente, y por qué

No todos los clientes de correo reaccionan igual. Es algo que muchos administradores IT descubren a posteriori.

Outlook (en sus versiones recientes, especialmente desde las actualizaciones de 2023-2024) utiliza el INTERNALDATE del servidor para la columna "Recibido". Muestra por tanto la fecha de subida, no la fecha de envío original. Para más detalles sobre este comportamiento específico de Outlook, este artículo es útil: Outlook: fecha recibida IMAP vs fecha enviada.

Gmail / Google Workspace y Thunderbird tienen comportamientos algo más matizados. Gmail, por ejemplo, puede en ocasiones usar el campo Date: de la cabecera del mensaje para la visualización, lo que da la impresión de que todo está bien... hasta que intenta ordenar por fecha y se da cuenta de que el orden es completamente aleatorio.

Apple Mail muestra generalmente la fecha extraída de la cabecera Date:, pero la ordenación y la búsqueda pasan por el INTERNALDATE en segundo plano. Así que sus correos pueden "parecer" bien fechados visualmente, pero la función de ordenación ya no funciona correctamente. Para los detalles del comportamiento de Apple Mail, vea Apple Mail: fecha incorrecta tras migración.

La buena noticia: la fecha original está intacta

La cabecera Date: de cada correo, la que contiene la fecha real de envío (o de recepción), no ha sido tocada. Sigue ahí, en el cuerpo del mensaje. Es la que ve cuando abre un correo y consulta los detalles.

Lo que el servidor IMAP ha "roto" es únicamente el INTERNALDATE, esa metadato externa al mensaje. El mensaje en sí está intacto.

Eso es lo que hace posible la corrección. Y también explica por qué el problema puede pasar desapercibido durante un tiempo: los correos parecen correctos cuando los abre uno a uno. Solo al mirar la lista de su bandeja de entrada ordenada por fecha el problema se hace visible. Correos de 2019 aparecen arriba como si acabaran de llegar. Todos con la misma fecha.

El problema de escala: 3.000 correos es otra cosa que 3

Quizás piense: "Borro y reimporto, esta vez correctamente." Con 5 o 10 correos de prueba, sí, funciona. Con una bandeja de 8.000 mensajes, carpetas anidadas, archivos adjuntos voluminosos, correos firmados con S/MIME e hilos que se remontan a 2015... la historia es distinta.

Un script casero que funciona en un lote de prueba de 50 correos puede perfectamente generar duplicados, perder archivos adjuntos o romper hilos de conversación en una bandeja de producción. La gestión de cuotas de API, los timeouts de red, los mensajes con estructuras MIME atípicas... son todos casos límite que una herramienta no especializada no maneja.

¿Y si algo sale mal a mitad del proceso? Sin mecanismo de copia de seguridad y rollback, pierde datos sin posibilidad de recuperarlos.

El problema es bien conocido entre los administradores que gestionan migraciones a gran volumen. Entender por qué las fechas están rotas es una cosa. Corregir correctamente 15.000 correos preservando cada estructura de mensaje es otra. Para profundizar en el tema, el artículo ¿Se pueden corregir fechas de email tras migración? detalla los diferentes enfoques y sus límites.

Cómo Redate.io gestiona este caso específico

Redate.io fue diseñado precisamente para este tipo de situación. Su motor de análisis identifica los correos cuyo INTERNALDATE no coincide con la fecha contenida en las cabeceras del mensaje, ya sea en una migración POP a IMAP, una migración entre servidores IMAP, o una subida manual de archivos locales.

El pipeline de análisis multi-etapa inspecciona la cadena de cabeceras de cada mensaje, valida la conformidad con la RFC y reconstruye los metadatos de fecha sin alterar el contenido del mensaje: ni el texto, ni los archivos adjuntos, ni la estructura MIME, ni las posibles firmas digitales. Cada correo corregido se verifica individualmente antes de su validación.

Los originales se conservan en una carpeta de copia de seguridad visible durante 30 días. Si algo no le conviene, puede restaurarlo.

El análisis inicial es gratuito: Redate analiza su bandeja, identifica los correos afectados e indica el número exacto antes de que decida nada. Sin compromiso a ciegas.

Redate.io se conecta directamente a sus buzones mediante Google Workspace (delegación de dominio), Microsoft 365 (Azure AD) o IMAP directo. Sin instalación local. Sin exportar archivos .pst que manipular a mano.

Para los administradores que gestionan varias bandejas y quieren conocer la experiencia práctica en este tipo de casos, el artículo MSP: corregir fechas de correo de clientes es una buena lectura complementaria. Y para las particularidades de la corrección en Thunderbird, que tiene su propio comportamiento en el paso POP/IMAP, vea Thunderbird: fecha incorrecta tras migración.

Si todavía está a tiempo: anticipar el problema

Si aún no ha subido sus archivos locales al servidor IMAP, o si planea otras migraciones de cuentas POP en su organización, hay algunas cosas que conviene tener en cuenta.

• Verifique si su cliente de correo admite pasar la fecha explícitamente en el comando APPEND. Thunderbird, por ejemplo, ha tenido comportamientos variables según la versión en este punto.
• Haga primero una prueba en una cuenta de validación con 50-100 mensajes representativos: correos antiguos, con adjuntos, correos firmados. Compruebe las fechas mostradas en distintos clientes.
• Planifique la corrección antes de que los usuarios finales empiecen a trabajar en la bandeja migrada. Corregir las fechas en una bandeja activa es más complejo que en una bandeja recién migrada.
• Documente el número de correos antes y después de la migración. Es la única forma de detectar pérdidas silenciosas.

Para una checklist completa de los puntos a verificar antes y después de una migración, el artículo Checklist migración email: prevenir problemas de fechas cubre todos los casos.

¿Sus correos antiguos muestran la fecha de hoy tras el paso de POP a IMAP? Lance un análisis gratuito en Redate.io para medir el alcance del problema y corregir los metadatos de fecha sin tocar el contenido de sus mensajes.