Resumen

  • RFC 2449 incorporó CAPA a POP3 para descubrir extensiones y comportamientos de forma estructurada, sin depender solo de probar comandos o interpretar errores en lenguaje natural.
  • La lista estaba limitada por el estado de la sesión: no era permiso ni confirmación de éxito, y podía cambiar con la autenticación, la política por usuario y la protección de integridad.

«¿Qué sabe hacer este servidor?» parece una pregunta singular. POP3 ya la había convertido en varias. Los comandos opcionales, los métodos de autenticación y ciertas conductas diferían entre servidores; sin embargo, los clientes solían descubrirlo probando comandos, leyendo errores pensados para personas o pidiendo al usuario que activara opciones de compatibilidad. Publicado en noviembre de 1998 como actualización de RFC 1939 en el Standards Track, RFC 2449 añadió CAPA: un inventario legible por máquinas antes de escoger una extensión.

El inventario no se transformó en una ficha permanente del servidor. CAPA estaba disponible en AUTHORIZATION, antes del inicio de sesión, y en TRANSACTION, después de autenticar. El RFC exigía que cada definición indicara en qué estados se anunciaba la capacidad y en cuáles eran válidos sus comandos. Una capacidad disponible antes de autenticarse debía anunciarse en ambos estados; aun así, sus argumentos podían precisar más después de conocer al usuario. La etiqueta, su valor y la acción que habilitaba eran datos relacionados, no equivalentes.

Dos políticas muestran por qué. Si LOGIN-DELAY variaba entre cuentas, el servidor debía anunciar antes de la autenticación el mayor intervalo posible y, después, debía ofrecer al usuario autenticado un valor más exacto. EXPIRE describía un periodo mínimo de conservación garantizado, no la fecha en que desaparecería un mensaje concreto. Si la política variaba por usuario, el valor previo al acceso debía ser el menor posible; tras el inicio de sesión el servidor debía proporcionar uno más preciso. La primera respuesta era conservadora porque el servidor todavía ignoraba qué política correspondía.

La autenticación también podía cambiar el contexto de seguridad. RFC 2449 recomendaba repetir CAPA si se negociaba una capa de integridad, para detectar una posible degradación activa. Más tarde, RFC 5034 delimitó claramente el caso de las capas de seguridad SASL: el cliente debía descartar la información aprendida anteriormente del servidor, incluida la lista antigua. Lo recibido fuera del contexto protegido no se convertía automáticamente en evidencia dentro de él.

Una lista positiva tampoco garantizaba que cada usuario pudiera ejecutar cada acción. La capacidad USER anunciaba que USER y PASS estaban implementados, aunque RFC 2449 advertía que quizá no estuvieran disponibles para todos. Un mecanismo SASL anunciado podía fallar por las credenciales o la política local; un acceso autenticado aún podía no obtener el buzón. Si CAPA respondía -ERR, el servidor no implementaba el mecanismo de consulta y el cliente debía volver a probar como antes. La nueva vía reducía las conjeturas, no borraba la incertidumbre heredada.

RFC 2449 también introdujo códigos de respuesta estructurados para que el software no tuviera que deducir cada fallo del texto libre. Los códigos desconocidos debían ignorarse, de modo que la capa común sobreviviera a la evolución de las extensiones. El documento advertía que la lista podía revelar mecanismos de autenticación, aunque su detección automática también ayudase al cliente a elegir uno más fuerte. La información legible tiene valor operativo y un coste de divulgación.

La aportación no fue prometer que los servidores POP3 serían intercambiables ni que desaparecerían las pruebas. Fue delimitar qué podía afirmar el servidor, en qué estado y bajo las reglas de cada extensión. Una lista orienta la siguiente decisión; solo el siguiente comando, su respuesta y una observación posterior del buzón permiten saber qué ocurrió. El estado del RFC y un registro de IANA no prueban implementación o despliegue universal.

Fuentes

RFC 2449; registro de RFC 2449; erratas de RFC 2449; RFC 1939; RFC 1957; RFC 5034; RFC 1734; RFC 4422; registro IANA de extensiones POP3; RFC 2384; Heng Lu, primacía del código en ejecución; Heng Lu, especificación inicial mínima y adopción voluntaria.