Resumen

  • Los números de secuencia de IMAP son posiciones relativas: al expulsar un mensaje, los posteriores cambian de número. Los UID persisten entre sesiones, pero su validez está limitada al buzón y a una generación UIDVALIDITY.
  • Si cambia UIDVALIDITY, el cliente debe descartar su caché y las acciones pendientes dirigidas a los UID anteriores. Reconstruir el estado cuesta, pero evita que una referencia vieja modifique o elimine otro mensaje.

La caché recordaba bien; el mundo que recordaba ya no existía

Un portátil cierra la tapa con una copia local de la bandeja de entrada. El usuario, sin conexión, marca para borrar el UID 9207. Durante esas horas el operador migra el buzón desde un almacén que no podía conservar los identificadores de IMAP. Los mensajes sobreviven, pero reciben una nueva secuencia de UID. En ella, 9207 pertenece a un correo distinto.

El peligro no parece un fallo convencional. El usuario tiene permiso, TLS protege la sesión y el comando UID STORE puede estar bien formado. Si el servidor conserva la antigua UIDVALIDITY, ambas partes confunden una coincidencia numérica con continuidad de objeto.

IMAP eligió sacrificar la comodidad. El servidor anuncia otra UIDVALIDITY. El cliente elimina el mapa local de ese buzón y no ejecuta la orden pendiente. La sincronización empieza de nuevo, porque una intención antigua no puede gobernar un objeto nuevo por accidente.

Contar una fila no equivale a nombrar su contenido

El número de secuencia de IMAP describe el lugar actual de un mensaje. En una carpeta de doce piezas, las posiciones son 1 a 12. Sirven para obtener intervalos y para calcular cuántos mensajes llegaron. Mientras la carpeta permanece abierta, el servidor informa los cambios y el cliente puede seguir el movimiento.

Pero una expulsión altera la geometría. Si desaparece la posición 3, la antigua 4 se convierte en 3 y todas las posteriores descienden. Un valor puede pasar de un mensaje a otro durante la misma sesión. Así lo detalla RFC 2060, y RFC 9051 conserva la regla en IMAP4rev2.

La posición es buena para operar sobre la vista presente; es mala para guardar una decisión mientras el cliente duerme. Un teléfono desconectado no observa las expulsiones producidas por la tableta, el webmail o una regla del servidor. Al regresar, “mensaje 3” solo describe la lista nueva.

IMAP4 inventó una memoria separada del orden

En diciembre de 1994, RFC 1730 presentó IMAP4 con una ambición específica: manipular buzones remotos y permitir que un cliente fuera de línea se resincronizara. El UID era un entero de 32 bits, ascendente dentro del buzón, posiblemente discontinuo y persistente entre conexiones.

El UID permitía conservar estado local con un costo razonable. En vez de identificar cada correo por cuerpo, fecha y asunto al reconectar, el cliente podía preguntar por los números que ya conocía y asociar con ellos banderas o acciones.

La infraestructura real complicaba la promesa. Muchos almacenes de correo habían nacido antes de IMAP y no reservaban un campo permanente para esos UID. Una herramienta externa podía reordenar el archivo. Un administrador podía borrar un buzón y crear luego otro con el mismo nombre. Una restauración podía recuperar los mensajes sin recuperar sus metadatos de identificación.

El estándar no declaró que lo imposible fuera obligatorio ni permitió que el servidor ocultara la pérdida. Introdujo una generación explícita.

UIDVALIDITY delimitó el espacio de confianza

Cada buzón comunica una UIDVALIDITY. Si los UID de la sesión previa dejaron de persistir, la nueva debe ser mayor. Un servidor puede derivarla de la fecha de creación o de un contador monotónico; la arquitectura no depende de una receta única. Depende de que el cambio de generación sea inequívoco para el cliente.

El nombre induce una lectura equivocada. RFC 2683 advierte que UIDVALIDITY no identifica un buzón. Dos buzones pueden tener el mismo valor. Tampoco la pareja UIDVALIDITY–UID es un identificador global de 64 bits. El contexto completo incluye el nombre del buzón.

RFC 3501 formuló el compromiso con precisión: nombre del buzón, UIDVALIDITY y UID deben referirse para siempre a un solo mensaje inmutable en ese servidor. RFC 9051 mantiene el principio. El cuerpo, el sobre, la fecha interna, el tamaño y la estructura no pueden convertirse silenciosamente en los de otra pieza. Las banderas sí cambian, porque forman parte del estado editable.

La garantía también se extiende después de expulsar el correo: el servidor no puede reutilizar ese UID bajo la misma UIDVALIDITY. La ausencia no libera el nombre para otro objeto.

Un almacén imperfecto debía ser imperfecto a la vista

Cambiar UIDVALIDITY es caro. Los clientes pierden el beneficio de sus cachés y vuelven a pedir información. Por eso las especificaciones animan con fuerza a mantener los UID. Sin embargo, RFC 4315 define UIDNOTSTICKY para almacenes heredados incapaces de hacerlo, y a la vez recomienda no diseñar sistemas nuevos con esa debilidad.

La excepción no rebaja la regla en secreto. El servidor puede admitir que no ofrece persistencia; no puede simularla mientras recicla identificadores.

Las recomendaciones de RFC 2683 surgieron de problemas de implementación, no de una abstracción remota. Señalan la peor consecuencia de ignorar UIDVALIDITY: borrar el mensaje equivocado con un UID obsoleto. Copiar, mover o cambiar banderas también puede trasladar una decisión a una pieza que el usuario nunca vio.

La honestidad del error protege más que la apariencia de disponibilidad.

La pérdida del estado local era una operación de seguridad semántica

RFC 4549 ordena el trabajo de un cliente desconectado. Al abrir el buzón debe comparar la UIDVALIDITY recibida con la almacenada. Si difieren, vacía la caché de esa carpeta, elimina las acciones pendientes referidas a sus UID antiguos y las considera fallidas.

El protocolo no intenta rescatar las acciones buscando asuntos o tamaños parecidos. Esos datos pueden facilitar una búsqueda humana; no demuestran que un borrado preparado para un mensaje deba aplicarse a otro. Cuando la generación cambia, la autoridad de la caché termina.

El radio de destrucción es local. Un buzón que perdió su mapa no obliga a invalidar los demás. RFC 2683 incluso cuestiona los UID asignados desde un contador global de servidor: consumirían el espacio de 32 bits más rápido y un agotamiento afectaría a todas las carpetas. El ámbito pequeño preserva recursos y contiene el fallo.

Un enlace guardado necesitaba conocer su vejez

Ya en 1997, RFC 2192 permitió incluir UIDVALIDITY y UID en una URL de IMAP. Al abrirla, el programa debía comparar la generación guardada con la actual para decidir si el enlace estaba obsoleto.

No es una fecha de caducidad del mensaje. No demuestra autoría, autorización ni integridad criptográfica. Es un dato que permite desactivar una referencia cuando la institución técnica que la emitió ya no puede sostener su continuidad.

La diferencia parece pequeña, pero separa la identidad de la mera localización. Una URL útil no solo indica dónde buscar; lleva la condición bajo la cual debe dejar de afirmar que encontró lo mismo.

Las optimizaciones obedecieron primero a la generación

Con bandejas grandes y conexiones móviles, comparar todo después de cada corte era ineficiente. RFC 7162 unió CONDSTORE y QRESYNC. Las secuencias de modificación permiten pedir metadatos cambiados; VANISHED comunica UID expulsados; el cliente puede recuperar el estado en una sola ida y vuelta.

Sin embargo, el primer dato que el cliente aporta a QRESYNC es su UIDVALIDITY conocida. Cuando no coincide, el servidor ignora la secuencia de modificación y el conjunto de UID restantes. Esas diferencias pueden ser exactas, pero pertenecen a otra generación.

La jerarquía es sensata. Antes de preguntar qué cambió, hay que demostrar que las entidades comparadas siguen siendo las mismas. Un delta rápido aplicado al universo equivocado solo acelera la corrupción.

UIDONLY retiró la coordenada relativa, no el límite

RFC 9586, publicado como Experimental en mayo de 2024, ofrece UIDONLY. Una vez activada la extensión, el cliente no usa números de secuencia y el servidor no los devuelve. Las formas UID y las respuestas basadas en UID reemplazan la correspondencia entre posición e identidad; VANISHED informa las expulsiones.

La motivación incluye el ahorro de recursos en ambos extremos. Mantener un mapa entre números móviles y UID estables tiene un costo. UIDONLY muestra una evolución de treinta años hacia referencias menos ambiguas.

Pero no convierte el UID en una identidad universal. Sigue siendo un número dentro de un buzón y de una UIDVALIDITY. Eliminar la posición no elimina la posibilidad de que el almacén renazca.

La continuidad solo fue creíble porque podía revocarse

IMAP repartió la autoridad de manera verificable. El servidor posee el almacén y sabe si preservó los UID; por eso declara UIDVALIDITY. El cliente posee la caché y las órdenes aplazadas; por eso debe invalidarlas al detectar el cambio. Ninguno puede usar la conveniencia del otro como prueba.

El estándar común no dicta el formato del disco, la estrategia de restauración ni la base local del teléfono. Define un invariante, una señal de ruptura y una reacción. Esa capa delgada admite implementaciones diversas sin permitir que una referencia vieja controle silenciosamente un contenido nuevo.

El UID logró sobrevivir a una sesión porque IMAP también diseñó la forma de decir que no sobrevivió al renacimiento del buzón.

Fuentes y límites

RFC 1730 contiene el diseño de 1994; RFC 2060, RFC 3501 y RFC 9051 desarrollan la diferencia entre secuencia, UID y generación. RFC 2683 aporta experiencia de implementación, RFC 2192 la prueba de obsolescencia en enlaces, RFC 4315 UIDNOTSTICKY, RFC 4549 la disciplina de caché, RFC 7162 QRESYNC y RFC 9586 el experimento UIDONLY. Las fuentes no prueban cuotas actuales de despliegue, conductas de productos concretos, autenticidad del correo ni un único algoritmo para UIDVALIDITY.