5. Mechanism Definitions (Définitions des mécanismes)

Cette section définit deux types de mécanismes: les mécanismes de cadre de langage de base et les mécanismes spécifiant l'expéditeur.

Les mécanismes de base facilitent le cadre du langage. Ils ne spécifient pas un type particulier de schéma d'autorisation. Les mécanismes de base sont les suivants:

all
include

Les mécanismes spécifiant l'expéditeur sont utilisés pour identifier un ensemble d'adresses <ip> qui sont autorisées ou non autorisées à envoyer des messages avec <domain>. Les mécanismes spécifiant l'expéditeur sont les suivants:

a
mx
ptr (do not use)
ip4
ip6
exists

Les conventions suivantes s'appliquent à tous les mécanismes qui effectuent à tout moment une comparaison entre <target-name> et une adresse IP:

Si aucune longueur de préfixe CIDR n'est donnée dans la directive, <target-name> est comparé à l'adresse IP pour l'égalité. (Ici, CIDR est le routage inter-domaine sans classe, décrit dans [RFC4632].)

Si une longueur de préfixe CIDR est spécifiée, seul le nombre spécifié de bits de poids fort de <target-name> est comparé à l'adresse IP pour l'égalité.

Lorsqu'un mécanisme récupère des adresses d'hôte à comparer avec <ip>, les enregistrements "A" sont récupérés lorsque <ip> est IPv4, et les enregistrements "AAAA" sont récupérés lorsque <ip> est une adresse IPv6. Les implémentations SPF sur les serveurs IPv6 doivent gérer les enregistrements "AAAA" et "A" pour les clients sur des adresses IPv6 mappées IPv4 [RFC4291]. Les adresses IPv4 sont répertoriées uniquement dans l'enregistrement SPF avec le mécanisme "ip4".

Plusieurs mécanismes dépendent des informations récupérées du DNS. Pour ces requêtes DNS, sauf indication contraire, si le serveur DNS renvoie une erreur (RCODE ni 0 ni 3) ou si la requête expire, le mécanisme s'arrête et le check_host() de niveau supérieur renvoie "temperror". Si le serveur renvoie "Name Error" (RCODE 3), l'évaluation du mécanisme continue comme si le serveur renvoyait sans erreur (RCODE 0) et zéro enregistrement de réponse.

5.1 "all"

all = "all"

Le mécanisme "all" est un test qui correspond toujours. Il est utilisé comme mécanisme le plus à droite dans l'enregistrement pour fournir une valeur par défaut explicite.

Exemple:

v=spf1 a mx -all

Les mécanismes après "all" ne sont jamais testés. Les mécanismes répertoriés après "all" doivent être ignorés. Lorsqu'un mécanisme "all" est présent dans l'enregistrement, tout modificateur "redirect" (Section 6.1) doit être ignoré, quel que soit l'ordre relatif des termes.

5.2 "include"

include = "include" ":" domain-spec

Le mécanisme "include" déclenche une évaluation récursive de check_host().

<domain-spec> est étendu selon la Section 7.
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().
L'évaluation récursive renvoie une correspondance, une non-correspondance ou une erreur.
Si elle renvoie une correspondance, le mécanisme "include" utilise le résultat approprié (par exemple, include ou +include produit un résultat "pass", -include produit "fail").
Si elle renvoie une non-correspondance ou une erreur, le check_host() parent reprend le traitement selon le tableau suivant et restaure la valeur <domain> précédente.

Rétrospectivement, le nom "include" était un mauvais choix. Seul le résultat d'évaluation de l'enregistrement SPF référencé est utilisé, plutôt que d'inclure littéralement les mécanismes de l'enregistrement référencé dans le premier enregistrement. Par exemple, l'évaluation d'une directive "-all" dans l'enregistrement référencé ne termine pas le traitement global et n'entraîne pas nécessairement un "fail" global. (De meilleurs noms pour ce mécanisme auraient été "if-match", "on-match", etc.)

Le mécanisme "include" permet à un domaine de spécifier plusieurs domaines administrativement indépendants. Par exemple, le domaine de vanité "example.net" pourrait envoyer des messages en utilisant les serveurs des domaines administrativement indépendants example.com et example.org.

Example.net pourrait dire

IN TXT "v=spf1 include:example.com include:example.org -all"

Cela demanderait à check_host() de vérifier efficacement les enregistrements d'example.com et d'example.org pour un résultat "pass". Ce n'est que si l'hôte n'est autorisé par aucun de ces deux domaines que le résultat serait "fail".

Le fait que ce mécanisme corresponde, ne corresponde pas ou renvoie une exception dépend du résultat de l'évaluation récursive de check_host():

+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of:                             | to:                            |
+---------------------------------+---------------------------------+
| pass                            | match                          |
|                                 |                                |
| fail                            | not match                      |
|                                 |                                |
| softfail                        | not match                      |
|                                 |                                |
| neutral                         | not match                      |
|                                 |                                |
| temperror                       | return temperror               |
|                                 |                                |
| permerror                       | return permerror               |
|                                 |                                |
| none                            | return permerror               |
+---------------------------------+---------------------------------+

Le mécanisme "include" est destiné à franchir les frontières administratives. Lorsqu'il reste au sein d'une seule autorité administrative, "include" n'est généralement pas le meilleur choix. Par exemple, si example.com et example.org sont gérés par la même entité, et si l'ensemble des hôtes autorisés pour les deux domaines est "mx:example.com", alors example.org pourrait spécifier "include:example.com", mais il serait préférable de spécifier "redirect=example.com" ou même "mx:example.com".

Avec le mécanisme "include", il est possible d'autoriser un ensemble administrativement externe d'hôtes, mais la détermination de la politique de l'expéditeur reste une fonction de l'enregistrement SPF du domaine d'origine (déterminé par le mécanisme "all" dans cet enregistrement). Le modificateur "redirect" est plus approprié pour consolider l'autorisation et la politique en un ensemble commun à partager au sein d'un ADMD. Redirect ressemble plus à un élément de code commun à partager entre les enregistrements 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.

5.3 "a"

Ce mécanisme correspond lorsque <ip> est l'une des adresses IP de <target-name>. Pour clarifier, cela signifie que le mécanisme "a" correspond également aux enregistrements AAAA.

a = "a" [ ":" domain-spec ] [ dual-cidr-length ]

Une requête d'adresse est effectuée pour <target-name> en utilisant le type de requête (A ou AAAA) approprié pour le type de connexion (IPv4 ou IPv6). <ip> est comparé aux adresses renvoyées. Si une adresse correspond, le mécanisme correspond.

5.4 "mx"

Ce mécanisme correspond lorsque <ip> est l'un des hôtes MX du nom de domaine.

mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]

check_host() effectue d'abord une requête MX pour <target-name>. Ensuite, il effectue une requête d'adresse pour chaque nom MX renvoyé. <ip> est comparé à chaque adresse IP renvoyée. Pour éviter les attaques par déni de service (DoS), les limites de traitement définies dans la Section 4.6.4 doivent être respectées. Si la limite de requête MX est dépassée, "permerror" est renvoyé et l'évaluation se termine. Si une adresse correspond, le mécanisme correspond.

Note sur les MX implicites: Si <target-name> n'a pas d'enregistrements MX, check_host() ne doit absolument pas appliquer la règle MX implicite de [RFC5321], c'est-à-dire interroger les enregistrements A ou AAAA pour le même nom.

5.5 "ptr" (do not use) ("ptr" (ne pas utiliser))

Ce mécanisme teste si le mappage inverse DNS de <ip> existe et pointe correctement vers un nom de domaine dans un domaine particulier. Ce mécanisme ne devrait pas être publié. Voir les notes à la fin de cette section pour plus d'informations.

ptr = "ptr" [ ":" domain-spec ]

Le nom de <ip> est recherché à l'aide de la procédure suivante:

Effectuez un mappage inverse DNS pour <ip>: recherchez l'enregistrement PTR correspondant dans "in-addr.arpa.", si l'adresse est IPv4, ou dans "ip6.arpa.", si elle est IPv6.
Pour chaque enregistrement renvoyé, validez le nom de domaine en recherchant son adresse IP. Pour éviter les attaques DoS, les limites de traitement PTR définies dans la Section 4.6.4 doivent être appliquées. Si les limites sont dépassées, terminez le traitement et le mécanisme ne correspond pas.
Si <ip> est parmi les adresses IP renvoyées, ce nom de domaine est validé.

Vérifiez tous les noms de domaine validés pour voir s'ils correspondent à <target-name> ou sont des sous-domaines de <target-name>. S'il y a des correspondances, ce mécanisme correspond. Si aucun nom de domaine validé ne peut être trouvé, ou si aucun nom de domaine validé ne correspond ou n'est un sous-domaine de <target-name>, ce mécanisme ne peut pas correspondre. Si une erreur DNS se produit lors de l'exécution de la requête PTR RR, ce mécanisme ne peut pas correspondre. Si une erreur DNS se produit lors de l'exécution d'une requête A RR, ce nom de domaine est ignoré et la recherche continue.

Ce mécanisme correspond lorsque:

<target-name> est un sous-domaine du nom de domaine validé, ou
<target-name> et le nom de domaine validé sont identiques.

Par exemple, "mail.example.com" est dans le domaine "example.com", mais "mail.bad-example.com" ne l'est pas.

Note: Ce mécanisme est lent, pas aussi fiable que d'autres mécanismes en cas d'erreurs DNS, et impose une charge importante aux serveurs de noms .arpa. En cas d'utilisation, des enregistrements PTR appropriés doivent être configurés pour les hôtes du domaine, et le mécanisme "ptr" devrait être l'un des derniers mécanismes vérifiés. Après plusieurs années d'expérience de déploiement SPF, la conclusion a été tirée qu'il est inutile et que des alternatives plus fiables devraient être utilisées. Cependant, il reste une partie du protocole SPF, donc les implémentations check_host() conformes doivent le prendre en charge.

5.6 "ip4" and "ip6" ("ip4" et "ip6")

Ces mécanismes testent si <ip> est contenu dans un réseau IP donné.

ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]

ip4-cidr-length = "/" ("0" / %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" / %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT                      ; 0-9
     / %x31-39 DIGIT              ; 10-99
     / "1" 2DIGIT                 ; 100-199
     / "2" %x30-34 DIGIT          ; 200-249
     / "25" %x30-35               ; 250-255
     ; as per conventional dotted-quad notation, e.g., 192.0.2.0

ip6-network = &lt;as per [RFC5952], Section 4>
            ; e.g., 2001:db8::cd30

Comparez <ip> au réseau donné. Si les bits de poids fort de la longueur du préfixe CIDR correspondent, le mécanisme correspond.

Si ip4-cidr-length est omise, elle est traitée comme "/32". Si ip6-cidr-length est omise, elle est traitée comme "/128". Il n'est pas autorisé d'omettre des parties de l'adresse IP au lieu d'utiliser la notation CIDR. C'est-à-dire, utilisez 192.0.2.0/24 au lieu de 192.0.2.

5.7 "exists"

Ce mécanisme est utilisé pour construire un nom de domaine arbitraire pour une requête d'enregistrement DNS A. Il permet des schémas complexes impliquant des parties arbitraires de l'enveloppe de message pour déterminer ce qui est autorisé.

exists = "exists" ":" domain-spec

<domain-spec> est étendu selon la Section 7. Le nom de domaine résultant est utilisé pour une requête DNS A RR (même si le type de connexion est IPv6). Si des enregistrements A sont renvoyés, ce mécanisme correspond.

Les domaines peuvent utiliser ce mécanisme pour spécifier des requêtes arbitrairement complexes. Par exemple, supposons qu'example.com publie l'enregistrement:

v=spf1 exists:%\{ir}.%\{l1r+-}._spf.%\{d} -all

<target-name> pourrait s'étendre à "1.2.0.192.someuser._spf.example.com". Cela permet de prendre des décisions granulaires au niveau de l'utilisateur et de l'adresse IP du client.