6. Modifier Definitions (Définitions des modificateurs)

Les modificateurs sont des paires nom/valeur qui fournissent des informations supplémentaires. Les modificateurs ont toujours un "=" séparant le nom et la valeur.

Les modificateurs définis dans ce document ("redirect" et "exp") devraient apparaître à la fin de l'enregistrement, après tous les mécanismes, bien qu'ils puissent syntaxiquement apparaître n'importe où dans l'enregistrement. L'ordre de ces deux modificateurs n'a pas d'importance. Ces deux modificateurs ne doivent absolument pas apparaître plus d'une fois dans un enregistrement. S'ils le font, check_host() se termine avec un résultat "permerror".

Les modificateurs non reconnus doivent être ignorés, peu importe où ou combien de fois ils apparaissent. Cela permet aux implémentations conformes à ce document de gérer correctement les enregistrements avec des modificateurs définis dans d'autres spécifications.

6.1 redirect: Redirected Query (redirect: Requête redirigée)

Le modificateur "redirect" est destiné à consolider l'autorisation et la politique en un ensemble commun à partager au sein d'un seul ADMD. Les hôtes autorisés et les politiques de n'importe quel nombre de domaines peuvent être contrôlés depuis un seul enregistrement.

redirect = "redirect" "=" domain-spec

Si tous les mécanismes ne correspondent pas et qu'un modificateur "redirect" est présent, le traitement se déroule comme suit:

La partie <domain-spec> de la partie redirect est étendue selon les règles de macro de la Section 7. Ensuite, check_host() est évalué avec la chaîne résultante comme <domain>. Les paramètres <ip> et <sender> restent les mêmes que dans l'évaluation actuelle de check_host().

Le résultat de cette nouvelle évaluation de check_host() est alors traité comme le résultat de l'évaluation actuelle, sauf que si aucun enregistrement SPF n'est trouvé ou si <target-name> est mal formaté, le résultat est "permerror" au lieu de "none".

Notez que le domaine de la nouvelle requête peut lui-même spécifier un traitement redirect.

Cet outil est destiné aux organisations qui souhaitent appliquer le même enregistrement à plusieurs domaines. Par exemple:

la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"

Dans cet exemple, le courrier de l'un de ces trois domaines est décrit par le même enregistrement. Cela peut être un avantage administratif.

Note: En général, le domaine "A" ne peut pas utiliser de manière fiable une redirection vers un autre domaine "B" qui n'est pas sous le même contrôle administratif. Puisque <domain> reste inchangé, il n'y a aucune garantie que l'enregistrement au domaine "B" fonctionnera correctement pour les boîtes aux lettres du domaine "A", en particulier si le domaine "B" utilise des mécanismes qui impliquent le local-part. La directive "include" serait généralement plus appropriée.

Pour plus de clarté, tout modificateur "redirect" devrait apparaître comme dernier terme dans l'enregistrement. Si un mécanisme "all" est présent n'importe où dans l'enregistrement, tout modificateur "redirect" doit être ignoré.

6.2 exp: Explanation (exp: Explication)

explanation = "exp" "=" domain-spec

Si check_host() aboutit à "fail" en raison d'un mécanisme correspondant (tel que "-all") et qu'un modificateur "exp" est présent, la chaîne d'explication renvoyée est calculée comme décrit ci-dessous. Si aucun modificateur "exp" n'est présent, soit une chaîne d'explication par défaut, soit une chaîne d'explication vide doit être renvoyée à l'application appelante.

<domain-spec> subit une expansion de macro (voir Section 7) et devient <target-name>. Le RRset DNS TXT pour <target-name> est récupéré.

S'il y a des erreurs de traitement DNS (n'importe quel RCODE différent de 0), ou si aucun enregistrement n'est renvoyé, ou si plus d'un enregistrement est renvoyé, ou s'il y a des erreurs de syntaxe dans la chaîne d'explication, continuez comme si aucun modificateur "exp" n'avait été donné.

Les chaînes de l'enregistrement TXT récupéré sont concaténées sans espaces puis traitées comme une explain-string, qui subit une expansion de macro. Ce résultat final est la chaîne d'explication. Les implémentations peuvent limiter la longueur de la chaîne d'explication résultante pour tenir compte d'autres contraintes de protocole et/ou de limites de traitement raisonnables. Puisque la chaîne d'explication est destinée à être utilisée dans les réponses SMTP, et que la Section 2.4 de [RFC5321] indique que les réponses sont [US-ASCII], la chaîne d'explication doit être limitée à [US-ASCII].

Le logiciel qui évalue check_host() peut utiliser cette chaîne pour communiquer des informations du domaine de publication sous forme de message court ou d'URL. Le logiciel devrait indiquer clairement que la chaîne d'explication provient d'un tiers. Par exemple, il pourrait préfixer l'explication avec la chaîne de macro "%\{o} explains: ", comme montré dans l'exemple de la Section 8.4.

Supposons qu'example.com ait cet enregistrement:

v=spf1 mx -all exp=explain._spf.%\{d}

Voici quelques exemples d'enregistrements TXT d'explication possibles à explain._spf.example.com:

"Mail from example.com should only be sent by its own servers."

-- un message simple et constant

"%\{i} is not one of %\{d}'s designated mail servers."

-- un message qui contient plus d'informations, y compris l'adresse IP qui a échoué à la vérification

"See http://%\{d}/why.html?s=%\{S}&i=%\{I}"

-- un exemple complexe utilisant les paramètres de check_host() pour construire une URL afin qu'une page Web avec des instructions détaillées et personnalisées puisse être générée

Note: Pendant la récursion dans un mécanisme "include", le modificateur "exp" de <target-name> ne doit absolument pas être utilisé. À l'inverse, lors de l'exécution d'un modificateur "redirect", le modificateur "exp" du domaine d'origine ne doit absolument pas être utilisé. Cela est dû au fait que "include" est destiné à franchir les frontières administratives, et l'explication à fournir devrait être celle de l'ADMD récepteur, tandis que "redirect" est destiné comme outil pour consolider les enregistrements de politique au sein d'un ADMD, et donc l'explication redirigée est celle qui devrait avoir la priorité.