1. Introduction
1. Introduction
L'infrastructure de messagerie actuelle a la caractéristique que tout hôte injectant des messages dans le système peut utiliser n'importe quel nom de domaine DNS dans les divers identifiants spécifiés dans [RFC5321] et [RFC5322]. Bien que cette caractéristique soit avantageuse dans certains cas, elle constitue un obstacle majeur à la réduction des e-mails en masse non sollicités (UBE, Unsolicited Bulk Email, également connu sous le nom de spam). De plus, les ADMD (comme décrit dans [RFC5598]) sont légitimement préoccupés par le fait que d'autres entités puissent facilement utiliser leurs noms de domaine, souvent avec des intentions malveillantes.
Ce document définit un protocole par lequel un ADMD peut autoriser des hôtes à utiliser son nom de domaine dans les identités "MAIL FROM" ou "HELO". Les ADMD conformes publient des enregistrements Sender Policy Framework (SPF) dans le DNS, spécifiant quels hôtes sont autorisés à utiliser leurs noms, et les destinataires de messagerie conformes utilisent les enregistrements SPF publiés pour tester l'autorisation d'un agent de transfert de messagerie (MTA, Mail Transfer Agent) émetteur utilisant une identité "HELO" ou "MAIL FROM" donnée lors d'une transaction de messagerie.
Un autre avantage pour les destinataires de messagerie est qu'après avoir validé l'utilisation d'une identité, des décisions de politique locale concernant les e-mails peuvent être prises sur la base du domaine de l'expéditeur plutôt que sur la base de l'adresse IP de l'hôte. Cela est avantageux car la réputation d'un nom de domaine peut être plus précise que la réputation d'une adresse IP d'hôte, car le nom de domaine pourrait être plus stable sur une plus longue période. De plus, si l'identité revendiquée ne peut pas être validée, la politique locale peut prendre des mesures plus fermes contre de tels e-mails, comme les rejeter.
1.1 Terminology (Terminologie)
1.1.1 Key Words (Mots-clés)
Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans [RFC2119].
1.1.2 Imported Definitions (Définitions importées)
ABNF (Augmented Backus-Naur Form) est défini dans [RFC5234], les jetons "ALPHA", "DIGIT" et "SP" (espace) y sont également définis.
Les jetons "Local-part", "Domain" et "Mailbox" sont définis dans [RFC5321].
"dot-atom", "quoted-string", "comment", "CFWS" (Comment Folded White Space), "FWS" (Folded White Space) et "CRLF" (Carriage-Return/Line-Feed) sont définis dans [RFC5322].
1.1.3 MAIL FROM Definition (Définition MAIL FROM)
Ce document concerne l'identité de l'expéditeur du message, comme décrit dans [RFC5321]:
La transaction commence par la commande MAIL, qui fournit l'identité de l'expéditeur.
Comme cette identité a de nombreux autres noms, il est important de choisir un nom qui soit:
-
Couramment utilisé
-
Clairement défini
Par conséquent, le terme "MAIL FROM" sera utilisé dans ce document, défini comme l'identité RFC5321.MailFrom (Reverse-Path) décrite dans [RFC5598].
1.1.4 HELO Definition (Définition HELO)
Ce document utilise également l'identité HELO/EHLO. L'identité "HELO" provient de la commande SMTP HELO ou EHLO (voir [RFC5321]). Comme HELO et EHLO peuvent être utilisés de manière interchangeable dans de nombreux cas, ils sont généralement identifiés comme "HELO" dans ce document. Cela signifie RFC5321.HELO/.EHLO tel que défini dans [RFC5598]. Ces commandes fournissent l'identité du client SMTP (hôte émetteur) pour la session SMTP.
1.2 check_host()
La section 4 présente un algorithme utilisé pour évaluer la politique SPF par rapport à une transaction de messagerie entrante. Dans les premières implémentations, cet algorithme était codé dans une fonction appelée check_host(). Ce nom est utilisé dans ce document comme symbole de l'algorithme d'évaluation SPF, mais bien sûr, les implémenteurs ne sont pas tenus d'utiliser ce nom.