Resumen

  • DELE marca un mensaje durante TRANSACTION, bajo un bloqueo exclusivo; no lo quita del buzón. RSET deshace todas las marcas antes de la salida normal.
  • Solo QUIT enviado desde TRANSACTION abre UPDATE. Una interrupción anormal debe conservar todos los mensajes, aunque una avería dentro de UPDATE puede dejar un resultado parcial.

La caída de la línea no podía hablar por el usuario

En la época de las conexiones breves, descargar correo era también trasladar custodia. El ordenador pedía un mensaje, recibía sus octetos y quizá ordenaba borrar el original. Si la línea telefónica se cortaba antes de escribir el archivo local, un borrado inmediato convertía el mismo fallo en pérdida en ambos extremos.

POP3 colocó una pausa entre intención y efecto. DELE hacía que el mensaje pareciera eliminado dentro de la sesión: otras órdenes ya no podían usar su número. Sin embargo, los datos seguían en el maildrop. RSET retiraba las marcas. Únicamente QUIT desde el estado de trabajo permitía pasar a UPDATE y comenzar la eliminación real.

No era una ceremonia de buena educación. Era el único punto común en el que cliente y servidor podían reconocer que la conversación había llegado a su final previsto. El silencio de TCP, por sí solo, no adquiría autoridad destructiva.

El acuse de recibo fue anterior a POP3

RFC 918, de octubre de 1984, distinguía RETR de RDEL. En el segundo caso, el cliente recibía el correo y enviaba después RCVD; recién entonces se intentaba eliminar. RSET abortaba la transacción y exigía cerrar y desbloquear correctamente el buzón.

POP2, descrito por RFC 937 en 1985, usaba ACKD: el cliente confirmaba la recepción y el servidor marcaba el mensaje. El cambio físico se aplazaba hasta liberar el buzón al terminar la sesión o escoger otro.

La gramática cambió, pero la intuición sobrevivió. Entregar bytes no equivale a saber que la otra máquina posee una copia durable. En una red intermitente, ese intervalo merece formar parte del protocolo, no quedar escondido en cada implementación.

POP3 convirtió la intuición en una máquina de estados

RFC 1081, la primera especificación POP3 de 1988, separó AUTHORIZATION, TRANSACTION y UPDATE. Tras autenticar al usuario, el servidor tomaba un bloqueo exclusivo sobre el maildrop. Durante TRANSACTION se enumeraban, recuperaban y marcaban mensajes. QUIT llevaba a UPDATE, donde el servidor intentaba quitar los marcados, soltaba el bloqueo y cerraba la conexión.

Cada estado concentraba una clase de poder. AUTHORIZATION abría el acceso. TRANSACTION ofrecía una vista estable donde las decisiones seguían siendo reversibles. UPDATE ejecutaba el efecto irreversible. Por eso QUIT en AUTHORIZATION solo terminaba la sesión: no existía una transacción autenticada que actualizar.

Los números de mensaje pertenecían también a esa vista temporal. Marcar un número hacía que las órdenes posteriores recibieran error al referirse a él, aunque el mensaje continuase almacenado. El protocolo podía comportarse como si la decisión estuviera tomada sin fingir que ya se había cumplido.

RSET conservaba el derecho a cambiar de opinión

RSET no era una extensión opcional. Formaba parte del conjunto mínimo y desmarcaba todos los mensajes. Un cliente podía descubrir falta de espacio, fallar al procesar una pieza o aplicar una preferencia de conservación distinta antes de despedirse.

El bloqueo exclusivo protegía esa ventana. RFC 1725 aclaró que debía impedir, cuando fuese necesario, modificaciones o eliminaciones antes de UPDATE. Así, los números y las marcas no quedaban apuntando a un buzón que otro actor reorganizaba al mismo tiempo.

La analogía con una base de datos termina pronto. No había consenso distribuido, restauración universal tras un fallo ni deshacer después de UPDATE. Había una zona pequeña de decisiones revocables, diseñada para servidores sencillos.

La desconexión anormal prohibía entrar en UPDATE

RFC 1725 señaló expresamente que aclaraba el comportamiento de las conexiones rotas. Una sesión que termina por una causa distinta de QUIT no entra en UPDATE y no debe eliminar mensajes. El cierre automático por inactividad sigue la misma regla.

RFC 1939, STD 53 desde 1996, mantiene la obligación y explica su motivo operativo: después de una terminación anormal, el cliente quizá no recibió o almacenó bien el correo.

La norma no adivina el disco remoto. Es posible que todo haya llegado antes del corte, y un QUIT tampoco demuestra que exista una copia de respaldo. Escoge un indicador conservador que ambos extremos ven. Ante la duda, acepta la posibilidad de un duplicado futuro en lugar de arriesgar la desaparición de la única copia.

La salida era una compuerta, no una garantía atómica

Durante UPDATE, RFC 1939 ordena retirar todos los mensajes marcados. Pero si faltan recursos o aparece otro error, pueden borrarse algunos, todos o ninguno. Jamás se puede tocar uno no marcado. Después, con éxito o fracaso, el servidor libera el bloqueo y cierra TCP.

Por tanto, QUIT se parece a un commit solo como frontera de autorización. No promete todo o nada. Si además se pierde la respuesta final, el cliente no puede saber qué subconjunto cambió. La especificación reconoce esa ambigüedad en lugar de atribuir a todos los almacenamientos una atomicidad inexistente.

Esta precisión cambia la lectura de +OK tras DELE: significa que la marca fue aceptada. El resultado físico pertenece a otra fase y puede ser parcial.

La política de retención siguió obedeciendo la frontera

Cuando dejar mensajes en el servidor se volvió habitual, RFC 2449 introdujo EXPIRE. EXPIRE NEVER anuncia que la política no elimina; EXPIRE 0 permite considerar implícitamente marcados los mensajes recuperados con éxito, pero al entrar en UPDATE.

La extensión cambia la política que produce marcas sin convertir cada RETR en destrucción instantánea. Una conexión rota continúa sin ser una despedida. Ese es el beneficio de una máquina de estados pequeña: la función nueva encuentra un límite existente al que someterse.

La despedida protegía la custodia, no el protocolo social

El cliente decide cuándo su secuencia de recuperación está lista para producir efectos; el servidor decide qué eliminaciones logra el almacenamiento. La red puede impedir ambos pasos, pero no puede suplantar el primero. Así, POP3 puso el coste de la incertidumbre del lado recuperable: duplicados y reconciliación, no pérdida silenciosa.

Marcar, poder reiniciar, cruzar explícitamente, intentar quitar y admitir un resultado parcial: esa es la arquitectura. La eliminación se volvía real al decir adiós, aunque el protocolo nunca afirmó que toda realidad posterior cambiase de una sola vez.

Fuentes y límites

La genealogía procede de RFC 918 y RFC 937. RFC 1081 define el primer POP3; RFC 1225 y RFC 1460 conservan el mecanismo. RFC 1725 aclara la ruptura, RFC 1939 fija la conducta actual y el fallo parcial, y RFC 2449 aporta EXPIRE. No prueban cuota de despliegue, comportamiento de productos concretos, ni borrado atómico o exactamente una vez.