Summary

  • RFC 5235 projette des contrôles antispam et antivirus propres à chaque système sur une échelle portable, mais la valeur zéro de spamtest :percent réunit « contrôlé et sain », « non contrôlé » et « statut indéterminé ».
  • Une décision importante doit donc conserver, à côté du score, la preuve que le contrôle a réellement été exécuté. Le résultat, la branche Sieve, l'action et l'effet observé ne sont pas le même fait.

Le paradoxe du zéro rassurant

Un responsable consulte un tableau de bord : le score est nul, la règle a laissé passer le message, aucune alerte n'est apparue. La chaîne semble avoir fonctionné. Mais le chiffre ne dit pas si un moteur à jour a inspecté le contenu ou si Sieve n'a simplement pas pu déterminer qu'un test avait eu lieu.

RFC 5235 inscrit cette ambiguïté dans la sémantique de son mode pourcentage. Le texte ne promet pas une attestation universelle de propreté. Il fournit une valeur normalisée que des scripts portables peuvent comparer malgré la diversité des contrôles sous-jacents.

La différence est décisive. Un langage commun facilite l'automatisation ; il ne recrée pas les informations que la normalisation a écartées.

La portabilité est une projection

Les moteurs antispam emploient leurs propres catégories, seuils et sorties. RFC 5235 demande à l'implémentation d'en produire une chaîne normalisée. Un texte propre à l'implémentation peut être exposé, mais le document avertit qu'un script qui en dépend n'est plus portable.

Le compromis est utile : une politique Sieve peut voyager sans connaître le vocabulaire de chaque moteur. Cependant, le score commun ne contient pas nécessairement le nom du scanner, sa version, la date des règles, le profil appliqué, les parties du message inspectées, les pièces exclues, les erreurs ni la cause d'une absence de contrôle.

Il faut donc résister à une confusion fréquente dans les systèmes de pilotage. La valeur qui permet de décider vite n'est pas forcément celle qui permet d'expliquer la décision plus tard. Le score sert l'interopérabilité ; le reçu d'exécution sert l'attribution et l'audit.

Deux échelles, deux sens de zéro

Sans :percent, l'extension spamtest utilise une échelle de zéro à dix. Zéro correspond à non testé ou indéterminé ; un correspond à testé et clairement non-spam. Avec :percent, zéro peut aussi signifier testé et clairement sain.

La même apparence change donc de sens selon l'échelle. Si le journal conserve la valeur mais pas le mode, il perd la proposition que le nombre était censé exprimer. Lors d'une migration, une série historique de zéros peut devenir impossible à interpréter correctement.

RFC 5235 offre une question séparée grâce à :count. Une valeur de comptage égale à un indique que le contrôle sous-jacent a été réalisé ; zéro indique qu'il ne l'a pas été ou que Sieve ne peut pas le déterminer. Ce reçu rétablit une frontière d'exécution. Il ne révèle toutefois ni l'identité du moteur, ni sa fraîcheur, ni la couverture du contrôle.

Le canal du résultat commande la politique

Une implémentation peut transmettre le résultat par des en-têtes privés. Le volet sécurité de RFC 5235 impose alors que seuls les processus légitimes de contrôle puissent produire cette information et qu'un expéditeur ou un intermédiaire ne puisse pas la contrefaire.

Cette exigence montre où se trouve le pouvoir. Si une valeur infléchit le filtrage, écrire cette valeur revient à peser sur la décision. L'intégrité du canal est donc une question d'autorité, pas seulement de format.

Mais un résultat authentique peut encore provenir d'un scanner obsolète ou d'un examen incomplet. Le RFC recommande de maintenir les outils à jour et rappelle que la détection antivirus n'est pas infaillible. Prouver l'origine du score ne prouve pas la qualité de l'examen.

Ne pas faire remonter l'issue dans le score

Le résultat normalisé appartient à l'interface de test. La comparaison détermine ensuite si une branche du script correspond. Une action peut être sélectionnée, tentée par le serveur, confirmée par un stockage ou un transfert, puis perçue — ou non — par le destinataire.

Chacune de ces étapes a son sujet. « Score nul » ne signifie pas « contrôle exécuté ». « Branche sélectionnée » ne signifie pas « action accomplie ». « Message classé » ne signifie pas « utilisateur protégé ». Les fusionner produit un récit propre, mais une chaîne de preuve fragile.

L'apport singulier de RFC 5235 se situe avant l'action : il révèle ce que la transformation d'un contrôle local en valeur portable peut conserver et ce qu'elle peut perdre.

Ce que les sources ne disent pas

Le standard ne documente aucun fournisseur actuel, aucun taux d'erreur, aucune campagne malveillante ni incident d'exploitation. Le registre IANA établit l'existence des extensions, pas leur adoption ou leur bonne mise en œuvre. Une spécification de sémantique n'est pas une étude de marché.

Tout zéro n'est pas non plus une faute. Pour un traitement sans enjeu, une organisation peut accepter un statut inconnu. Elle doit seulement enregistrer cette décision comme une tolérance au risque, et non comme la preuve factuelle qu'un message a été déclaré sain.

L'échelle de virustest confirme la nécessité de cette précision : elle distingue non testé, sain, rendu inoffensif, possiblement infecté et certainement infecté. Ces états restent les sorties d'un processus dont la fiabilité doit être gouvernée ailleurs.

Conserver deux reçus, puis deux autres

Le premier reçu doit décrire le résultat portable : extension, échelle, valeur, comparaison, branche et version du script. Le second doit décrire l'exécution : contrôle réalisé ou non, scanner, version des règles, heure de mise à jour, représentation examinée, exclusions, erreurs et canal de provenance.

L'action et l'effet final méritent ensuite leurs propres reçus. Les états non testé, inconnu, délai dépassé ou contrôle partiel doivent rester visibles. Les transformer en « sain » pour satisfaire un champ numérique détruit précisément l'information dont une enquête aura besoin.

La doctrine de Lu Heng place la réalité opératoire avant le récit institutionnel. Ici, cela signifie qu'un nom de protocole n'endosse pas la responsabilité. Un décideur identifiable doit fixer le seuil à partir duquel l'ambiguïté portable ne suffit plus.

Un zéro peut être une valeur valide. Il n'est pas, à lui seul, le témoin d'un travail accompli.

Sources

Dossier normatif complémentaire

  1. Texte brut de RFC 5235
  2. Fiche d'information RFC 5235
  3. Fiche Datatracker RFC 5235
  4. Historique RFC 5235
  5. Errata RFC 5235
  6. Documents citant RFC 5235