Cambiar la fecha de un email: límites técnicos

Un email tiene tres "fechas". No una.

Cuando se habla de "cambiar la fecha de recepción de un email", la mayoría de la gente imagina modificar un campo en algún lugar, como se modificaría la fecha de creación de un archivo en Windows. La realidad es algo más compleja. Un email transporta en realidad tres capas de datación distintas, cada una con sus propias reglas, sus propios guardianes, y sus propias consecuencias si se toca.

Entender estas tres capas es entender por qué ciertas correcciones son técnicamente sanas, y otras son imposibles o detectables de inmediato como falsificaciones.

Capa 1: el INTERNALDATE de IMAP

El INTERNALDATE es un metadato almacenado en el servidor, fuera del mensaje en sí. No forma parte del contenido del email. Lo define el servidor IMAP, y es el que la mayoría de los clientes de correo utilizan para ordenar los mensajes en su lista.

Outlook, por ejemplo, muestra por defecto los mensajes ordenados por INTERNALDATE. Gmail también, en ciertos contextos. Por tanto, si su INTERNALDATE es incorrecto, todos sus emails parecen tener la misma fecha en la interfaz, independientemente de lo que digan las cabeceras internas del mensaje.

El INTERNALDATE se define en el momento en que el mensaje se deposita en el servidor. A través del protocolo IMAP, la única forma de "modificarlo" es indirecta: hay que usar el comando APPEND para depositar una nueva copia del mensaje con la fecha deseada. No existe un comando IMAP SETINTERNALDATE. Este detalle cobrará importancia en un momento.

Capa 2: la cabecera Date: (RFC 2822)

Es el campo Date: en las cabeceras sin procesar del mensaje. Lo define el cliente de correo en el momento del envío, y viaja con el mensaje de servidor en servidor. Es la fecha de envío declarada por el remitente.

(Por cierto, si nunca ha mirado las cabeceras sin procesar de un email, es una lectura bastante sorprendente. Cada mensaje arrastra unas veinte líneas técnicas que el 99% de las personas nunca ha visto.)

Técnicamente, nada impide enviar un email con un campo Date: antedatado o posdatado. Los servidores SMTP no validan este campo. Pero los servidores destinatarios sí anotan la hora de llegada real en las cabeceras Received:, lo que crea de inmediato una incoherencia visible para cualquier cliente de mensajería o herramienta de análisis.

Capa 3: las cabeceras Received: apiladas

Cada vez que un servidor SMTP retransmite un mensaje, añade una cabecera Received: en lo alto de la pila, con una marca de tiempo. Un email que pasa por tres servidores tendrá tres cabeceras Received:. Se leen de abajo hacia arriba: la más antigua está abajo, la más reciente arriba.

Es precisamente aquí donde las herramientas de migración crean el problema. Cuando BitTitan MigrationWiz, CloudM, imapsync o GSMMO migran un email, lo reinyectan en el nuevo servidor vía IMAP. Ese depósito genera una nueva entrada Received: fechada en el momento de la migración. Resultado: el mensaje más antiguo de su buzón, un email de 2019, acaba con un Received: fechado en noviembre de 2024. Y como ciertos clientes de correo (Outlook a la cabeza) utilizan el Received: más reciente como fecha de visualización...

Ahí está el problema. 15.000 emails muestran todos la misma fecha de migración.

¿Se puede realmente "modificar" estas fechas?

Técnicamente, sí para el INTERNALDATE (con restricciones). Técnicamente posible pero inútil para el Date:. Y para los Received:, merece que nos detengamos.

Reescribir una cabecera Received: es trivial. Y detectable de inmediato.

Una cabecera Received: no es más que una línea de texto en el mensaje. Se puede editar como cualquier archivo de texto. Es exactamente tan sencillo como parece.

Pero esto es lo que ocurre después.

Primer problema: DKIM. La firma DKIM (DomainKeys Identified Mail) se calcula sobre un conjunto de cabeceras del mensaje, incluyendo a veces los Received:. Modificar una cabecera firmada invalida la firma. Cualquier servidor destinatario que verifique DKIM verá de inmediato que el mensaje ha sido alterado. No es una falsificación sutil, es una alarma.

Segundo problema: los identificadores internos. Los servidores de correo modernos (Google Workspace, Microsoft 365) asignan a cada mensaje un identificador interno incremental y único. Estos identificadores están vinculados al INTERNALDATE y al orden de recepción. Modificar un Received: sin coherencia con estos identificadores crea incoherencias que las herramientas de auditoría detectan sin dificultad.

Tercer problema, más práctico: incluso si modifica el Received: en el contenido del mensaje, no ha tocado el INTERNALDATE, que sigue siendo el del depósito IMAP. El cliente de correo continúa mostrando la fecha incorrecta para la ordenación. Ha modificado el mensaje para nada.

En resumen. Reescribir los Received: para falsificar una fecha de email con fines maliciosos: trivial técnicamente, detectable en pocos segundos por un experto. No es una vía seria.

La cabecera Date:: cambiar el pasado sobre el papel

El mismo razonamiento se aplica al Date:. Se puede modificar en el cuerpo del mensaje. Pero las cabeceras Received: autenticadas por los servidores intermedios permanecen intactas y cuentan otra historia. La cadena temporal es incoherente. Cualquier analista o tribunal que compare esos campos lo verá de inmediato.

Para ser precisos, eso no impide que algunos clientes de correo muestren el Date: modificado si se les presenta directamente el archivo .eml. Pero en el contexto de un servidor de correo activo, con autenticación y registros, la modificación es transparente.

La migración IMAP: el único contexto donde corregir las fechas es legítimo

Hay un caso, y solo uno, en que modificar la fecha de recepción de un email no solo es posible sino técnicamente justificado: corregir los daños causados por una migración IMAP mal gestionada.

La situación concreta es esta. Acaba de migrar 80 buzones de Exchange a Microsoft 365. La migración terminó un viernes por la noche. El lunes por la mañana llegan los primeros tickets: "Todos mis emails tienen la misma fecha", "No puedo encontrar un email del año pasado", "Mi historial con este cliente está completamente roto". Tiene 80 usuarios bloqueados y su responsable esperando una respuesta.

En ese contexto, el problema está documentado, es identificable, y su causa es clara: la herramienta de migración añadió un Received: fechado el día de la migración, y ciertos clientes de correo utilizan esa nueva cabecera como fecha de visualización. La cabecera Date: original, en cambio, está intacta en cada mensaje. Nunca fue modificada. Contiene todavía la fecha de envío original, correcta.

La corrección no es, por tanto, una falsificación: es una restauración. Se parte de datos verdaderos (el Date: original) para reconstruir metadatos coherentes. Esto es fundamentalmente diferente de intentar hacer pasar un email de 2024 por un email de 2019.

Para profundizar en los mecanismos específicos de cada herramienta, estas guías detallan los casos concretos: corregir las fechas de BitTitan en Microsoft 365, corregir las fechas de CloudM en Outlook, o corregir las fechas de imapsync en Google Workspace.

Por qué no escribir un script uno mismo

La lógica básica es accesible. Cualquier administrador IT que haya pasado tiempo en foros IMAP puede reconstituir el enfoque general. Ese no es el problema.

El problema es la diferencia entre un script que funciona con 50 emails de prueba y un script que procesa 40.000 mensajes en producción sin perder un solo email, sin corromper un solo archivo adjunto, y sin romper un solo hilo de conversación.

Algunos casos concretos que los scripts caseros generalmente no gestionan:

• Emails firmados con S/MIME: la firma cubre el contenido y las cabeceras. Cualquier modificación de la estructura del mensaje invalida la firma. Un email firmado corregido torpemente llega con "firma no válida" a los destinatarios.
• Mensajes cifrados con PGP: la misma familia de problemas, con consecuencias potencialmente peores según la implementación.
• Codificaciones no ASCII en cabeceras: el RFC 2047 describe la codificación de caracteres especiales en cabeceras. Un script que manipula cabeceras sin gestionar estos casos corromperá silenciosamente asuntos de emails con acentos, caracteres japoneses o nombres árabes.
• Límites de tasa de la API: Google Workspace y Microsoft 365 implementan throttling agresivo. A las 3 de la madrugada, un lote de 10.000 emails que choca con un error 429 Too Many Requests sin gestión de backoff exponencial deja la mitad de los buzones a medio corregir.
• Fronteras MIME corruptas: los mensajes multipart con archivos adjuntos tienen fronteras MIME precisas. Regenerarlas incorrectamente hace que los adjuntos queden ilegibles.

Y la pregunta que ningún script casero resuelve: ¿cómo verificar que cada email corregido está intacto? Un script que modifica 40.000 mensajes sin verificación individual es una apuesta. Una apuesta con datos que sus usuarios consideran a menudo irremplazables.

Un artículo sobre las opciones disponibles para corregir fechas tras una migración explora los distintos enfoques, incluyendo sus limitaciones respectivas.

Qué hace Redate.io en este contexto

Redate.io está diseñado específicamente para este caso: corregir las fechas dañadas por una migración IMAP, a gran escala, sin riesgo para la integridad de los mensajes.

El servicio se conecta directamente a los buzones afectados (Google Workspace mediante delegación de dominio, Microsoft 365 vía Azure AD, o IMAP directo), analiza de forma gratuita los mensajes con fechas incorrectas, y aplica un motor de corrección propietario que gestiona los casos límite documentados anteriormente. Cada email se verifica de forma individual tras la corrección. Los originales permanecen en una carpeta de copia de seguridad visible durante 30 días.

El análisis de patrones cubre cientos de firmas de herramientas de migración conocidas: BitTitan MigrationWiz, CloudM, imapsync, GSMMO, y sus variantes. La detección es precisa: Redate.io no toca los emails cuya fecha es correcta.

El modelo de precios es sencillo: pago único por buzón de correo, sin suscripción. El análisis de diagnóstico es gratuito, lo que permite medir el alcance de los daños antes de decidir cualquier cosa.

Si gestiona buzones afectados por este problema, este artículo sobre fechas erróneas en Outlook tras migración detalla los síntomas más habituales y cómo distinguirlos de otras causas.

¿Listo para medir el alcance del problema en sus buzones? Lance un análisis gratuito en Redate.io y vea exactamente cuántos emails están afectados antes de realizar ninguna corrección.