Resumen

  • Una ACL de buzón contiene pares de identificador y derechos. Un usuario puede coincidir con su nombre, varios grupos y anyone; cada fila es solo una entrada del cálculo.
  • GETACL devuelve reglas, LISTRIGHTS lo que el servidor permite conceder a un identificador y MYRIGHTS la respuesta efectiva para la sesión conectada.
  • DELETEACL elimina un par; un identificador de derechos negativos resta autoridad durante el cálculo. RFC 4314 aclaró la diferencia sin uniformar todos los sistemas de identidad.

La fila desapareció antes que la autoridad

Las pantallas de permisos convierten un sistema de decisiones en una cuadrícula. Se elimina un nombre, se guarda y aparece un mensaje de éxito. La revocación solo es real si esa fila era el único camino, si el motor que ejecuta el correo ya recalculó el resultado y si ninguna sesión conserva la decisión anterior.

Los buzones compartidos mostraban pronto el problema. Una cola de soporte podía pertenecer a un equipo. La misma persona recibía un derecho directo, otro por un grupo y quizá uno universal. La lista describía motivos de acceso; no era el derecho final.

RFC 1730 había convertido el buzón remoto en un objeto operable por red. El cliente elegía carpetas, leía mensajes, alteraba banderas y modificaba estado almacenado en el servidor. Cuando varios usuarios trabajaban sobre el mismo objeto, el control ya no podía quedar oculto en permisos locales que el cliente no veía.

En enero de 1997, el Standards Track RFC 2086 añadió la capacidad ACL. Una lista era un conjunto de pares <identificador,derechos> ligado a un buzón. El cliente podía consultar y editar ese conjunto sin recibir todo el directorio interno del servidor.

La sesión no llegaba con una sola identidad

anyone quedó reservado para la identidad universal, incluso para autenticaciones anónimas. Los nombres aceptados por LOGIN o AUTHENTICATE correspondían a usuarios. El resto podía significar grupos u otras categorías definidas por la implementación.

Por eso Fred podía coincidir a la vez con fred, equipo-soporte y anyone. El RFC no impuso una operación universal de combinación. Un servidor podía unir todos los derechos aplicables; otro podía escoger el identificador más específico. Ambas decisiones pertenecían al modelo local.

Una interfaz no podía deducir de las filas la pertenencia real a grupos, los derechos forzados del propietario ni la precedencia. La misma tabla aparente podía producir resultados diferentes en dos sistemas conformes.

IMAP no intentó centralizar esas identidades. Introdujo una pregunta al ejecutor. MYRIGHTS pedía al servidor el conjunto efectivo del usuario conectado sobre un buzón. El componente que decidiría la siguiente orden publicaba así su conclusión actual.

Tres comandos evitaban una sola ficción

GETACL mostraba los pares almacenados. Respondía qué reglas estaban declaradas, no cuáles se aplicaban al usuario ni cómo se combinaban.

LISTRIGHTS describía los derechos que podían concederse a un identificador. Si el sistema subyacente obligaba a conceder varias letras juntas, la respuesta expresaba los grupos inseparables. Era una consulta sobre la capacidad del modelo, no sobre el permiso actual.

MYRIGHTS devolvía el resultado después de resolver identidades y aplicar la política local. Era la observación más próxima a lo que el servidor permitiría a esa sesión.

La persistencia de una edición, el cálculo efectivo y la aceptación de una operación son hechos distintos. Ni siquiera la aceptación identifica a la persona que utilizó las credenciales. El protocolo acotaba la evidencia en vez de convertir una señal en todas las demás.

DELETEACL no significaba «niega todo»

DELETEACL buzón fred borraba el par de Fred. Si el grupo o anyone conservaban w, la orden cumplía su contrato y Fred seguía escribiendo.

RFC 2086 reservó los identificadores iniciados con guion para derechos negativos. RFC 4314 explicó la diferencia: una entrada -fred con w resta ese derecho a Fred aunque otra identidad coincidente se lo conceda. La entrada negativa forma parte de la evaluación; borrar una entrada solo quita una pieza.

Los servidores no estaban obligados a admitir identificadores negativos. Un cliente no podía fabricar un botón universal de “denegación prioritaria”. Debía descubrir la posibilidad y volver a consultar el efecto.

También había dos guiones con funciones diferentes. En el argumento de derechos de SETACL, -w elimina w del par seleccionado. En la posición del identificador, -fred crea la entrada que resta durante la combinación. Una sintaxis parecida no ampliaba el alcance de la primera operación.

Dividir el poder sin romper a los clientes antiguos

La versión de 1997 representó con letras la visibilidad, lectura, estado visto, otras banderas, inserción, publicación, creación, eliminación y administración. c y d resultaron ambiguas cuando implementaciones distintas intentaron separar borrar un mensaje, purgarlo y eliminar todo el buzón.

RFC 4314 sustituyó a RFC 2086 en diciembre de 2005. k pasó a controlar la creación de buzones hijos; x, la eliminación o traslado del buzón; t, la bandera de mensaje eliminado; e, la purga. c y d sobrevivieron como derechos virtuales de compatibilidad. El servidor moderno podía aplicar el detalle y ofrecer al cliente antiguo una proyección estable.

La nueva capacidad RIGHTS= anunciaba letras adicionales. Un servidor cuyo almacenamiento ataba varias operaciones podía conservarlas unidas y mostrar esa restricción mediante LISTRIGHTS. El estándar común no fingía que todas las arquitecturas locales tenían la misma granularidad.

Los editores recibieron otra obligación: conservar derechos desconocidos que no permitían editar. Si un cliente viejo leía una entrada moderna y guardaba solo las letras que entendía, podía quitar permisos silenciosamente. La compatibilidad exigía tratar la ignorancia con prudencia.

La autoridad también podía quedar almacenada en el tiempo

RFC 4314 permitió que el servidor guardara en caché los derechos al seleccionar un buzón. Una modificación con SETACL o DELETEACL podía no cambiar de inmediato las órdenes de una sesión ya seleccionada. El nuevo resultado aparecería al volver a seleccionar.

El servidor que revisaba cada orden podía actualizar banderas, negar operaciones o cerrar la conexión si desaparecía la lectura. No existía, sin embargo, una promesa de revocación simultánea para todas las sesiones. El estándar señalaba la frontera temporal que debía verificarse.

Dentro de una conexión sí protegía el orden: si llegaban en canalización SETACL y MYRIGHTS, la modificación debía terminar antes de calcular la respuesta. Esa secuencia no decía qué había almacenado otra conexión.

La propia ACL era información sensible

Una lista podía revelar que el buzón existía, qué cuentas y grupos había y quién administraba. RFC 2086 prohibió que una consulta sin permiso revelara un buzón restringido. RFC 4314 precisó que, sin derecho de visibilidad, la respuesta debía parecer la de un nombre inexistente.

Leer mensajes tampoco autorizaba automáticamente a ver los identificadores de la ACL. El mapa de autoridad era un dato protegido. Además, la extensión no ofrecía confidencialidad por sí sola: sin STARTTLS, privacidad negociada en la autenticación u otra capa, esos datos viajaban en claro.

Autorizar correctamente una consulta y cifrar su transporte seguían siendo responsabilidades separadas.

La especificación reconoció lo que no podía unificar

RFC 4314 enumeró deficiencias: la combinación de identidades seguía siendo propia de la implementación; usuarios, grupos y nombres especiales compartían espacio; una interfaz universal era difícil; no existía un equivalente completo a todas las operaciones de propiedad de un sistema de archivos.

Aun así, la revisión compatible merecía la pena porque RFC 2086 ya estaba desplegado en varias implementaciones. RFC 9051 definió después IMAP4rev2 y mantuvo en general las extensiones registradas de IMAP4rev1. Eso demuestra continuidad normativa, no que un servicio concreto implemente ACL o derechos negativos.

El legado no fue una autoridad central sobre el correo. Fue una separación verificable: la lista declarada, las modificaciones que el servidor sabe representar y el permiso efectivo que su código aplicará no son el mismo objeto.

Fuentes