Resumen

  • RFC 3028 definió un lenguaje restringido para decidir el destino del correo y añadió una conservación implícita cuando ninguna acción de entrega anulaba esa protección.
  • Las acciones keep, fileinto, redirect, discard y rechazo expresaban intención en el intérprete; no demostraban por sí solas escritura duradera, aceptación remota ni resultado definitivo.

El filtrado de correo parecía una tarea sencilla hasta que se trasladaba al servidor. Clasificar por remitente o asunto exigía leer el mensaje y producir efectos en el mismo lugar donde se hacía la entrega. Dar al usuario un lenguaje de propósito general habría puesto bucles, procesos externos y consumo de recursos junto a una función crítica compartida.

Sieve resolvió el problema reduciendo posibilidades. La especificación de 2001 carecía de bucles, funciones y acceso a programas externos. Sus pruebas no podían tener efectos secundarios. Los controles elegían bloques. Las acciones concentraban los cambios. La limitación no era una carencia accidental: permitía alojar reglas de usuarios sin concederles un sistema de ejecución abierto.

Una omisión activaba protección, no pérdida

Las reglas nunca conocen todos los casos futuros. Cambian las cabeceras, aparecen remitentes nuevos y una condición bien intencionada queda incompleta. RFC 3028 introdujo por ello la conservación implícita. Si el guion no ejecutaba una acción que la cancelara, el sistema aplicaba el destino normal, por lo general el buzón principal.

No se trataba de crear siempre una copia adicional. keep, fileinto, redirect y discard cancelaban la conservación implícita. El conjunto de acciones tenía una semántica compartida. Una extensión posterior que modificara una cabecera o enviara una notificación debía declarar si mantenía o anulaba esa protección.

El caso de discard muestra la precisión del modelo. La acción cancelaba en silencio el destino predeterminado, pero no borraba otros efectos compatibles. fileinto junto con discard seguía archivando el mensaje en la carpeta indicada; simplemente no añadía otra copia en el buzón principal. El nombre era dramático, la operación normativa era acotada.

Los verbos terminaban antes que sus consecuencias

keep pedía el comportamiento normal del entorno. El autor no necesitaba saber cómo se llamaba o implementaba el buzón principal. Esa independencia hacía portable la regla, pero impedía confundir la selección del comando con una transacción de almacenamiento confirmada.

fileinto elegía una carpeta. La propia especificación reconocía que algunos entornos no podían ofrecer esa acción. La cadena con el nombre de la carpeta no acreditaba su existencia, permisos o escritura.

redirect modificaba el destinatario del sobre y reenviaba como lo haría un MTA. Después de la decisión local comenzaba otra conversación de transporte. El destino podía rechazar el mensaje, aplicar su propia política o aceptarlo sin asegurar la experiencia final del usuario. La detección de bucles también quedaba en manos de la implementación.

discard debía ser silencioso. La ausencia de una notificación era parte del comportamiento, no una confirmación legible por el remitente. Para auditar la decisión sin conservar indefinidamente el contenido, el operador necesitaba evidencias separadas y con retención proporcionada.

La interacción de acciones limitaba contradicciones

Cuando varias condiciones podían activar varias acciones, el significado residía en la combinación. RFC 3028 obligó a las extensiones a declarar su relación con las acciones básicas. La política del sitio podía limitar cantidades y asociaciones. Además, pedir dos veces la misma escritura en un buzón no debía provocar dos entregas.

Estas reglas frenaban efectos de amplificación. Redirecciones múltiples podían crear una bomba de correo. Rechazar y entregar a la vez podía comunicar al remitente lo contrario de lo ocurrido. Ejecutar cada verbo como si fuera independiente destruiría la coherencia de la decisión.

RFC 5228 sustituyó a RFC 3028 y aclaró errores, límites e interacción sin abandonar la conservación implícita. RFC 9122 creó después un registro IANA de acciones Sieve con campos para sus interacciones y para indicar si cancelan esa conservación. El registro dice cómo deben componerse los contratos, no qué sucedió con un mensaje concreto.

El rechazo mostró el peligro de aceptar primero

La extensión reject de RFC 3028 descartaba el mensaje y enviaba una notificación de disposición al remitente del sobre. El sistema podía haber aceptado ya el correo. Si el remitente estaba falsificado, la notificación recaía sobre un tercero y contribuía al correo reflejado.

RFC 5429 añadió ereject, que prefiere rechazar durante SMTP o LMTP cuando el componente puede hacerlo. También declaró que el rechazo cancela la conservación implícita, prohibió ejecutar más de uno y desaconsejó combinarlo con entrega. La razón era probatoria: no era aceptable decir «no se entregó» mientras se guardaba o reenviaba el mismo mensaje.

Así, “rechazado” podía significar que la regla eligió el rechazo, que el componente consiguió negarse durante el protocolo o que generó una señal posterior. El remitente podía ver una respuesta inmediata, un informe tardío o nada. Un único estado no distinguía esas realidades.

ManageSieve, definido en RFC 5804, trató otro plano: subir, comprobar, enumerar y activar guiones. Que un guion esté activo no prueba que haya evaluado un mensaje; que lo evalúe no prueba el resultado de cada acción. Administración, decisión y consecuencia pertenecen a registros distintos.

Fuentes

Lu Heng no redactó ni respaldó RFC 3028, RFC 5228 o RFC 5429. Sus ensayos se usan aquí como perspectivas analíticas expresamente declaradas.