Summary

  • RFC 5235 traduce controles de spam y virus específicos de cada implementación a valores comparables, pero el cero porcentual reúne los estados limpio, no analizado e indeterminado.
  • La organización debe conservar una prueba independiente de que el control se ejecutó, además de separar resultado, rama Sieve, acción seleccionada y efecto final.

El número común oculta caminos distintos

Pensemos en dos mensajes. El primero atraviesa un motor actualizado y no activa ninguna señal. El segundo llega cuando el análisis está deshabilitado. Ambos pueden presentar spamtest :percent igual a cero. Un tercer mensaje puede compartir el valor porque Sieve no sabe si la comprobación se realizó.

La especificación no intenta fingir que esas historias son equivalentes. Su propósito es permitir que un guion compare resultados procedentes de mecanismos locales distintos. Normalizar resuelve una incompatibilidad de vocabularios; no certifica la actividad que hubo antes del dato.

El riesgo aparece cuando el sistema de gobierno conserva el resultado y descarta la procedencia. Entonces «sin prueba» se vuelve indistinguible de «probado como limpio».

La portabilidad elimina contexto de forma deliberada

RFC 5235 encarga a la implementación producir una cadena normalizada. Puede ofrecer texto propio del motor, pero depender de él rompe la portabilidad. El diseño acepta una pérdida de detalle para obtener una regla reutilizable.

Ese intercambio es razonable si se reconoce. El valor común no identifica necesariamente el escáner, su versión, la fecha del conjunto de reglas, las partes inspeccionadas, los adjuntos omitidos, los errores o la razón por la que no se ejecutó el control. Es un resultado proyectado, no el expediente de la prueba.

Una misma columna no debería hacer de interfaz de automatización y de registro de auditoría. La primera necesita estabilidad y pocas categorías. El segundo necesita excepciones, identidad y tiempo. Se pueden conservar ambos sin obligar al guion portátil a entender todos los motores.

El significado de cero depende de la escala

Sin :percent, spamtest usa una escala de cero a diez: cero significa no analizado o desconocido, y uno significa analizado y definitivamente limpio. En el modo porcentual, cero también incluye el caso analizado y limpio.

Guardar el dígito sin guardar la escala destruye una parte esencial de su semántica. Una migración entre modos puede cambiar la interpretación histórica aunque la pantalla siga mostrando el mismo carácter.

Para preguntar por ejecución, RFC 5235 permite usar la coincidencia relacional :count. Uno indica que la comprobación subyacente se hizo; cero indica que no se hizo o que Sieve no puede determinarlo. Ese dato evita confundir ejecución con resultado, pero no demuestra qué motor trabajó, si estaba actualizado o qué contenido vio.

Quien escribe el resultado influye en la decisión

Algunas implementaciones transportan los resultados mediante cabeceras privadas. El apartado de seguridad exige que solo un proceso legítimo de análisis pueda crearlas y que remitentes o intermediarios no puedan falsificarlas.

La razón es operacional: el campo gobierna una rama. Su escritor posee capacidad de decisión. Autenticar el canal protege esa autoridad, aunque todavía no garantiza la calidad del análisis. El propio RFC recomienda mantener actualizados los escáneres y reconoce que la detección de virus no es infalible.

Una salida auténtica de reglas antiguas sigue siendo auténtica y antigua. La integridad del transporte no sustituye la aptitud del proceso.

Cuatro superficies, no un único éxito

El valor normalizado describe la interfaz del control. La comparación decide una rama Sieve. El guion elige una acción. El sistema intenta ejecutarla y, más tarde, puede existir evidencia de almacenamiento, transferencia, rechazo o experiencia del destinatario.

«Cero» no prueba que se analizara. «La regla coincidió» no prueba que la acción terminara. «El mensaje se archivó» no prueba que una persona estuviera protegida. Un indicador verde que absorbe todas estas afirmaciones es cómodo y difícil de auditar.

La tesis específica de RFC 5235 está al principio de esa cadena: convertir evidencia local en un valor portable puede perder la distinción entre un hallazgo limpio y la ausencia del examen.

Límites de la evidencia

Las fuentes no describen un proveedor actual, un despliegue, una campaña, un incidente ni tasas reales de error. El registro de IANA prueba que las extensiones existen en el registro, no que estén ampliamente implantadas. Tampoco todo cero exige bloquear un mensaje: una política de bajo impacto puede aceptar el estado desconocido.

Lo que no debe hacer es llamar a esa aceptación «prueba de limpieza». La escala de virustest, que diferencia desconocido, limpio, neutralizado, posible infección e infección definida, sigue dependiendo de un proceso cuya frescura y cobertura viven fuera del número.

Un expediente enlazado en lugar de una cifra absoluta

Conserve un recibo del resultado con extensión, escala, valor, comparación, rama y versión del guion. Enlace otro recibo de ejecución con estado realizado/no realizado, identidad del motor, reglas, actualización, representación inspeccionada, exclusiones, errores y canal de confianza.

Registre por separado la acción y el desenlace. Mantenga visibles los estados no analizado, desconocido, expirado y parcial. Forzarlos a «limpio» para llenar un campo numérico impide explicar después por qué se tomó la decisión.

La doctrina de Lu Heng exige realidad operativa y un principal atribuible. El estándar define la interfaz; no asume la responsabilidad. Una persona concreta debe decidir cuándo la ambigüedad es tolerable y cuándo hace falta probar que alguien miró.

Sources

Registro normativo adicional

  1. Texto de RFC 5235
  2. Ficha informativa de RFC 5235
  3. RFC 5235 en Datatracker
  4. Historial de RFC 5235
  5. Erratas de RFC 5235
  6. Referencias a RFC 5235