Resumen

  • Si Sieve encuentra un buzón con el uso especial solicitado, ese destino tiene prioridad. El nombre por defecto entra en juego cuando no hay una coincidencia o el atributo es desconocido para la implementación.
  • Un fallo de entrega ajeno a la existencia del buzón elegido no permite intentarlo después en la carpeta por defecto. El objetivo es impedir que los errores intermitentes repartan el correo entre ubicaciones inesperadas.
  • Las asignaciones de usos, la selección entre varias coincidencias y la inicialización del servicio forman parte del comportamiento del filtro, aunque su texto permanezca intacto.

El indicador podía mejorar mientras empeoraba el servicio

Pensemos en una operación de correo cuya prioridad inmediata es reducir entregas fallidas. El buzón destinado al archivo ha alcanzado su cuota. Una carpeta ordinaria sigue admitiendo mensajes y su nombre figura en la misma regla de filtrado. Guardar allí parece una solución eficaz: no queda un error pendiente y el mensaje no se pierde por falta de espacio en el destino previsto.

Este supuesto es ilustrativo; no describe un incidente observado. Su interés está en que el éxito de la última escritura oculta una decisión anterior: alguien ha cambiado dónde debe aparecer el mensaje. Si el usuario y los demás clientes siguen consultando el archivo designado, guardar en otro sitio no reproduce el servicio original.

RFC 8579 establece una frontera expresa para esta situación. Cuando falla la entrega al buzón de uso especial por motivos que no tienen que ver con su existencia, el intérprete Sieve no debe probar después el buzón indicado por defecto. Continúa el tratamiento ordinario del fallo de la acción; la extensión no prescribe aquí una única respuesta universal de cola, devolución o descarte.

La prohibición puede parecer contraria a la disponibilidad. En realidad, impide que una solución para una búsqueda sin resultado se convierta, sin otra decisión, en una política general de redistribución.

El nombre que quedaba en segundo lugar

Un filtro tradicional puede archivar mensajes indicando un nombre de buzón. El inconveniente aparece cuando la función sobrevive al nombre: otro cliente organiza la cuenta de forma distinta, el usuario cambia de idioma o decide trasladar su archivo a otra carpeta.

Los atributos de uso especial definidos en RFC 6154 permiten identificar funciones como \Archive, \Sent o \Junk. Una carpeta no tiene que llamarse literalmente Archive para desempeñar ese papel. Tampoco basta con ponerle ese nombre para demostrar que sea el archivo preferido por la cuenta.

Sieve aprovecha esa información mediante el argumento :specialuse de la acción de clasificación. Primero busca el atributo solicitado en el espacio de nombres personal del usuario. Si encuentra el buzón correspondiente, entrega allí en lugar de hacerlo en el nombre que acompaña a la acción.

Ese segundo nombre sigue siendo importante. Si no existe un buzón con el atributo, o la implementación no conoce ese atributo, la acción se comporta como si no se hubiera añadido la selección especial. El destino indicado por nombre recupera entonces su función ordinaria.

Por tanto, no hay dos candidatos de igual rango que el sistema pueda probar según la capacidad disponible. Hay una decisión de selección con un caso de reserva. Una vez encontrado el destino especial, un error posterior no equivale a volver al principio y declarar que la búsqueda había fracasado.

La diferencia exige describir con cuidado qué significa «no disponible». Una función no asignada, un buzón existente sin espacio y una operación que falla después de elegirlo no son hechos intercambiables.

La avería no debe convertirse en criterio de clasificación

La razón que da RFC 8579 es muy concreta: evitar que fallos transitorios o intermitentes distribuyan inesperadamente los mensajes entre dos buzones.

Imaginemos una secuencia de correspondencia. Las primeras entregas entran en el archivo. Cuando se agota la capacidad, otras van a la carpeta alternativa. Una intervención restablece el espacio y las siguientes vuelven al archivo. El momento de la avería ha determinado una partición de la conversación que nadie eligió como regla documental.

Que una búsqueda general encuentre las piezas no elimina el coste. Un proceso puede vigilar solo la ubicación designada. Otro cliente puede mostrar esa ubicación como archivo de referencia. Una persona puede interpretar la ausencia de un mensaje allí como ausencia de recepción.

Hay un argumento legítimo a favor de un funcionamiento degradado: a veces el usuario preferirá otra ubicación a una demora. Pero esa preferencia necesita una decisión explícita sobre el destino, la visibilidad y la recuperación posterior. El nombre por defecto no concede por sí mismo toda esa autoridad.

Mantener el error visible tampoco es una solución completa. El operador sigue teniendo que resolver la causa y explicar el resultado. La norma protege la coherencia del destino; no paga la ampliación de capacidad ni decide quién asumirá el trabajo pendiente.

Comprobar derechos no es reservar almacenamiento

La prueba specialuse_exists permite examinar si se cumplen determinadas condiciones para usar buzones con atributos especiales. Su resultado positivo puede ser útil sin constituir una promesa de entrega.

Si no se indica un buzón concreto, cada atributo solicitado debe estar presente en al menos un buzón del espacio personal que permita entregar en el contexto del usuario del script. Es posible que atributos diferentes se satisfagan en buzones diferentes. Cuando sí se da un nombre, ese buzón debe existir, permitir la entrega y reunir todos los atributos enumerados.

RFC 5490, al que remite esta definición, distingue la existencia y los permisos del éxito de una escritura posterior. Señala expresamente que una operación puede superar la cuota aunque la comprobación previa haya sido positiva.

La prueba no es una reserva para el tamaño de este mensaje. Tampoco congela las condiciones del sistema hasta que termine la entrega. «El usuario puede realizar esta clase de operación» y «esta operación quedó completada» pertenecen a momentos y evidencias distintos.

Un registro operativo debe conservar esa separación. Qué contexto de usuario se evaluó, qué atributos estaban asignados, qué buzón fue elegido y cuál fue el resultado real son datos diferentes. Convertirlos en un único estado verde hace más difícil diagnosticar precisamente el fallo que el filtro debe conservar.

El uso puede sobrevivir al script y cambiar su resultado

RFC 8579 permite que varios buzones personales compartan un atributo de uso especial. Si el buzón nombrado por defecto forma parte de ese conjunto, debe ser el elegido. El nombre explícito resuelve esa ambigüedad particular.

Si no pertenece al conjunto, la elección queda definida por la implementación. La norma recomienda mantenerla coherente mientras no cambien las asignaciones pertinentes, pero permite cambiar el destino cuando estas se modifican. No establece una ordenación universal que garantice el mismo resultado entre productos.

Esta posibilidad afecta a la continuidad durante una migración. Conservar el texto de los filtros y los nombres de los atributos no basta si el nuevo sistema selecciona otro miembro de un conjunto con varias coincidencias.

También cambia la investigación de incidentes. Una comparación de versiones que no detecte modificaciones en el script no descarta un cambio de ubicación: la regla puede estar leyendo un estado de asignaciones distinto. La historia de ese estado forma parte de la explicación.

El significado funcional tampoco debe exagerarse. En RFC 6154, el sentido concreto de un buzón Archive depende del servidor. El atributo no acredita un periodo de conservación, un almacenamiento inmutable ni una obligación jurídica. Es una pista normalizada sobre el uso de un lugar, no una certificación del régimen que una organización desea aplicar.

El trabajo de puesta en marcha tenía que hacerlo alguien

La interoperabilidad supone que exista una asignación para descubrir. Los atributos de RFC 6154 son opcionales. Poder crear un buzón con un uso específico requiere una capacidad separada, CREATE-SPECIAL-USE; permitir cambios por metadatos depende asimismo del servidor y de sus comprobaciones.

La entrada 4422 en las erratas de RFC 6154 recoge un caso ilustrativo de reparto fallido de responsabilidades. En una prueba informal de interoperabilidad del 19 de julio de 2015, un servidor esperaba que el cliente inicializara los usos, mientras un cliente esperaba que lo hiciera el servidor.

La entrada figura como Held for Document Update. Sus propuestas no deben presentarse como nuevas obligaciones ya incorporadas a la norma. Tampoco permiten atribuir el problema a un proveedor actual. La evidencia histórica es más limitada y más útil: ambos extremos pueden entender un mecanismo sin haber acordado quién establece su estado inicial.

Cuando no se encuentra ni el buzón especial ni el indicado por nombre, se aplican las reglas ordinarias para un destino inexistente. El argumento explícito :create solicita la creación necesaria del buzón por defecto. Si el servidor admite CREATE-SPECIAL-USE, RFC 8579 recomienda asignar el uso solicitado al buzón recién creado; no lo convierte en una garantía para todas las implementaciones.

Por eso, depositar correctamente por nombre puede ocultar que la selección por uso nunca llegó a funcionar. El resultado inmediato es válido, pero no demuestra que la configuración esperada esté terminada.

Un ámbito personal, no una búsqueda sin límites

Buscar el atributo en todo el almacén de correo parecería aumentar las probabilidades de encontrar un destino. También cambiaría quién puede influir sobre ese destino.

RFC 8579 limita la búsqueda por uso especial al espacio personal del usuario. Además de evitar una exploración innecesariamente costosa, busca impedir que los mensajes acaben de forma inesperada o maliciosa en buzones compartidos con el atributo correspondiente.

No es una garantía de que una carpeta personal jamás pueda compartirse. Tampoco impone automáticamente el mismo ámbito a todos los destinos por defecto expresamente nombrados. Es una restricción del mecanismo de descubrimiento por atributo.

RFC 6154 advierte por separado que algunas asignaciones pueden iniciar comportamientos automáticos y exponer correo privado en espacios compartidos. Quién asigna el uso y dónde se busca son decisiones que, combinadas, pueden controlar dónde termina una comunicación.

Lo que permiten afirmar las fuentes

No se han examinado cuentas, implantaciones de proveedores ni cifras de fallos. Esta es una lectura de mecanismos documentados. La errata técnica verificada 5877 de RFC 8579 corrige un operador de coincidencia en un ejemplo posterior; no modifica la regla de selección y fallo analizada aquí. No se han ejecutado los ejemplos del protocolo.

La reflexión de Lu Heng sobre el problema de agencia ayuda a preguntar quién soporta el coste de una decisión. El componente que logra guardar en otra carpeta puede mostrar una mejora, mientras quien necesita localizar el correo recibe un problema nuevo.

Su explicación del propósito de BTW pide describir estructuras antes que promover causas. En este caso, describir bien obliga a no confundir capacidad con permiso. El espacio libre puede ser real. La autoridad para cambiar el destino necesita otra justificación.