Resumen

  • CLOSE llevaba una doble instrucción: abandonar el estado Selected y eliminar de forma permanente todos los mensajes con la marca \Deleted. Para ganar eficiencia no enviaba una respuesta EXPUNGE por cada mensaje.
  • UNSELECT, definido en RFC 3691, devolvió la conexión al estado Authenticated y liberó los recursos del buzón sin eliminar mensajes. Dos decisiones con el mismo destino en la máquina de estados obtuvieron verbos diferentes.

Un programa de correo termina de trabajar con Inbox. Quiere mantener la autenticación porque todavía hará otras operaciones, pero ya no necesita que el servidor conserve el contexto del buzón seleccionado. No pretende confirmar ninguna eliminación.

La orden que parecía describir esa intención era CLOSE. Sin embargo, en un buzón seleccionado con escritura, su efecto no se limitaba a cerrar el contexto. El servidor retiraba para siempre todos los mensajes que ya tuvieran \Deleted y después devolvía la conexión a Authenticated.

Las marcas podían haberse acumulado durante una sesión larga. Otro cliente podía haber cambiado alguna. El usuario podía seguir considerando la decisión. Aun así, el acto aparentemente administrativo de salir se convertía en el momento que daba efecto definitivo a todo el conjunto.

RFC 3691 introdujo UNSELECT en 2004 para expresar la intención que faltaba. La orden libera los recursos del buzón seleccionado y realiza la misma transición de estado que CLOSE, salvo por una diferencia esencial: no elimina ningún mensaje de forma permanente.

La mejora no consistió en añadir otra forma de gestionar correo. Consistió en dejar de exigir un permiso destructivo a quien solo quería entregar un contexto de trabajo.

El estado Selected tenía coste y significado propios

Una conexión IMAP autenticada puede conocer buzones, pero necesita seleccionar uno para buscar mensajes, recuperarlos, alterar indicadores, copiarlos o realizar operaciones de eliminación. Al entrar en Selected, cliente y servidor comparten un contexto concreto. El servidor mantiene información y puede comunicar cambios relacionados con ese buzón.

Abandonar ese contexto no obliga a terminar la conexión. Un cliente puede pasar a otro buzón o esperar autenticado. Por eso la transición de Selected a Authenticated es una operación legítima por sí misma: libera recursos y reduce el estado vivo sin cambiar la identidad de la sesión.

El diagrama de IMAP asignaba esa transición a CLOSE. Los diagramas, no obstante, resumen el punto de salida y el de llegada; no siempre muestran lo que una arista hace con datos persistentes. Dos órdenes pueden terminar en Authenticated y, aun así, dejar buzones distintos.

La marca \Deleted tampoco equivale a una desaparición ya consumada. Indica que el mensaje está preparado para un expunge. Solo cuando se ejecuta esa operación cruza el límite irreversible. La separación permite marcar, revisar y después confirmar. También permite que una marca y su confirmación procedan de momentos o actores diferentes.

Al unir cierre y expunge, CLOSE hacía que el último actor heredara autoridad sobre todas las marcas que encontraba.

Menos mensajes en el cable no significaban menos eliminación

La orden EXPUNGE elimina los mensajes marcados y emite una respuesta no etiquetada por cada retirada. Las respuestas usan message sequence numbers, posiciones dentro de la vista seleccionada. Cuando un mensaje desaparece, los posteriores cambian de número; la secuencia de avisos permite seguir ese movimiento.

CLOSE omite esos avisos individuales. El diseño tenía una razón operativa: un cliente que va a abandonar el buzón probablemente no usará las nuevas posiciones. Cuando hay muchas bajas, evitar respuestas que serán descartadas puede resultar bastante más rápido.

La optimización reducía prueba en el cable, no el efecto en el almacén. Un OK etiquetado demuestra que la orden terminó, pero no que nada fue borrado. Tampoco ofrece un inventario de UID retirados. Si una investigación conserva solo la orden y el resultado, puede saber que el cierre tuvo éxito sin poder reconstruir la población afectada.

Existe además una condición de modo. En un buzón abierto por EXAMINE o seleccionado de otro modo como solo lectura, CLOSE no elimina mensajes y no devuelve error por no hacerlo. El mismo nombre y la misma forma de éxito pueden corresponder a una mutación permanente o a ninguna mutación.

La evidencia útil necesita unir buzón, modo, conjunto previo de marcas, identidad estable cuando esté disponible, orden escogida y recepción del resultado. closed=true no responde la pregunta que importa.

La salida no destructiva existía, pero se expresaba mal

IMAP4rev1 permitía seleccionar o examinar otro buzón, o enviar LOGOUT, sin ejecutar antes CLOSE. Esos caminos terminaban la selección actual sin expunge. El protocolo, por tanto, no imponía que toda salida borrase.

Faltaba una operación directa para liberar el buzón actual y permanecer autenticado sin seleccionar otro. RFC 3691 documentó dos rodeos. Un cliente podía intentar seleccionar un buzón inexistente y aprovechar el fallo para volver a Authenticated. También podía volver a seleccionar el mismo buzón con EXAMINE.

El primer método convierte una respuesta de error en flujo ordinario. Los registros mezclan intención y equivocación, las métricas de fallos pierden precisión y una implementación futura puede alterar un borde que parecía inútil. El segundo abre una vista de solo lectura para abandonar otra vista, aunque el cliente realmente no quiera mantener ninguna.

Ambos caminos explotaban consecuencias laterales de órdenes con otro propósito. Funcionaban, pero obligaban al receptor y al operador a deducir una intención que nunca aparecía en el cable.

UNSELECT convirtió esa intención en una instrucción legible: dejar de seleccionar, conservar la autenticación y no expurgar.

La capability acotó la compatibilidad

Los servidores IMAP4rev1 que comprendían la extensión anunciaban la capability UNSELECT. El cliente podía verificar el vocabulario antes de usarlo. Un rechazo por orden desconocida no equivalía a una salida segura: el servidor podía seguir en Selected y conservar sus recursos.

Esta negociación evitaba adivinar por versión, fabricante o comportamiento histórico. No autenticaba al usuario ni validaba los mensajes. Solo establecía que ambos extremos asignaban el mismo significado reducido a la orden.

UNSELECT no acepta argumentos ni necesita respuestas no etiquetadas específicas. Tras el éxito llega el resultado etiquetado. Su garantía no depende de una lista extensa; depende de que la definición excluye la retirada permanente.

En caso de perderse la respuesta, el cliente debe tratar el estado como incierto y recuperarlo. Pero la propia orden no repite una eliminación. La reducción de autoridad también reduce el radio de daño que puede producir un reintento tras una interrupción.

Conservar el punto de decisión no es prometer conservación eterna

UNSELECT no quita \Deleted, no recupera un mensaje ya expurgado y no identifica al actor que puso la marca. Si el buzón vuelve a seleccionarse, las marcas pueden seguir allí. Un EXPUNGE, un CLOSE posterior u otra operación autorizada puede hacerlas definitivas.

La orden preserva la decisión para otro momento; no decide que los mensajes deban existir para siempre. Tampoco bloquea sesiones concurrentes ni sustituye las reglas de autorización. Anunciar la capability demuestra semántica de protocolo, no la corrección de la interfaz humana, la existencia de copias o la integridad de los registros.

La precisión evita una falsa seguridad. La promesa es estrecha y comprobable: abandonar Selected mediante UNSELECT no ejecuta expunge por causa de esa orden.

IMAP4rev2 convirtió la corrección en lenguaje básico

RFC 9051 incorporó UNSELECT al conjunto principal de IMAP4rev2. Su modelo enumera CLOSE y UNSELECT como transiciones a Authenticated. Las definiciones conservan la diferencia de datos: CLOSE elimina todos los mensajes marcados en un buzón escribible; UNSELECT no elimina ninguno.

El paso de extensión a protocolo base muestra una reparación compatible. Los atajos anteriores no se borraron de la historia, pero la intención común dejó de depender de un fallo fabricado o una selección artificial. El código puede mostrar qué decisión toma y la observación puede conservarla.

El patrón aparece en muchos sistemas. Cerrar después de commit y cerrar después de rollback dejan igual la conexión, no los datos. Liberar un archivo tras escribir el búfer o tras descartarlo deja igual el descriptor, no el contenido. Medir solo el estado final confunde operaciones con consecuencias opuestas.

UNSELECT hizo explícito un principio de mínimo mandato. La solicitud de liberar recursos ya no concedía por accidente la potestad de eliminar. Para cruzar el borde irreversible, el cliente tenía que escoger una orden que lo dijera.

Perder la confirmación dejaba riesgos distintos

La conexión puede romperse después de que el servidor reciba la orden y antes de que el cliente vea el resultado etiquetado. Tras UNSELECT, la duda principal es si la selección sigue viva. Tras CLOSE, también puede existir una eliminación permanente ya ejecutada. Repetir el último método de forma automática no es neutral.

La recuperación debe reconectar, observar el buzón y comparar los UID presentes con la evidencia anterior antes de reproducir una intención humana. Las bibliotecas también deben exponer la diferencia: una función genérica de cierre no debería ocultar un commit de borrado en un destructor o bloque de limpieza.

Un OK no aporta por sí solo un inventario. La ventaja de verbos separados es que la clase de efecto se conoce antes de enviar la orden, cuando aún puede revisarse, y no se deduce después de una respuesta mínima.

Fuentes