Resumen

  • POP3 numeraba los mensajes al abrir el buzón, de modo que el mismo elemento podía ocupar otra posición en la siguiente conexión. La antigua orden LAST conservaba solo el mayor número accedido y no una memoria individual.
  • RFC 1725 eliminó LAST y añadió UIDL. RFC 1939 hizo que el identificador persistiera entre sesiones dentro de un buzón, pero también obligó al cliente a aceptar que dos copias idénticas compartieran un UID calculado por hash.

Un buzón contiene dos copias byte por byte del mismo mensaje. La lista UIDL devuelve dos números actuales y el mismo token. ¿Ha fallado la unicidad?

La RFC 1939 dice que el cliente debe poder manejar precisamente esa situación. El servidor puede guardar identificadores asignados arbitrariamente, la opción preferida, pero también puede calcularlos como un hash del mensaje. Dos copias idénticas producirán entonces la misma clave.

La regla revela el alcance real de UIDL. El mecanismo no quería contar objetos físicos ni crear un nombre universal para cada correo. Quería que un cliente que se desconectaba pudiera reconocer mensajes retenidos cuando volviera, aunque los números de posición del buzón hubieran cambiado.

Una aplicación que reduce la lista a un diccionario de “un UID, una fila” puede perder una copia. Una que conserva la multiplicidad actual y el ámbito del buzón puede usar el token para la pregunta correcta: ¿el servidor presenta esta entidad como la que ya conocía en otra sesión?

Los números describían la apertura presente

POP3 nació para equipos pequeños o con conectividad intermitente. Un servidor mantenía el maildrop y el cliente se conectaba para recuperar correo. El patrón normal era descargar y borrar; el protocolo no pretendía ofrecer la gestión remota extensa de IMAP.

Al abrir el maildrop, el servidor asignaba los números 1, 2 y siguientes según el orden actual. Esos números servían como argumentos de LIST, RETR o DELE durante la transacción. Si una posición anterior desaparecía antes de la conexión siguiente, todo lo posterior podía desplazarse.

La RFC 1460 intentó conservar una forma de progreso con LAST. El servidor devolvía el mayor número accedido en transacciones anteriores y el cliente podía suponer que los números superiores eran nuevos. RETR y DELE podían adelantar esa frontera; RSET la devolvía a cero.

Un máximo no identifica entidades. No representa huecos, no distingue el historial de dos clientes y depende de que la orden del buzón conserve el significado esperado. Convertía muchos hechos particulares en una sola frontera.

La RFC 1725 describió claramente su revisión de 1994: eliminó LAST y añadió la orden opcional UIDL. No declaró que una decisión causara exclusivamente la otra, pero el resultado arquitectónico fue pasar de un progreso lineal guardado por el servidor a tokens por mensaje con los que cada cliente podía mantener su propio historial.

Un número para actuar y un UID para recordar

UIDL puede recibir un número o listar todos los mensajes no marcados para eliminación. Cada línea contiene primero la posición actual y luego el identificador. Las dos piezas no son redundantes.

El número es necesario para actuar en esta sesión. El UID atraviesa el cierre y permite comparar la lista con el registro local. La RFC 1939 exige que persista incluso si la sesión anterior termina sin UPDATE.

Ese caso protege contra una incertidumbre habitual. El cliente puede haber recibido el cuerpo antes de que la conexión se corte. Como no hubo QUIT que llevara la sesión a UPDATE, el servidor no debe borrar los mensajes marcados. En la próxima conexión el mensaje sigue allí. Un UID estable evita que el fallo de cierre lo convierta automáticamente en correo nuevo.

El servidor no debería reutilizar un identificador en el mismo maildrop mientras exista la entidad que lo usa. Si lo hiciera, una nueva fila podría presentarse al cliente como una que ya había procesado.

La persistencia, sin embargo, pertenece al token durante la vida de la entidad. No obliga al servidor a conservar el mensaje indefinidamente.

El ámbito del maildrop evitó una identidad ficticia

La palabra “unique” puede inducir tres exageraciones. La primera es globalidad: la RFC solo garantiza el ámbito de un maildrop. La misma cadena en otra cuenta o servidor no tiene relación definida. La segunda es autenticidad: el UID no certifica remitente, destinatario, entrega ni lectura. La tercera es identidad de contenido: aunque se permita un hash, la especificación no convierte el token en firma criptográfica ni promete que toda implementación lo derive del cuerpo.

La excepción de las copias idénticas añade un cuarto límite. La clave puede reconocer una clase de contenido idéntico sin distinguir cada instancia almacenada. El cliente debe conservar el número de filas que el servidor presenta ahora. Una lista con dos números y un token repetido no es lo mismo que una sola fila.

Así, UIDL combina dos dimensiones: identidad temporal y multiplicidad presente. El registro local puede decir que el token ya fue descargado, pero la lista actual todavía decide cuántas copias existen y qué números permiten operar sobre ellas.

La retención era otra autoridad

La opción de dejar mensajes en el servidor generó acumulación. RFC 1939 advierte de buzones con cientos o miles de mensajes ya leídos y permite que el operador aplique cuotas o reglas de retención fuera del protocolo. Un UID visto ayer no es un recibo de custodia para mañana.

RFC 2449 creó CAPA porque las órdenes opcionales se descubrían antes mediante pruebas o configuración manual. La capacidad UIDL anuncia soporte. No prueba la continuidad histórica de un servidor migrado ni la ausencia de fallos en sus identificadores.

El mismo documento definió EXPIRE. El servidor puede anunciar un mínimo de días, cero o NEVER. Incluso ese dato es deliberadamente impreciso para un mensaje concreto: el reloj puede empezar al llegar, al aparecer en LIST o UIDL, después de RETR o en otro evento.

El soporte de UIDL, la identidad del token y la duración del objeto son estados distintos. Un cliente que los fusiona no sabe si un token ausente fue borrado por política, eliminado por otro cliente o simplemente no apareció por un error de sesión.

La inteligencia local necesitaba una ruta de recuperación

POP3 prefería mantener el servidor simple y colocar inteligencia en el cliente. Cada aplicación podía decidir qué significaba “ya procesado” y conservar su propio registro de UID. Eso evitaba un modelo central complejo de leído/no leído para cada dispositivo.

También hizo que una migración o restauración pudiera romper memoria sin perder los mensajes. Si el nuevo servidor regenera todos los tokens, el contenido antiguo parece nuevo. El efecto puede ser una descarga masiva de duplicados. Si, en dirección opuesta, el cliente confía demasiado en una clave repetida, puede omitir una copia legítima.

La solución no consiste en atribuir al UID más fuerza. Consiste en preservar su namespace cuando corresponde, incluir servidor y cuenta en el ámbito de las claves, conservar multiplicidad y tratar un reset como reconciliación explícita.

UIDL fue exitoso por su modestia. Dio al borde memoria entre desconexiones, pero dejó claro que una identidad útil no necesita contestar todas las preguntas sobre el objeto. Dos copias podían compartir un valor y seguir siendo dos copias.

Fuentes