Résumé

  • Les noms location, phase, host ou remote-host rendent un script adaptable. Leur valeur reste une observation fournie par l’implémentation, non une attestation d’identité ou de résultat.
  • RFC 5183 avertit qu’un remote-host issu d’un PTR peut être choisi par une source non fiable. Le suffixe d’un nom ne constitue donc pas un périmètre de sécurité.

L’ancien système exécutait le filtre dans un composant de stockage après la remise. Le nouveau déclarait lui aussi location=MS et phase=post. La recette de migration valida les deux comparaisons et conclut que la politique n’avait pas changé.

Pourtant, « post » ne recouvrait pas les mêmes engagements. Dans le premier système, la règle s’exécutait avant la réplication de la boîte ; dans le second, elle intervenait après l’écriture primaire mais avant l’indexation et la visibilité client. Le vocabulaire était identique. Le point de reprise, l’échec partiel et la preuve disponible ne l’étaient pas.

Ce scénario n’attribue aucun comportement à un produit réel. Il révèle une limite volontaire du standard : un mot commun permet l’interopérabilité, mais ne remplace pas la description locale de ce que fait le code.

Un test qui interroge l’interpréteur

L’extension environment ajoute un test dont la source n’est pas directement le message. L’interpréteur extrait une information de son environnement d’exécution ; le script fournit le nom de l’item et les clés de comparaison. Par défaut, la correspondance est :is et le comparateur i;ascii-casemap.

Cette séparation est précieuse. Le filtre peut adapter son comportement au domaine, à l’hôte, au type de service, à la phase de remise, au produit ou à la connexion distante. Il n’a pas besoin de transformer ces données en en-têtes ni de supposer une architecture universelle.

Elle impose aussi une discipline de preuve. La chaîne doit conserver l’implémentation qui a fourni la valeur, sa méthode de calcul, le moment de l’observation et le sens local attribué au résultat. « La condition était vraie » ne suffit pas à reconstruire ces éléments.

Les items initiaux sont bornés. domain désigne le domaine DNS principal du contexte, généralement mais pas toujours suffixe du nom d’hôte. host nomme l’hôte d’exécution. location distingue MTA, MDA, MUA et magasin de messages. phase situe l’évaluation avant, pendant ou après la remise finale. name et version décrivent le produit. remote-host et remote-ip décrivent le client SMTP, LMTP ou Submission lorsqu’ils sont applicables et disponibles.

Le standard ne transforme aucun de ces champs en identité juridique, zone interne, numéro de build, transaction validée ou réception humaine.

La portabilité commence par l’absence

Un item peut ne pas exister. RFC 5183 exige alors que le test échoue sans provoquer d’erreur de script. Une condition :contains avec une chaîne vide peut servir à découvrir que l’implémentation connaît l’item, car toute chaîne renvoyée contient la chaîne vide.

Cette astuce ne garantit pas une valeur informative. remote-host doit être vide si le nom ne peut être obtenu. Avec l’extension relationnelle, le comptage vaut zéro pour une chaîne vide et un sinon. Le mécanisme distingue donc au moins l’absence de l’item, l’existence avec valeur vide et l’existence avec valeur non vide.

Une migration sûre conserve ces états. Si le nouveau serveur ne connaît pas un item fournisseur, le script doit suivre un chemin explicite. S’il connaît remote-host mais ne peut le remplir, la politique doit décider ce qu’implique l’incertitude. Si une valeur apparaît, il reste à examiner sa provenance.

Le simple fait d’annoncer la capacité environment n’engage pas chaque implémentation à fournir tous les items. Le RFC recommande d’en prendre en charge autant que possible. La capacité, la présence, la population et la confiance sont quatre assertions différentes.

Le registre empêche les collisions, pas les contresens

Les items normalisés peuvent être définis par des RFC de standardisation ou expérimentales. Les extensions propres à un fournisseur commencent par vnd. et sont enregistrées afin d’éviter les collisions. Le registre IANA actuel conserve les items initiaux, des ajouts IMAP et un espace fournisseur.

Cette organisation est un bon exemple de spécification commune minimale. Un futur document peut étendre le langage sans demander à un centre permanent de décider toute l’architecture du courrier. Un fournisseur peut publier un contexte local sans lui donner un statut universel.

Mais le registre ne traduit pas les politiques. vnd.a.cluster=blue n’acquiert pas le même sens chez un autre fournisseur parce que son nom est unique. Même location=MS exige une carte locale : quel processus, quelle génération, quelle écriture, quel domaine de panne et quelle étape de visibilité ?

RFC 5463 ajoute une façon de tester la disponibilité de capacités. Cette vérification résout la compatibilité syntaxique. Elle ne prouve ni l’existence d’un item, ni l’exactitude de sa valeur, ni l’équivalence de deux déploiements.

L’exemple PTR fixe la limite de confiance

RFC 5183 autorise toute technique pour déterminer remote-host et souligne que sa fiabilité varie. Un choix courant est la requête PTR sur l’adresse cliente. Or le résultat peut provenir d’une source non fiable. Celui qui contrôle le PTR peut choisir un nom renvoyant au domaine qu’il souhaite.

Une règle *.example.com peut donc fonctionner exactement comme écrite et mal classifier la relation de confiance. Le protocole ne promettait qu’un nom d’hôte disponible, pas la propriété de l’organisation ni l’appartenance au réseau interne.

Pour prendre une décision sensible, il faut conserver l’adresse du pair, la requête inverse, le résolveur, la réponse, son ancienneté, la politique de validation et, s’il y en a une, la confirmation directe. Même une donnée DNS authentifiée ne prouve pas à elle seule le rôle commercial ou humain que l’application cherche à autoriser.

remote-ip évite la dérivation nominale mais reste l’adresse du pair observé à cet endroit. Relais, proxy, NAT et service de soumission peuvent séparer ce pair de l’auteur initial. La carte de confiance appartient au déploiement et doit être déclarée.

Une observation initiale ne suit pas l’action

RFC 6785 montre comment le modèle s’étend aux événements IMAP. Dans ce cas, location devient MS et phase devient post. De nouveaux items décrivent l’utilisateur, la cause APPEND/COPY/FLAG, la boîte et les drapeaux modifiés.

Le détail décisif concerne imap.mailbox : sa valeur est fixée au début du script et ne change pas après une action fileinto. Elle dit d’où vient l’invocation ou quelle boîte était initialement visée ; elle ne devient pas le registre de la destination finale.

imap.changedflags possède une limite comparable. Il peut nommer des drapeaux qui ont changé, mais ne dit pas lesquels ont été posés ou retirés. Le script doit interroger l’état courant. Une seule valeur ne résume pas toute la transition.

La même retenue s’applique à phase=post. Elle situe l’évaluation. Elle ne prouve pas que l’action choisie a été écrite, répliquée, indexée ou montrée à l’utilisateur. La preuve doit poursuivre la chaîne après l’interpréteur.

Un contrat de migration plutôt qu’un tableau d’équivalences

Avant de déplacer une politique, l’équipe devrait inventorier chaque item, sa présence attendue, sa source, son sens local et son niveau de confiance. Elle doit lier le hash exact du script au produit et au build réellement chargés, puis tester les branches d’absence, de chaîne vide et de valeur inconnue.

Pour chaque décision qui rejette, redirige, met en quarantaine ou libère un message, le reçu associe l’observation au comparateur et à la branche, puis enregistre l’action et l’effet en aval. Le message visible, la boîte finale et la transaction de transport ne doivent pas être déduits d’un mot comme post.

Cette méthode respecte la fonction du registre. Le standard fournit des points de rencontre ; l’opérateur conserve l’autorité sur la signification locale et la responsabilité de la vérifier. La question finale n’est pas « les deux serveurs ont-ils renvoyé le même mot ? », mais « le même fait observable et le même engagement opérationnel se trouvent-ils derrière ce mot ? »

Sources

  1. RFC 5183 — HTML
  2. RFC 5183 — texte brut
  3. Page d’information du RFC Editor
  4. Page du document dans l’IETF Datatracker
  5. Historique dans l’IETF Datatracker
  6. Références dans l’IETF Datatracker
  7. Errata du RFC 5183
  8. RFC 5228 — spécification de base de Sieve
  9. Page d’information du RFC 5228
  10. RFC 5231 — extension relationnelle
  11. RFC 5598 — architecture du courrier Internet
  12. RFC 6785 — événements IMAP dans Sieve
  13. Page d’information du RFC 6785
  14. RFC 5804 — ManageSieve
  15. RFC 5463 — extension Sieve ihave
  16. Registre IANA des extensions Sieve
  17. Registre IANA des items d’environnement Sieve
  18. Heng Lu — couches de réalité
  19. Heng Lu — spécification minimale et adoption volontaire
  20. Heng Lu — priorité au code en fonctionnement