Resumen

  • environment consulta información del intérprete, no del cuerpo del mensaje. Que el elemento exista o sea no vacío sólo describe la respuesta de esa implementación.
  • remote-host puede proceder de un PTR no fiable. Un nombre que coincide con una lista permitida no demuestra que la conexión pertenezca a esa organización.

La consola resumía tres estados con un mismo icono verde. Si remote-host estaba implementado, si devolvía una cadena vacía o si contenía un nombre con el sufijo esperado, el flujo terminaba en “contexto validado”. La interfaz había eliminado exactamente las diferencias que el protocolo conservaba.

El mensaje no causó un error. El intérprete tampoco incumplió el estándar. Cuando no pudo obtener un nombre remoto, entregó una cadena vacía. La política local fue la que confundió una consulta válida con una identidad confirmada.

Éste es un caso analítico, no un incidente atribuido. Su utilidad está en obligar a separar disponibilidad, población, procedencia y autoridad antes de que una condición Sieve pueda controlar cuarentena, rechazo o liberación.

La fuente está fuera del mensaje

RFC 5183 añade la capacidad environment. El script indica un nombre de elemento y una lista de claves. Puede elegir comparador y tipo de coincidencia; si no lo hace, se aplican :is e i;ascii-casemap.

El valor no se extrae directamente del mensaje actual. Lo aporta el entorno operativo del intérprete. Esa frase cambia el modelo de auditoría: hay que conocer qué proceso respondió, en qué punto del servicio, a partir de qué observación y bajo qué configuración.

Los elementos iniciales cubren varias capas. domain y host describen el contexto DNS y el host de ejecución. location clasifica el servicio como MTA, MDA, MUA o almacén de mensajes. phase sitúa la evaluación antes, durante o después de la entrega final. name y version identifican el producto. remote-host y remote-ip describen al cliente remoto de SMTP, LMTP o Submission cuando son aplicables.

La utilidad de la lista no depende de convertirla en certificado. Permite que un mismo script reconozca diferencias operativas. La aplicación que necesite una afirmación más fuerte debe construirla y demostrarla por separado.

Falso no siempre significa lo mismo

Si el elemento solicitado no existe, el test debe fallar sin abortar el script. Esta regla permite transportar políticas entre intérpretes con conjuntos de funciones distintos. La ausencia es una condición esperada, no un fallo de sintaxis.

Una prueba :contains con clave vacía sirve para saber si el elemento es conocido: cualquier cadena devuelta contiene la cadena vacía. Pero el método no dice que la cadena contenga información. remote-host devuelve precisamente una cadena vacía cuando el nombre no puede obtenerse.

La extensión relacional ofrece otro ángulo: :count produce cero si la información devuelta es vacía y uno si no lo es. No mide cuántas fuentes apoyan el dato, cuánto dura la caché ni cuánta confianza merece. Es cardinalidad del valor, no calidad de evidencia.

Una máquina de estados responsable conserva al menos: elemento inexistente, elemento existente con valor vacío, elemento existente con valor no vacío pero no verificado y valor aceptado por una política declarada. Un Booleano borra esas fronteras y hace imposible explicar el fallo.

El nombre remoto puede ser correcto y no tener autoridad

El propio RFC advierte que la implementación puede usar cualquier técnica para calcular remote-host. Una opción común es consultar el PTR de la dirección cliente. La fiabilidad varía y la fuente puede no ser confiable.

Quien controla la zona inversa puede publicar un nombre que apunte al dominio que elija. Por eso el documento rechaza una coincidencia *.example.com como prueba de que el mensaje proviene de dentro o fuera. La cadena puede estar bien formada, el DNS puede haber respondido y la comparación puede ser exacta; la conclusión organizativa sigue sin demostrarse.

El recibo necesario comienza antes de Sieve: dirección del par, protocolo y salto observado, consulta inversa, resolver, respuesta, antigüedad, estado de validación y política de confirmación directa. Después conserva el valor entregado al intérprete, la regla aplicada y la acción seleccionada.

remote-ip evita el paso nominal, pero tampoco identifica automáticamente a una persona o empresa. Un relay o servicio de envío puede ser el par inmediato de miles de remitentes. La arquitectura local debe decir qué identidad, si alguna, representa esa dirección.

Lugar y fase no son un comprobante de entrega

location=MTA informa que evalúa un agente de transferencia; MS señala un almacén. phase=post sitúa la ejecución después de la entrega final en el modelo. Ninguna etiqueta contiene el identificador de transacción, el hash del script cargado, el nodo de réplica ni la visibilidad final del usuario.

RFC 6785 extiende el patrón para eventos IMAP. Declara location=MS y phase=post, y añade imap.user, imap.email, imap.cause, imap.mailbox e imap.changedflags. El crecimiento del registro confirma que los nombres pueden describir contextos más precisos sin convertirlos en resultados.

imap.mailbox queda fijado al iniciar el script. Una acción posterior fileinto no lo modifica. El dato responde qué buzón estaba implicado al comienzo, no dónde terminó el mensaje. imap.changedflags puede enumerar flags cambiados, pero no especifica si se activaron o retiraron; hay que consultar el estado actual.

Una bitácora que registra sólo valores de entorno congela la entrada de la decisión. Para demostrar el efecto necesita seguir la acción hasta el sistema que confirmó el cambio.

Portabilidad no es equivalencia semántica

El registro IANA coordina nombres. Los elementos normalizados provienen de RFC de estándares o experimentales. Los nombres de proveedor empiezan por vnd. y se registran para evitar colisiones.

Ese diseño deja espacio a la innovación local. También obliga a reconocer sus límites. Un elemento vnd. desconocido en el nuevo intérprete no puede recibir automáticamente el significado del anterior. Un version de producto no es un digest de artefacto. Un host no identifica por sí solo el worker que tomó la decisión.

RFC 5463 permite preguntar por capacidades con ihave. La respuesta ayuda a seleccionar sintaxis disponible. No certifica que un elemento de entorno exista en esa invocación, que esté lleno o que sea confiable. ManageSieve, por su parte, administra scripts y anuncia capacidades; tampoco prueba el contexto runtime de un mensaje concreto.

Portar una política exige un contrato: qué nombres se esperan, quién los produce, qué valores son válidos, qué hacer ante ausencia, cómo se verifica la procedencia y cuál es el recibo de resultado. Sin él, la misma cadena puede ocultar dos operaciones distintas.

Reconstruir la decisión completa

Una política de consecuencias altas debe asignar un identificador inmutable a la decisión y retener el hash del script, el build del intérprete y las capacidades observadas. Para cada test almacena nombre, valor crudo, fuente, método de derivación, ubicación, fase, comparador y rama.

Después registra la acción Sieve y el resultado del componente que la ejecuta. Si el objetivo es un buzón, una entrega o un rechazo, añade el recibo del sistema responsable y la reconciliación con el estado visible. De este modo un resultado vacío puede ser una ausencia explicada, no una confianza ficticia.

El estándar mantiene pequeño el lenguaje común. La organización conserva la responsabilidad de no elevar un símbolo por encima de su fuente. La pregunta de cierre no es “¿existía el elemento?”, sino “¿qué hecho observó, quién estaba autorizado a afirmarlo y qué cambio verificamos después?”

Fuentes

  1. RFC 5183 — HTML
  2. RFC 5183 — texto plano
  3. Página informativa del RFC Editor
  4. Documento en IETF Datatracker
  5. Historial en IETF Datatracker
  6. Referencias en IETF Datatracker
  7. Erratas de RFC 5183
  8. RFC 5228 — especificación base de Sieve
  9. Página informativa de RFC 5228
  10. RFC 5231 — extensión relacional
  11. RFC 5598 — arquitectura del correo de Internet
  12. RFC 6785 — eventos IMAP en Sieve
  13. Página informativa de RFC 6785
  14. RFC 5804 — ManageSieve
  15. RFC 5463 — extensión Sieve ihave
  16. Registro IANA de extensiones Sieve
  17. Registro IANA de elementos de entorno Sieve
  18. Heng Lu — capas de realidad
  19. Heng Lu — especificación mínima y adopción voluntaria
  20. Heng Lu — primacía del código operativo