Resumen

  • RFC 5232 permite que Sieve construya y compruebe un conjunto de marcas para el mensaje que está procesando y lo adjunte a la copia entregada mediante keep o fileinto.
  • Esa petición no es una edición general del almacén IMAP: las marcas que el buzón no pueda conservar de forma permanente deben ignorarse sin convertirlo en un error de ejecución del script.

La marca viajaba con la decisión de entrega

Un mensaje entrante recorre varias capas: el filtro lo analiza, decide un destino y el sistema acaba guardando una copia. Una marca IMAP pertenece al estado asociado a un mensaje almacenado. Publicada en enero de 2008, RFC 5232 conectó ese estado con Sieve, pero no borró la diferencia entre decidir qué hacer con el mensaje actual y reescribir un buzón entero.

La extensión imap4flags exige cuatro acciones o pruebas —setflag, addflag, removeflag y hasflag— además de un argumento :flags para keep y fileinto. Las tres primeras modifican conjuntos; la última prueba si determinados nombres están presentes. El argumento de entrega acompaña a la copia del mensaje que se está clasificando.

Ese conjunto vive dentro de una ejecución del script. Empieza vacío. setflag lo sustituye, addflag incorpora elementos y removeflag los retira. hasflag puede comprobarlo. Si el motor también admite la extensión Variables, el script puede mantener varios conjuntos con nombre; de lo contrario, indicar un nombre explícito produce un error. Las marcas se comparan sin distinguir mayúsculas, y el script no debe depender de que se conserve su orden, escritura exacta o duplicados.

La entrega es el punto de enlace. Si keep o fileinto incluye :flags, esa lista se usa para la copia guardada. Si no, se utiliza el valor de la variable interna. El mismo valor se aplica al keep implícito, la disposición predeterminada cuando ninguna acción explícita de entrega la ha sustituido. Una rama puede añadir una marca que la acción posterior arrastra, o la acción puede especificar otra lista al depositar el mensaje.

Pero RFC 5232 solo abarca el mensaje que se procesa en esa ejecución Sieve. No autoriza al script a seleccionar otro mensaje del buzón y cambiarle sus marcas. Tampoco afecta a un mensaje distinto creado como efecto secundario de otra acción. Es un punto de enganche en la entrega, no una API para modificar cualquier estado de IMAP.

El buzón de destino añade otro límite. :flags expresa qué marcas deben acompañar a la copia; no garantiza que todo almacén pueda conservarlas de forma permanente. El intérprete debe ignorar las que no pueda guardar y no debe convertirlo en un fallo de ejecución de Sieve. El ejemplo de la RFC indica que fileinto :flags "\\Deleted" equivale a fileinto si ese buzón no admite la marca. En IMAP, \\Deleted señala que el mensaje queda pendiente de una expurgación posterior; no acredita su borrado físico.

Por eso, decir «la regla puso la marca» puede condensar hechos distintos. Quizá se evaluó una rama; quizá el intérprete produjo una lista; quizá la acción solicitó esos elementos; el buzón pudo guardar solo algunos de forma permanente y un cliente pudo mostrar después ese estado. Ninguna observación sustituye a las demás. RFC 5232 tampoco impone una arquitectura: el intérprete puede conectarse al servidor como cliente IMAP o acceder directamente al almacén. El modo de acceso varía, pero la extensión sigue limitada al mensaje actual.

Hay además una regla para acciones de entrega que convergen. Si la eliminación de duplicados combina varios keep o fileinto, debe prevalecer el último valor de marcas. La copia que queda no tiene por qué reunir todas las intenciones previas de las ramas. Hay que revisar el orden y el mecanismo real de entrega; no se puede deducir el estado final contando cada addflag del script.

RFC 5232 comparte familia con el lenguaje Sieve base de RFC 5228, las variables de RFC 5229 y las comparaciones relacionales de RFC 5231. Esas normas explican cómo procesar instrucciones y valores, pero no desplazan esta frontera de entrega. Más adelante, RFC 9051 distinguió marcas permanentes de las limitadas a la sesión y declaró obsoleta \\Recent; una marca solicitada no equivale sin más a un estado duradero. La norma define un contrato técnico: no prueba que un servidor concreto lo implementara, que el mensaje llegara al lector ni que la interfaz mostrara un distintivo.

Fuentes