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)). Ce mécanisme est toutefois désuet et ne doit plus être utilisé[4]^{[source insuffisante]}.
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 28 avril 2006, 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 n^o 7208, avril 2014.
Voir aussi la RFC 7372 section 3.2.
Normalisation de SPF
, ietf.org.
(en) « Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 », Request for comments n^o 4408, avril 2006.

Voir aussi

Articles connexes

DKIM
DMARC
FCrDNS (en)

Liens externes

(en) openspf.org Le site officiel

Portail d’Internet
Portail de la sécurité informatique

Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.

[RFC-7208-t-d-1] (en) « Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 », Request for comments n^o 7208, avril 2014.

[2] Voir aussi la RFC 7372 section 3.2.

[bortzmeyer-3] Normalisation de SPF

[4] , ietf.org.

[RFC-4408-t-d-5] (en) « Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 », Request for comments n^o 4408, avril 2006.