Migración cPanel: correos mal fechados

El lunes por la mañana que duele

Acaba de terminar la migración de un alojamiento compartido cPanel a Google Workspace o Microsoft 365. La operación ha ido bien, los buzones son accesibles, los usuarios se conectan. Luego, hacia las 9:15, llega el primer ticket: "Mis correos antiguos muestran todos la misma fecha, la del fin de semana pasado." Después un segundo. Después diez.

No es un error aislado. Es la consecuencia directa de cómo las migraciones desde cPanel tratan (o más bien no tratan) los metadatos de fecha de los correos.

cPanel, Roundcube, Horde: un contexto IMAP particular

Un alojamiento compartido cPanel es un servidor Linux que ejecuta un servidor IMAP (generalmente Dovecot) con Roundcube o Horde como interfaz webmail. Nada exótico. Pero este contexto tiene algunas particularidades que hacen las migraciones hacia plataformas empresariales más delicadas de lo que parecen.

Por un lado, los buzones cPanel acumulan correos durante años, a veces una década. Un cliente que tenía su dominio en un alojamiento compartido desde 2013 puede tener archivos muy profundos. Ese volumen, combinado con la forma en que se realiza la migración, crea el terreno perfecto para el problema de fechas.

Por otro lado, las herramientas utilizadas para estas migraciones suelen ser la herramienta nativa de cPanel (el "Migrations" de WHM), o imapsync lanzado desde la línea de comandos por el proveedor de hosting o el técnico IT, o soluciones de uso general como GSMMO para migrar a Google Workspace.

Por qué las fechas quedan corruptas tras una migración cPanel

Para entender el problema, hay que distinguir dos conceptos: la cabecera Date: de un correo y el INTERNALDATE de IMAP.

La cabecera Date: se inscribe en el cuerpo bruto del mensaje en el momento de su envío, conforme a la RFC 2822. Indica cuándo se redactó y envió el correo. Esta cabecera nunca cambia, salvo manipulación deliberada del mensaje.

El INTERNALDATE, en cambio, es un metadato que el servidor IMAP asocia a cada mensaje almacenado. Es independiente del contenido del mensaje. Cuando un correo llega normalmente a un servidor, el INTERNALDATE se define a partir de las cabeceras Received: del mensaje, o en la fecha de depósito si el mensaje se entrega directamente. Es este valor el que Outlook, Thunderbird y la mayoría de los clientes de correo utilizan para ordenar los mensajes.

Durante una migración IMAP, los mensajes se copian de un servidor a otro. El problema: la herramienta de migración tiene que crear cada mensaje en el servidor de destino. Y para muchas herramientas, el INTERNALDATE del mensaje recién creado corresponde a la fecha de la migración, no a la fecha original del mensaje. Al mismo tiempo, se añade una cabecera Received: con la fecha de migración al principio de la cadena de cabeceras, lo que perturba aún más a los clientes de correo que la consultan para calcular la fecha a mostrar.

Resultado: un correo de 2019 llega a Google Workspace con un INTERNALDATE fijado al día de la migración y una cabecera Received: fechada ayer. Outlook lo muestra en la bandeja de entrada como si acabara de llegar. Toda la cronología del archivo queda destruida.

La herramienta de migración WHM / cPanel

La herramienta integrada en WHM para migrar cuentas cPanel a otra plataforma genera este problema de forma casi sistemática cuando el destino es un servidor IMAP externo (Google Workspace, Microsoft 365). Copia el contenido de los Maildir al nuevo servidor via IMAP sin preservar el INTERNALDATE original. Cada mensaje recibe así la marca de tiempo del momento en que se realiza la operación.

imapsync y las migraciones manuales desde cPanel

imapsync es una herramienta potente, pero su comportamiento por defecto no siempre preserva las fechas. Sin los parámetros correctos (y la versión adecuada), puede perfectamente copiar 40.000 mensajes asignándoles a todos la fecha de ejecución del script. (De hecho, si alguna vez ha revisado los logs de imapsync línea por línea para diagnosticar un problema de fechas en un buzón de 25.000 mensajes, sabe que es una experiencia que no apetece repetir.)

Para ser precisos: imapsync dispone de opciones para intentar preservar la fecha, pero esas opciones interactúan de forma diferente según los servidores de origen y destino, y su eficacia no está garantizada en todas las configuraciones cPanel / Dovecot.

GSMMO y las herramientas de uso general

Google Workspace Migration for Microsoft Outlook (GSMMO) está diseñado para migrar desde Outlook, no desde un servidor IMAP puro. Cuando se usa para migrar desde cPanel (mediante una cuenta IMAP configurada en Outlook), las fechas sufren el mismo tratamiento: el INTERNALDATE en Google Workspace se fija a la fecha de migración. El problema de GSMMO con las fechas de correo está documentado por separado, dado lo extendido que está.

¿Qué clientes de correo se ven afectados?

La corrupción de fechas no se manifiesta igual según el cliente utilizado.

Outlook es el más afectado. Utiliza el INTERNALDATE (o la cabecera Received: de migración) como criterio principal de ordenación en las carpetas. Tras una migración cPanel mal gestionada, un buzón en Outlook puede mostrar miles de correos archivados con la fecha del fin de semana de migración. La corrección de fechas de imapsync en Outlook es una de las correcciones más solicitadas.

Gmail (Google Workspace) suele mostrar la fecha del encabezado Date: en la lista de correos, pero el ordenamiento puede verse afectado igualmente por el INTERNALDATE según los casos. Los usuarios reportan comportamientos erráticos en la búsqueda y el ordenamiento por fecha.

Apple Mail y Thunderbird tienen comportamientos más matizados, pero ninguno de los dos es inmune al problema, especialmente cuando la cabecera Received: de migración aparece al principio de la cadena.

Buena noticia: la fecha original sigue ahí

Este es el detalle técnico que lo cambia todo. La cabecera Date: original del mensaje está inscrita en el cuerpo bruto del correo. La migración no la toca. Si abre un correo afectado y consulta las cabeceras en bruto (en Gmail: "Mostrar original", en Outlook: Archivo > Propiedades), verá el Date: original intacto, seguido de una o varias cabeceras Received: de las que la primera lleva la fecha de migración.

Esa información sigue presente. Puede aprovecharse para corregir los metadatos. Eso es exactamente lo que hace el motor de corrección de Redate.io.

Por qué "corregirlo uno mismo" es más arriesgado de lo que parece

La tentación es grande. El problema parece sencillo: leer la fecha original, corregir los metadatos, pasar al siguiente. Pero entre entender el mecanismo y corregir 12.000 correos en producción sin perder ni uno, hay una diferencia considerable.

Algunas realidades que los scripts caseros generalmente no anticipan:

Correos firmados con S/MIME o cifrados con PGP: cualquier modificación en la estructura del mensaje invalida la firma criptográfica. Un correo que superaba la verificación de firma antes de la corrección deja de superarla después. Los usuarios con requisitos de cumplimiento normativo (despachos de abogados, sector financiero, sanidad) descubren este problema en el peor momento.
Cabeceras no-ASCII y codificación RFC 2047: los buzones cPanel acumulan años de correos procedentes de clientes de correo muy variados. Algunas cabeceras contienen caracteres codificados según RFC 2047. Un script mal escrito que reconstruye las cabeceras puede corromper esas codificaciones de forma invisible.
Estructuras MIME anidadas: un correo con tres adjuntos y un cuerpo HTML alternativo tiene una estructura multipart compleja. El mínimo error en los límites MIME hace el mensaje ilegible, o peor: los adjuntos desaparecen sin ningún mensaje de error.
Cuotas de API y rate limiting: Google Workspace y Microsoft 365 imponen límites estrictos sobre el número de operaciones IMAP por minuto. Un script que no implementa correctamente el backoff exponencial provoca errores 429 a las 3 de la madrugada, y se despierta con una migración a medias sin saber exactamente dónde se detuvo.
Sin posibilidad de rollback: si algo sale mal a mitad del proceso, ¿a qué estado vuelve? ¿Siguen ahí los originales? ¿Tiene duplicados? Redate.io conserva los originales en una carpeta de copia de seguridad visible durante 30 días, precisamente para no encontrarse nunca en esa situación.

Un script que funciona con 50 correos de prueba en un entorno de desarrollo no funcionará necesariamente con 18.000 mensajes de un buzón de producción heredado de un alojamiento cPanel desde 2011.

Cómo Redate.io corrige las fechas tras una migración cPanel

Redate.io se conecta directamente al buzón de destino (Google Workspace mediante delegación de dominio, Microsoft 365 mediante Azure AD, o servidor IMAP directo) y comienza con un escaneo gratuito para identificar los correos cuyos metadatos de fecha son incoherentes con la cabecera Date: original.

El pipeline de análisis multi-etapa aplica a continuación una correspondencia de patrones sobre las firmas de cabeceras Received: para identificar las introducidas por las herramientas de migración (y distinguirlas de las cabeceras legítimas). La corrección selectiva de metadatos se realiza sin alterar el contenido del mensaje: el texto, los adjuntos, las cabeceras originales, todo permanece intacto. Cada correo corregido se verifica individualmente antes de validar la operación.

Para las migraciones desde cPanel en particular, el motor reconoce las firmas típicas de las migraciones Dovecot-a-IMAP y de los scripts imapsync, incluidas las variantes de configuración habituales en los proveedores de alojamiento compartido.

Guías específicas según su destino

Según la plataforma de destino de su migración cPanel, las guías siguientes describen los pasos concretos:

¿Ha migrado desde cPanel y sus usuarios ven fechas incorrectas? Lance un escaneo gratuito en Redate.io para identificar exactamente cuántos correos están afectados, sin ninguna modificación antes de su aprobación.

Emails mal fechados tras migración cPanel / Roundcube