Resumen

  • RESERVE hacía que el nombre del buzón dejara de estar disponible para otras reclamaciones, pero RFC 3656 aclaraba que eso no significaba que el buzón estuviera listo para los clientes.
  • El estado MAILBOX indicaba disponibilidad tras la creación local y ACTIVATE. La secuencia se recomendaba, pero dependía de participantes cooperativos y no era una condición obligatoria del servidor.

Primero el nombre; después el buzón

Un conjunto de servidores de correo debe responder dos preguntas distintas: ¿qué servidor tiene este nombre y se puede acceder al buzón ahora? RFC 3656, publicado como protocolo experimental en diciembre de 2003, mantuvo separadas ambas respuestas. MUPDATE buscaba dar a servidores IMAP y POP3 un espacio de nombres común mientras varias máquinas compartían la responsabilidad de entrega.

La creación típica comenzaba con RESERVE. El cliente pedía al maestro que retuviera un nombre de buzón en una ubicación concreta. Tras recibir OK, hacía el trabajo de creación local y enviaba ACTIVATE con nombre, ubicación y ACL. La activación satisfactoria convertía el registro en activo. La ubicación podía dirigir al cliente al servidor que almacenaba la caja; la ACL describía los permisos de acceso.

Las respuestas muestran la diferencia. RESERVE quiere decir que otro reclamante ya no puede tomar el nombre, pero RFC 3656 dice expresamente que el buzón no tiene por qué estar disponible para clientes en ese momento. MAILBOX sí describe un registro listo para acceso. Tratar ambos mensajes como sinónimos convertiría un bloqueo del espacio de nombres en una señal falsa de disponibilidad: quizá el objeto local aún no existe o la creación no ha terminado.

La atomicidad era una disciplina compartida

MUPDATE describe un único maestro con la base autoritativa y servidores esclavos que la replican. Los clientes podían buscar en cualquiera; los cambios de base se dirigían al maestro. Crear un buzón cruzaba, por tanto, dos superficies: el registro distribuido de nombres y el almacenamiento local. El protocolo las coordinaba, pero no las convertía en una sola transacción atómica.

El lenguaje normativo deja clara esa limitación. Los buzones nuevos SHOULD reservarse antes de activarse, porque el diseño presupone que los participantes autenticados cooperan para conservar operaciones atómicas. Sin embargo, ACTIVATE no exige una reserva previa. La especificación permite ese comportamiento para facilitar la sincronización con la ubicación real. Quien omita la convención de bloqueo puede contribuir a una base inconsistente. La base no puede deducir una transacción local que nadie le comunicó.

DEACTIVATE devolvía el nombre activo al estado reservado; no equivalía a eliminarlo del espacio de nombres. El RFC también advertía que la información ACL conocida podía perderse durante ese cambio. En una migración o creación interrumpida, el nombre puede seguir reclamado aunque no se anuncie un buzón activo. La ubicación registrada tampoco prueba que un usuario iniciara sesión o leyera correo.

El OK de una réplica tenía un límite

Tras UPDATE, el esclavo recibía primero una lista inicial y luego los cambios posteriores. El maestro debía enviar una actualización dentro de los 30 segundos desde que ocurría en su base. El esclavo podía mandar NOOP; después de UPDATE, la respuesta OK debía esperar a que se hubieran enviado todas las actualizaciones pendientes en el momento de ese NOOP. Era un punto de sincronización acotado, no una promesa de que la base siguiera globalmente al día después de responder.

Es una confirmación útil pero estrecha: indica qué flujo pendiente llegó a esa réplica en un instante. No prueba que haya llegado un cambio posterior, que el buzón local esté sano ni que un usuario lo haya abierto. RFC 3656 es experimental: documenta un contrato propuesto, no el despliegue actual ni una medida de disponibilidad.

Fuentes