Resumen

  • En POP3, DELE aceptaba una intención destructiva sobre un número de la sesión, pero conservaba el mensaje y permitía que RSET quitara la marca.
  • Solo un QUIT enviado por el cliente desde TRANSACTION llevaba a UPDATE. Una desconexión anómala o el temporizador de inactividad cerraban sin borrar.
  • La frontera protegía una descarga interrumpida, aunque no ofrecía atomicidad: RFC 1939 admitió que UPDATE quitara algunos mensajes marcados y dejara otros.

La confirmación llegó antes que el efecto

El texto de una respuesta POP3 podía decir más de lo que el protocolo había hecho. Tras DELE 4, +OK message deleted parecía un recibo de eliminación. Desde RFC 1081, publicado en 1988, la semántica era más contenida.

El servidor autenticaba al cliente, abría el maildrop, obtenía el bloqueo de acceso necesario y entraba en TRANSACTION. Allí numeraba la vista actual. DELE señalaba una posición; después de la respuesta positiva, nuevas órdenes sobre ese número daban error. El objeto seguía en el maildrop y RSET podía retirar todas las marcas.

La respuesta, por tanto, demostraba que el servidor había incorporado una posición al conjunto pendiente de borrado. No demostraba que hubiera liberado almacenamiento ni que el mensaje hubiese desaparecido de copias, respaldos o una sesión futura. Aún faltaba una transición.

Una lista protegida no era una identidad permanente

El bloqueo exclusivo impedía que los mensajes se modificaran o retiraran antes de UPDATE. Esa protección hacía que LIST 4, RETR 4 y DELE 4 siguieran apuntando al mismo elemento mientras duraba la transacción.

Su alcance acababa con la sesión. En una conexión posterior, una lista distinta recibía números nuevos. El cuatro era un operando breve, no un nombre histórico. El bloqueo tampoco convertía al cliente en dueño de la política del buzón ni prometía que no pudiera llegar correo nuevo por el sistema de entrega.

La arquitectura repartía conocimientos. El cliente era quien podía saber si la copia descargada ya estaba escrita de forma durable. El servidor era quien podía retirar la entidad almacenada. POP3 no intentó convertir ambos sistemas en una sola transacción distribuida; permitió preparar la intención y reservó el efecto para una frontera de sesión.

RFC 1225 y RFC 1460 mantuvieron ese orden. La continuidad importa: marcar, poder deshacer, pasar a UPDATE, retirar, liberar el bloqueo, responder y cerrar.

Cortar el cable no equivalía a decir adiós

RFC 1725 hizo explícita en 1994 la regla de seguridad: si la sesión terminaba por cualquier motivo distinto de un QUIT emitido por el cliente, no entraba en UPDATE y el servidor no debía quitar mensajes. El autologout por inactividad también cerraba sin respuesta y sin borrado.

La razón no estaba en la cortesía del protocolo. Un cliente intermitente podía haber recibido el último octeto de RETR y todavía no haber confirmado la escritura local. La batería podía agotarse, el disco podía fallar o el proceso podía morir. Si el fin de TCP autorizara el borrado, la misma avería que ocultaba el estado de la copia destruiría el original recuperable.

Por eso POP3 exigía una acción positiva dentro de su gramática. Un EOF, un reset o diez minutos de silencio no eran sustitutos de QUIT.

Incluso el estado inicial modificaba el significado. QUIT en AUTHORIZATION solo cerraba. QUIT en TRANSACTION abría UPDATE porque ya existían una vista protegida y, quizá, marcas destructivas. La autoridad estaba en la combinación de verbo y estado, no en cuatro letras aisladas.

El límite de UPDATE no garantizaba todo o nada

RFC 1939 describió un desenlace que una lectura optimista habría ocultado. Al entrar en UPDATE, el servidor intenta eliminar los mensajes marcados. Una escasez de recursos puede hacer que se borren algunos o ninguno. La respuesta posible -ERR some deleted messages not removed reconoce el resultado parcial. Ningún mensaje sin marca puede ser eliminado.

El conjunto autorizado era preciso, pero la operación no era atómica. Si había tres marcas, podía sobrevivir una. Tanto después del éxito como del error, el servidor liberaba el bloqueo y cerraba la conexión.

Además, la respuesta final podía perderse. El servidor pudo retirar los mensajes y fallar al entregar el +OK; pudo fallar antes o completar solo una parte. El cliente que observa silencio no sabe cuál rama ocurrió. El cierre de transporte no lleva un código causal.

La recuperación empieza con una vista nueva. UIDL, cuando existe, puede ayudar a correlacionar las entidades supervivientes, pero una ausencia no explica quién la causó. Otro cliente o la política local también pudieron actuar. Repetir el número anterior sería peligroso porque la nueva posición 4 puede nombrar otro mensaje.

La política podía crear marcas implícitas

RFC 2449 añadió el mecanismo de capacidades y EXPIRE. EXPIRE 0 comunica que el sitio no permite dejar correo en el servidor. Cuando la sesión entra en UPDATE, este puede asumir un DELE implícito por cada mensaje recuperado mediante RETR.

La cláusula conserva la frontera. La descarga no borra en el acto; la política decide qué entidades entran en el conjunto pendiente cuando llegue UPDATE. Si la conexión termina de manera anómala, el servidor no obtiene por ello permiso para aplicar esas eliminaciones.

El registro de la IANA mantiene pop3 en el puerto 110. Es una constancia de coordinación, no una encuesta de despliegue ni una auditoría de conformidad.

La lección histórica no es que POP3 inventara un commit perfecto. Hizo algo más honesto: redujo la autoridad de cada señal. DELE +OK significaba marcado. QUIT pedía el intento irreversible. La respuesta final informaba lo observado por el servidor. Y, si esa respuesta faltaba, solo la reconciliación podía revelar el estado servido después.

Fuentes