Resumen

  • RFC 9661 trata como actos distintos la carga del contenido, la validación, el alta del objeto y la activación de un único script por cuenta.
  • isActive=true confirma el estado que el servidor devuelve al cliente; no certifica que todos los workers hayan cargado ese blob ni que el próximo correo reciba la acción esperada.
  • La prueba completa une hash del blob, capacidades, estado condicional, transición de activación, lectura por ambas interfaces, generación del worker, traza del mensaje y resultado final.

A la mañana siguiente del cambio, el panel dice que todo salió bien. El nuevo script pasó la validación, se creó y quedó activo. Sin embargo, un mensaje de prueba aparece en la carpeta que definía la versión anterior. La discusión suele plantearse mal: o la API mintió o el correo se perdió. Hay una tercera posibilidad, más común y más útil: ambas observaciones describen capas diferentes.

El RFC 9661 incorpora los scripts Sieve al modelo JMAP. Cada SieveScript tiene id, nombre, blobId e indicador isActive; solo uno puede estar activo en una cuenta. El estándar mejora mucho la custodia del estado. No prescribe cómo el servicio distribuye ese estado a los procesos que ejecutan Sieve durante la entrega final.

No convertir cuatro recibos en uno

Subir un blob acredita que el servidor recibió bytes. Validarlo con SieveScript/validate comprueba la gramática y las extensiones requeridas sin almacenarlo como script. El RFC 5228 separa errores detectables antes de ejecutar de fallos que solo aparecen en tiempo de ejecución. Una validación verde no es un ensayo con un mensaje real.

La escritura del objeto usa las reglas generales de JMAP. ifInState evita aplicar una modificación sobre una colección que cambió mientras el cliente trabajaba. Es una defensa contra carreras y sobrescrituras. No es un sello sobre el contenido compilado en un worker de entrega.

La activación añade otra garantía: onSuccessActivateScript solo cambia el activo si las operaciones solicitadas tuvieron éxito. El servidor debe informar el nuevo activo y el anterior desactivado. La transacción queda cerrada en la base de estado. A partir de ahí pueden existir réplicas, cachés compiladas, colas de invalidación o despliegues parciales que el protocolo no observa.

Dos interfaces no equivalen a todo el camino

RFC 9661 busca que JMAP y ManageSieve vean los mismos scripts. Por eso conviene releer por ambos caminos tras el cambio. Si el nombre activo o el contenido difieren, la inconsistencia es directa.

Si coinciden, todavía falta el motor. Dos interfaces pueden consultar la misma fuente mientras un grupo de entrega conserva una versión antigua en memoria. El registro operativo debe poder responder: ¿qué cuenta?, ¿qué id?, ¿qué hash?, ¿qué generación activa?, ¿qué worker?, ¿qué mensaje? y ¿qué acción resultó?

La última pregunta exige cautela. Encontrar el correo en una carpeta es una observación positiva. No encontrarlo no demuestra discard: también puede haber rechazo previo, demora, antispam, ruta incorrecta o error de almacenamiento. Un buen control inyecta mensajes con identificadores únicos por el ingreso real, conserva su aceptación y observa la decisión en la entrega final sin retener contenido innecesario.

La respuesta de vacaciones delimita la autoridad

El RFC 8621 define VacationResponse. Cuando el servidor la implementa mediante un script Sieve, RFC 9661 permite leer y activar ese script, pero prohíbe modificarlo o destruirlo con SieveScript/set. El cambio de contenido pertenece a VacationResponse/set.

Ese detalle no es ornamental. Impide que dos superficies legítimas escriban sobre el mismo objeto sin un dueño claro. La procedencia —editor, vacaciones, restauración, ManageSieve o automatización— debe acompañar al hash del blob. Activar el objeto correcto por el canal equivocado puede romper el proceso de autorización aunque la sintaxis sea impecable.

El RFC 9404 mejora la gestión de blobs; el RFC 9425 expone cuotas; el registro JMAP de IANA coordina nombres y errores. Ninguna de esas capas observa por sí misma el resultado de un mensaje.

La cadena mínima de evidencia

Para cada cambio, conservar el hash del blob, el resultado de validación, el conjunto de capacidades, el estado leído, la precondición ifInState, la respuesta de activación y la relectura JMAP–ManageSieve. En la plataforma de correo, registrar de forma acotada la generación cargada por worker. En una prueba, enlazar el identificador del mensaje con el worker, el script y la decisión.

También hay que conservar el fracaso: activar un id inexistente no debe alterar el activo; destruir el script activo debe devolver sieveIsActive; una regla válida con un fallo controlado debe producir una clase de error comprensible; un script de vacaciones debe rechazar la escritura desde la interfaz incorrecta. Estos ensayos convierten las normas en controles verificables.

La especificación inicial mínima de Heng Lu ofrece la proporción correcta: un núcleo común pequeño y auditable, libertad local dentro de él. Las capas de realidad impiden que «activo» se convierta por retórica en «ejecutado». La primacía del código en funcionamiento obliga a mirar donde la decisión modifica el correo.

RFC 9661 resuelve la administración del estado. La prueba de ejecución sigue siendo responsabilidad del operador.

Fuentes