El síntoma: todos sus correos tienen fecha de hoy
Acaba de terminar un import PST en Outlook. La barra de progreso llegó al 100%, todo fue bien. Abre la bandeja de entrada... y cada correo importado muestra la fecha de hoy. Un mensaje de 2019, otro de 2021, un archivo de cinco años: todos llevan la misma fecha. La del día del import.
No es un error de visualización. No es un problema de zona horaria. Es un comportamiento perfectamente documentado, coherente con la forma en que IMAP gestiona los metadatos de fecha. Pero sigue siendo un desastre para cualquiera que necesite encontrar correos antiguos por fecha.
PST local e IMAP: dos mundos muy distintos
Antes de explicar por qué se rompen las fechas, conviene entender qué es un archivo PST desde el punto de vista de la gestión de fechas.
Un archivo PST (Personal Storage Table) es un formato propietario de Microsoft. Almacena los correos con sus metadatos completos: fecha de envío, fecha de recepción, archivos adjuntos, categorías, indicadores de lectura. Estos metadatos los gestiona Outlook directamente, fuera de cualquier protocolo de mensajería. Cuando consulta un PST en Outlook sin conexión a un servidor, las fechas mostradas provienen directamente de los campos internos del archivo PST. Hasta aquí, todo bien.
El problema aparece cuando intenta transferir ese contenido a un buzón alojado en un servidor IMAP, ya sea Microsoft 365, Google Workspace o cualquier proveedor de alojamiento convencional. Ahí deja el mundo PST y entra en el mundo IMAP, y las reglas cambian radicalmente.
IMAP APPEND e INTERNALDATE: el núcleo del problema
En IMAP, cada mensaje almacenado en el servidor tiene dos tipos de datos de fecha:
- La cabecera
Date:(RFC 2822), que forma parte del contenido del propio mensaje. Es la fecha que el remitente inscribió en el mensaje. - El INTERNALDATE, que es un metadato gestionado por el servidor IMAP. Representa el momento en que el mensaje fue depositado en el servidor. Es este valor el que Outlook usa para ordenar los mensajes en la vista "Fecha de recepción".
(Por cierto, si alguna vez ha intentado leer las cabeceras brutas de un correo electrónico, sabe que no es exactamente lectura de playa. Pero ahí es donde ocurre todo.)
Cuando un correo llega normalmente a su servidor, el servidor de mensajería define automáticamente el INTERNALDATE en el momento exacto de la recepción. Resultado: la fecha mostrada en Outlook corresponde al momento en que recibió el mensaje.
Cuando Outlook importa un archivo PST hacia un buzón IMAP, utiliza el comando IMAP APPEND para enviar cada mensaje al servidor. El estándar IMAP permite pasar un INTERNALDATE explícito durante un APPEND. Pero Outlook no lo hace. Envía los mensajes sin especificar un INTERNALDATE. El servidor IMAP, ante la ausencia de instrucción, aplica su regla por defecto: el INTERNALDATE se define como la hora actual, es decir, el momento del import.
Resultado: 8.000 correos importados, 8.000 correos con la fecha de hoy.
Por qué Outlook se comporta así
No es un descuido de Microsoft. Es una decisión de implementación que probablemente parecía razonable en su momento: en el caso de uso original del import PST, el usuario archiva mensajes localmente y los "importa" a su buzón actual. La fecha relevante para el ordenamiento sería la fecha de recepción original... pero Microsoft eligió no propagar el INTERNALDATE durante la operación de import.
Para ser exactos, este comportamiento afecta al import PST a través del asistente nativo de Outlook (Archivo > Abrir y exportar > Importar/Exportar). Otros métodos de import, como ciertas herramientas de terceros o migraciones a través del Centro de administración de Exchange, pueden comportarse de forma distinta según su implementación de IMAP APPEND.
Este comportamiento está documentado en los foros de Microsoft desde hace años. No cambió con Outlook 2016, ni con Outlook 2019, ni con las versiones actuales de Microsoft 365. Un usuario que importe un PST hoy encontrará exactamente el mismo problema que en 2015.
En qué se diferencia de una migración IMAP clásica
Aquí es donde resulta interesante, porque el import PST produce un resultado similar al de una migración IMAP clásica con fechas rotas, pero por un mecanismo diferente.
En una migración IMAP típica, por ejemplo con BitTitan MigrationWiz o imapsync, los correos pasan de un servidor IMAP origen a un servidor IMAP destino. La herramienta de migración recupera los mensajes y los reinyecta mediante IMAP APPEND. Algunas herramientas preservan correctamente el INTERNALDATE, otras no. Pero en todos los casos, los mensajes ya tienen una cabecera Received: con la fecha de migración añadida de paso, lo que puede perturbar la visualización en Outlook independientemente del INTERNALDATE.
Con un import PST, el mecanismo es más sencillo: no se añade ninguna cabecera Received: de migración (los archivos PST no transitan por ningún servidor de mensajería intermedio), pero el INTERNALDATE simplemente nunca se define al valor correcto. El resultado visible es idéntico; la causa subyacente es ligeramente diferente.
Esta distinción tiene una consecuencia directa en la corrección: el enfoque no es exactamente el mismo según se trate de una migración IMAP o de un import PST. Véase también por qué el INTERNALDATE provoca fechas rotas para una explicación detallada de los dos casos.
Por qué las opciones de vista de Outlook no corrigen nada
La reacción habitual al descubrir el problema es buscar en los ajustes de Outlook. Y de hecho hay un parámetro que parece prometedor: la posibilidad de ordenar los correos por "Fecha" en lugar de por "Fecha de recepción".
Ordenar por fecha de envío no es una solución. Es un parche.
He aquí por qué: aunque cambie el ordenamiento para mostrar la columna "Fecha" (que corresponde a la cabecera Date: del mensaje, es decir, la fecha original), varios problemas persisten:
- La búsqueda de Outlook indexa sobre el INTERNALDATE. Una búsqueda de "correos de enero de 2020" no devolverá sus correos importados de enero de 2020, porque su INTERNALDATE indica que son del día del import.
- Las carpetas "Hoy", "Esta semana", "Este mes" en la interfaz de Outlook se basan en el INTERNALDATE, no en la cabecera
Date:. - En las interfaces web (Outlook Web App, Gmail) y en los clientes móviles, la fecha mostrada y el comportamiento de ordenamiento dependen casi siempre del INTERNALDATE del servidor.
- Las reglas y filtros automáticos aplicados a la fecha de recepción no funcionarán correctamente.
En definitiva, cambiar la vista soluciona la visualización para un usuario concreto, en un cliente concreto, con una configuración concreta. No corrige el problema en su origen.
La resincronización OST tampoco sirve de nada
Otro intento clásico: vaciar la caché OST y forzar una resincronización completa desde el servidor. La idea es que quizás el problema proviene de la caché local de Outlook, no del servidor.
Pista falsa. El archivo OST es una caché local que refleja el estado del servidor IMAP. Si el INTERNALDATE está mal en el servidor, estará mal en el OST después de la resincronización. Eliminar el OST no cambia nada en los datos almacenados en Exchange Online o Google Workspace. El servidor es quien tiene la autoridad.
La única forma de corregir las fechas es corregir los metadatos directamente en el lado del servidor, mensaje a mensaje. Y es precisamente ahí donde hacerlo de forma manual se complica.
El problema de escala: 1 correo es trivial. 15.000 es otra historia
Técnicamente, si se entiende el problema, podría imaginarse escribir un script que recorra el buzón, lea la cabecera Date: de cada mensaje y corrija el INTERNALDATE en consecuencia. Entender el problema es una cosa. Corregirlo en 15.000 correos sin perder ni uno solo es otra muy distinta.
Algunas realidades del terreno:
- Las API de Microsoft Graph y Gmail imponen límites de tasa (rate limits). Un script sin precauciones disparará errores 429 Too Many Requests, interrumpirá su ejecución en medio de una corrección, y le dejará con un buzón parcialmente corregido, sin saber qué correos se han procesado y cuáles no.
- Algunos correos en un PST pueden tener cabeceras
Date:malformadas o ausentes. Un script sin gestión de estos casos límite puede corromper esos mensajes o saltárselos silenciosamente. - Los correos firmados (S/MIME) o cifrados (PGP) tienen restricciones de integridad adicionales. Modificar sus metadatos sin precaución puede invalidar la firma criptográfica.
- Las estructuras multipart/alternative con límites MIME complejos reaccionan a veces de forma impredecible ante operaciones de modificación.
- Ningún mecanismo de rollback. Si algo va mal a mitad del procesamiento, ¿cómo se vuelve al estado inicial?
Un script que funciona con 10 correos de prueba no funcionará en un buzón de producción de 50.000 mensajes. El año pasado, un cliente con un archivo PST de 40 GB intentó corregir esto con un script Python descargado de Stack Overflow. Resultado: 3.000 correos duplicados, 200 mensajes con archivos adjuntos inaccesibles, y dos semanas de limpieza manual.
Qué hace Redate.io en este caso concreto
Redate.io analiza los metadatos de cada mensaje en el buzón de destino, identifica los correos con fechas incorrectas (incluidos los procedentes de un import PST) y aplica una corrección mediante su motor propietario. El pipeline de análisis multi-etapa compara la cadena de cabeceras de cada mensaje, extrae la fecha original con validación de conformidad RFC, y procede a una corrección selectiva de los metadatos sin alterar el contenido del mensaje.
Cada correo corregido se verifica de forma individual. Los originales se conservan en una carpeta de copia de seguridad visible durante 30 días antes de cualquier modificación definitiva. La corrección funciona en las tres plataformas principales: Microsoft 365 (mediante Azure AD), Google Workspace (mediante delegación de dominio) e IMAP directo para proveedores convencionales.
El análisis inicial es gratuito. Permite ver exactamente cuántos correos están afectados y cuál es la distribución de las fechas incorrectas, antes de decidir nada.
Véase también:
- Corregir fechas tras migración a Microsoft 365
- Outlook: fecha recibida IMAP vs fecha enviada
- ¿Se pueden corregir fechas de email tras migración?
¿Su import PST ha sobreescrito todas las fechas de sus correos? Analice su buzón gratuitamente en Redate.io para medir el alcance del problema antes de actuar.