Sender Policy Framework
Pour les articles homonymes, voir SPF.
Sender Policy Framework (SPF) est une norme de vérification du nom de domaine de l'expéditeur d'un courrier électronique, normalisée dans la RFC 7208[1] (section 3.1)[2]. L'adoption de cette norme est de nature à réduire le spam.
Description
[modifier | modifier le code]Le protocole Simple Mail Transfer Protocol (SMTP) utilisé pour le transfert du courrier électronique sur Internet ne prévoit pas de mécanisme de vérification de l'expéditeur, c'est-à-dire qu'il est facile d'envoyer un courrier avec une adresse d'expéditeur factice, voire usurpée. SPF vise à réduire les possibilités d'usurpation en publiant, dans le DNS, un enregistrement (de type TXT)[3] indiquant quelles adresses IP sont autorisées ou interdites à envoyer du courrier en provenance du domaine considéré.
L'identité testée par SPF est celle indiquée par la commande MAIL FROM dans la session SMTP. C'est donc une information qui appartient à l'enveloppe du courrier, pas à ses en-têtes. (Dans certaines conditions, SPF peut aussi utiliser le nom de la machine expéditrice, tel que spécifié dans la commande HELO.)
Voici par exemple l'enregistrement SPF d'ietf.org via la commande "dig TXT ietf.org" :
ietf.org. 720 IN TXT "v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56 ip4:64.170.98.0/24 ip6:2001:1890:126c::/56 ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64 ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64 ip4:72.167.123.204 -all"
Seuls les blocs d'adresses IPv4 et IPv6 indiqués sont habilités à envoyer du courrier avec un expéditeur du domaine ietf.org. Un serveur de courrier participant à SPF peut donc rejeter un mail provenant d'autres blocs d'adresses que ceux-ci.
Il n’est pas obligatoire de publier un enregistrement SPF, ni de faire usage de ceux existants. Les sites qui ne participent pas à cette initiative ne sont donc pas affectés par celle-ci. SPF ne garantit pas que la partie locale de l'adresse de courrier électronique (à gauche du signe @) est authentique.
Mécanismes
[modifier | modifier le code]Il existe huit mécanismes possibles dans un enregistrement DNS SPF :
| ALL | Correspond toujours ; utilisé pour un résultat par défaut, ex. : -all pour toutes les IP qui ne correspondent pas. |
| A | Correspond si le nom de domaine possède un enregistrement IN A (ou AAAA) qui peut être résolu comme adresse d'expéditeur. |
| IP4 | Correspond si l'expéditeur est dans cette plage IPv4. |
| IP6 | Correspond si l'expéditeur est dans cette plage IPv6. |
| MX | Correspond si le nom de domaine contient un enregistrement Mail eXchanger pointant vers l'adresse de l'expéditeur (ex. : si le mail provient d'un des serveurs entrants du domaine). |
| PTR | Correspond si le domaine de l'adresse IP (PTR record (en)) correspond au domaine spécifié, et que ce dernier pointe vers l'IP en retour (forward-confirmed reverse DNS (en)). Si l'administrateur du domaine peut obtenir le même résultat avec les autres mécanismes, il est alors préférable de ne pas utiliser le mécanisme PTR qui peut s'avérer plus lent et moins fiable en cas de problèmes DNS[4]. |
| EXISTS | Correspond si domaine donné existe, c'est-à-dire s'il est résolu en n'importe quelle adresse (peu importe la résolution de cette dernière). Ce mécanisme est rarement utilisé. Avec le macrolangage SPF il offre des correspondances plus complexes, comme les requêtes DNSBL. |
| INCLUDE | Correspond si la règle incluse passe le test. C'est typiquement utilisé pour gérer les règles quand il y a plusieurs FAI. |
Qualifieurs
[modifier | modifier le code]Chaque mécanisme peut être combiné avec un seul des quatre qualifieurs :
| + (plus) | pour un résultat favorable. Il peut être omis, ex : +mx est équivalent à mx. |
| ? (point d'interrogation) | pour un résultat neutre. Interprété comme NONE (aucune règle). |
| ~ (tilde) | pour un léger échec /*SOFTFAIL.*/ Intermédiaire entre le neutre et l'échec, il est utilisé pour le débogage. /*Les messages qui retournent un SOFTFAIL sont acceptés mais marqués.*/ |
| - (moins) | pour un échec total. Le mail doit être rejeté. |
Modifieurs
[modifier | modifier le code]Les modifieurs permettent des extensions au framework. Aujourd'hui seuls deux modifieurs définis par la RFC 4408[5] initiale du , ont été déployés dans un certain nombre de domaines :
| exp=some.example.com | donne le nom du domaine avec un enregistrement TXT (interprété comme utilisant le macrolangage SPF) pour obtenir une explication des résultats en échec. Typiquement, une URL ajoutée au code erreur SMTP. |
| redirect=some.example.com | alternative au mécanisme ALL, pour lier à un enregistrement de règle d'un autre domaine. Il est similaire au mécanisme INCLUDE. |
Notes et références
[modifier | modifier le code]- (en) « Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 », Request for comments no 7208,
- Voir aussi la RFC 7372 section 3.2.
- Normalisation de SPF
- (en) « RFC 7208 », sur IETF,
- (en) « Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 », Request for comments no 4408,
Voir aussi
[modifier | modifier le code]Articles connexes
[modifier | modifier le code]Liens externes
[modifier | modifier le code]- (en) openspf.org Le site officiel
