2. Operational Overview (Aperçu opérationnel)

2.1 Publishing Authorization (Publication de l'autorisation)

Les domaines conformes SPF publient des enregistrements SPF valides comme décrit dans la section 3. Ces enregistrements autorisent les MTA qui y sont spécifiés à utiliser le nom de domaine associé dans les identités "HELO" et "MAIL FROM".

Les résultats SPF peuvent être utilisés pour prendre des déterminations positives (la source est autorisée) et négatives (la source n'est pas autorisée). Si un ADMD choisit de publier un enregistrement SPF et souhaite soutenir les destinataires dans la prise de décisions d'autorisation négatives, il doit publier un enregistrement se terminant par "-all" ou redirigeant vers un autre qui le fait; sinon, aucune détermination définitive sur l'autorisation ne peut être faite. La section 10 discute des problèmes potentiels et des mesures d'atténuation liés aux décisions négatives.

Les ADMD souhaitant déclarer qu'aucun hôte n'est autorisé à utiliser leur nom de domaine DNS dans les commandes HELO ou MAIL FROM pendant les sessions SMTP peuvent publier un tel enregistrement SPF pour les noms de domaine qui ne sont ni utilisés dans la partie domaine des adresses e-mail ni destinés à envoyer des e-mails.

Lors de modifications des enregistrements SPF, il faut veiller à ce qu'il y ait une période de transition pendant laquelle l'ancienne politique reste valide jusqu'à ce que tous les e-mails légitimes puissent raisonnablement être supposés avoir été vérifiés. La section 4.5.4.1 de [RFC5321] discute de la durée pendant laquelle les messages peuvent rester en transit. Bien que les vérifications hors ligne soient possibles, plus la vérification est proche du moment de transmission original, plus il est probable d'obtenir un résultat SPF correspondant à l'intention de l'ADMD émetteur au moment de l'envoi du message.

2.2 Checking Authorization (Vérification de l'autorisation)

Les destinataires de messagerie peuvent effectuer un ensemble de vérifications SPF pour chaque e-mail reçu. Une vérification SPF teste l'autorisation de l'hôte client à envoyer des e-mails avec une identité donnée. Typiquement, de telles vérifications sont effectuées par le MTA récepteur, mais elles peuvent être effectuées ailleurs dans la chaîne de traitement du courrier tant que les informations requises sont disponibles et fiables. Les identités "MAIL FROM" et "HELO" sont vérifiées respectivement conformément aux sections 2.4 et 2.3.

Il n'est pas recommandé de vérifier d'autres identités contre les enregistrements SPF version 1 sans approbation explicite de l'ADMD publiant, car on sait que certaines situations donnent des résultats incorrects. Par exemple, presque toutes les listes de diffusion réécrivent l'identité "MAIL FROM" (voir section 10.3), mais certaines ne modifient aucune autre identité dans le message. Les documents définissant d'autres identités doivent définir des méthodes d'approbation explicite.

Les destinataires de messagerie peuvent inclure les vérifications SPF dans le cadre d'un ensemble de tests plus large sur le courrier entrant. Les résultats d'autres tests peuvent influencer si une vérification SPF particulière est effectuée. Par exemple, trouver l'adresse IP de l'hôte émetteur sur une liste blanche locale peut entraîner le saut de tous les autres tests et l'acceptation de tous les e-mails de cet hôte.

Lorsqu'un destinataire de messagerie décide d'effectuer une vérification SPF, il doit utiliser la fonction check_host() correctement implémentée (section 4) et évaluer avec les paramètres corrects. Bien que l'ensemble du test soit optionnel, une fois la décision prise de l'effectuer, il doit être effectué comme prescrit pour préserver les sémantiques correctes entre les éditeurs et les destinataires.

Pour effectuer le test, le destinataire de messagerie doit évaluer la fonction check_host() avec les paramètres décrits dans la section 4.1.

Bien que les domaines invalides, mal formés ou inexistants entraînent le retour de "none" par les vérifications SPF (car aucun enregistrement SPF n'est trouvé), la politique de nombreux MTA depuis longtemps est de rejeter les e-mails de tels domaines, en particulier dans le cas d'un "MAIL FROM" invalide. Le rejet de l'e-mail empêche un moyen de contourner les enregistrements SPF.

Les implémentations doivent veiller à extraire correctement le <domain> des données fournies avec la commande SMTP MAIL FROM, car de nombreux MTA acceptent encore des choses comme le routage source (voir l'annexe C de [RFC5321]), le %-hack (voir [RFC1123]) et les chemins bang (voir [RFC1983]). Ces fonctionnalités obsolètes ont été utilisées de manière malveillante pour contourner les systèmes de sécurité.

2.3 The "HELO" Identity (L'identité "HELO")

Il est recommandé que les vérificateurs SPF vérifient non seulement l'identité "MAIL FROM" mais aussi l'identité "HELO" séparément en appliquant la fonction check_host() (section 4) à l'identité "HELO" comme <domain>. La vérification de "HELO" peut favoriser des résultats cohérents et peut réduire l'utilisation des ressources DNS. Si une détermination définitive sur un message peut être faite sur la base de la vérification de "HELO", les ressources DNS pour traiter le "MAIL FROM" normalement plus complexe peuvent être évitées. De plus, comme les enregistrements SPF publiés pour l'identité "HELO" se réfèrent à un seul hôte, lorsqu'ils sont disponibles, ils sont une source très fiable du statut d'autorisation de l'hôte. Si les deux doivent être vérifiés, il est recommandé de vérifier d'abord "HELO" puis "MAIL FROM".

Notez que les exigences sur le domaine présenté dans la commande EHLO ou HELO pour les expéditeurs ne sont pas toujours claires, et les vérificateurs SPF doivent être prêts à ce que l'identité soit un littéral d'adresse IP (voir section 4.1.3 de [RFC5321]) ou simplement mal formée. Cette vérification SPF ne peut être effectuée que si la chaîne "HELO" est un nom de domaine multi-étiquettes valide.

2.4 The "MAIL FROM" Identity (L'identité "MAIL FROM")

Si la vérification "HELO" n'a pas été effectuée ou n'a pas atteint un résultat de politique définitif, le vérificateur SPF doit vérifier l'identité "MAIL FROM" en appliquant la fonction check_host() à l'identité "MAIL FROM" comme <domain>.

[RFC5321] permet que le chemin inverse soit vide (voir section 4.5.5 dans [RFC5321]). Dans ce cas, il n'y a pas de boîte aux lettres d'expéditeur explicite, et de tels messages peuvent être supposés être des messages de notification du système de messagerie lui-même. Lorsque le chemin inverse est vide, ce document définit l'identité "MAIL FROM" comme la boîte aux lettres composée de la partie locale "postmaster" et de l'identité "HELO" (qui peut ou non avoir été vérifiée séparément auparavant).

2.5 Location of Checks (Emplacement des vérifications)

Les vérifications d'autorisation doivent être effectuées pendant le traitement de la transaction SMTP qui reçoit l'e-mail. Cela réduit la complexité de la détermination de l'adresse IP correcte à utiliser comme entrée pour check_host() et permet de retourner les erreurs directement au MTA émetteur via les réponses SMTP. L'annexe D de [RFC7001] offre une discussion plus complète sur ce sujet.

Les vérifications d'autorisation sont effectuées pendant la transaction SMTP au moment de la commande MAIL et utilisent la valeur MAIL FROM et l'adresse IP du client. Effectuer des vérifications à un moment ultérieur ou avec d'autres entrées peut entraîner les problèmes suivants:

Il peut être difficile d'extraire avec précision les informations requises à partir d'en-têtes potentiellement usurpés.
Les e-mails légitimes peuvent échouer à la vérification d'autorisation parce que la politique de l'expéditeur a changé.

Générer des avis de non-livraison à des identités usurpées ayant échoué à la vérification d'autorisation constitue normalement du backscatter, c'est-à-dire des avis de rejet de harcèlement inutilisables. Les opérateurs sont fortement encouragés à éviter de telles pratiques. La section 2 de [RFC3834] décrit le backscatter et les problèmes qu'il cause.

2.6 Results of Evaluation (Résultats de l'évaluation)

La section 4 définit check_host(), une définition de fonction modèle qui utilise les entrées définies ci-dessus et la politique d'expéditeur publiée dans le DNS pour arriver à des conclusions sur l'autorisation du client. Les vérificateurs SPF implémentent quelque chose de sémantiquement équivalent à la fonction définie ici.

Cette section énumère et définit brièvement les sorties possibles de cette fonction. Cependant, notez que le protocole n'établit pas d'exigences normatives pour le traitement d'un résultat particulier. Les options de traitement pour chaque résultat sont discutées dans la section 8.

2.6.1 None

Un résultat de "none" signifie que (a) aucun nom de domaine DNS syntaxiquement valide n'a pu être extrait de la session SMTP pour être utilisé comme <domain> à autoriser, ou (b) aucun enregistrement SPF n'a été récupéré du DNS.

2.6.2 Neutral (Neutre)

Un résultat "neutral" signifie que l'ADMD a explicitement déclaré qu'il n'affirme pas si l'adresse IP est autorisée ou non.

2.6.3 Pass (Réussi)

Un résultat "pass" est une déclaration explicite que le client est autorisé à injecter du courrier avec l'identité donnée.

2.6.4 Fail (Échec)

Un résultat "fail" est une déclaration explicite que le client n'est pas autorisé à utiliser le domaine dans l'identité donnée.

2.6.5 Softfail (Échec doux)

Un résultat "softfail" est une déclaration faible de l'ADMD publiant que l'hôte pourrait ne pas être autorisé. Il n'a pas publié une politique plus forte et plus explicite qui entraînerait un "fail".

2.6.6 Temperror (Erreur temporaire)

Un résultat "temperror" signifie que le vérificateur SPF a rencontré une erreur transitoire (généralement DNS) lors de l'exécution de la vérification. Une nouvelle tentative ultérieure peut réussir sans action supplémentaire de l'opérateur DNS.

2.6.7 Permerror (Erreur permanente)

Un résultat "permerror" signifie que l'enregistrement publié du domaine n'a pas pu être interprété correctement. Cela indique une condition d'erreur qui nécessite définitivement l'intervention de l'opérateur DNS pour être résolue.