Sender Policy Framework
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
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 pour le 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
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 ne 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
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
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
- (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
Liens externes
- (en) openspf.org Le site officiel