MirabellugWiki:SPF

SPF : Sender Policy Framework

Le contexte

J’aimerai vous faire découvrir SPF, une initiative visant à diminuer le nombre de spam dit forgé. En fait, un spam forgé est un mail envoyé avec une adresse qui n’appartient pas à l’expéditeur réel du message. Je m’explique :

Monsieur X a une adresse monsieurx@monprovider.com
monprovider.com vous fournit un serveur SMTP permettant d’envoyer des emails
maintenant, Monsieur Y, qui n’est pas client chez monprovider.com, va créer un mail de toute part, ayant pour expéditeur monsieurx@monprovider. et l’envoyer à votre adresse avec un serveur SMTP quelconque
Le destinataire (votre adresse email) étant correct pour le serveur SMTP destination, le mail sera accepté et délivré dans votre boîte aux lettres

Aujourd’hui, rien n’empêche ce comportement. Ainsi, bon nombre de spammeurs peuvent envoyer des mails à travers des relais ouverts, en utilisant des adresses sources forgées, et celà en toute impunité. Cette méthode permet notamment d’envoyer en masse des emails en changeant l’expéditeur à chaque email, évitant ainsi d’être blacklisté au niveau d’un système antispam.

Sender Policy Framework

L’idée derrière SPF consiste à empêcher une personne d’utiliser un nom de domaine particulier avec n’importe quel serveur SMTP. Pour cela, SPF souhaite associer à un domaine particulier, un ensemble de serveurs autorisés à envoyer des mails pour ce domaine.

Si on reprend l’exemple précédent, monprovider.com pourrait déclarer que seul le serveur smtp.monprovider.com est sensé envoyer des mails pour le domaine monprovider.com. Ainsi, si on reçoit un mail d’une adresse en @monprovider.com, mais qu’en regardant les entêtes, on s’aperçoit que le mail n’a pas été envoyé depuis smtp.monprovider.com, on peut être sûr à 100% que c’est un mail illégitime.

L’implémentation

En pratique, comment ça fonctionne ? La solution se base sur les serveurs DNS, et elle doit être implémenté à la fois par les administrateurs des zones, et les administrateurs des serveurs webs.

Au niveau des zones DNS, il suffit de déclarer dans la zone à protéger un enregistrement de type TXT, contenant une chaîne de caractères normalisée, qui va indiquer quels serveurs sont autorisés à envoyer des mails pour ce domaine. Pour l’exemple précédent, la ligne ressemblerait à :

v=spf1 ip4:smtp.monprovider.com

La norme est très complète, elle permet notamment de définir des includes, ou des références dans la déclaration de l’enregistrement. Elle permet aussi de définir un pointeur IN A résolvant vers l’ensemble des IPs autorisées à relayer des mails pour ce domaine, etc … Je vous invite à lire les liens à la fin de l’article.

Du côté du serveur de mail, il suffira alors de vérifier à la réception d’un mail, que l’adresse du serveur de l’envoyeur fait parti des serveurs autorisés. Si ce n’est pas le cas, il est alors tout à fait possible de supprimer cet email sans état d’âme.
Efficacité et conclusion

Bien sûr, pour que ce système soit efficace à 100%, il faudrait que tous les personnes possédant un domaine, et toutes les personnes administrant un serveur de mail implémentent ce procédé. Dans la pratique, c’est loin d’être le cas, même si ce principe est de plus en plus présent. Pour savoir si un domaine gère SPF, il suffit de taper la commande suivante :

dig aol.com TXT <.~.SNIP.~.> ;; ANSWER SECTION: aol.com. 300 IN TXT “spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all” aol.com. 300 IN TXT “v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all” <.~.SNIP.~.> ;; Query time: 63 msec ;; SERVER: 192.168.42.125#53(192.168.42.125) ;; WHEN: Mon Sep 24 15:33:19 2007 ;; MSG SIZE rcvd: 503

Je l’ai moi même mis en place sur mes domaines ainsi que sur mes serveurs webs. L’avantage de cette méthode, c’est que rien ne vous empêche de l’implémenter en partie, ou juste pour tester. En effet, vous pouvez déclarer un enregistrement qui renverra des softfail, ainsi les mails ne sont pas réellement rejetés par les destinataires. Ou alors, au niveau de votre serveur mail, vous pouvez regarder l’enregistrement spf, mais faire que du loggue. Pour ma part, je l’ai activé à la fois sur mes domaines et sur mes serveurs webs, et sur une journée typique :

Nombre total de mail traité par SPF : 330
none (le domaine ne gère pas spf) : 211
softfailed (le domaine gère le spf mais juste en test) : 27
pass (le domaine gère le spf et le mail est valide) : 67
failed (le domaine gère le spf et le mail est non valide) : 18

J’ai donc évité 18 mails forgés, je pourrais potentiellement en éviter 27 de plus si les administrateurs des domaines retournant des softfail activaient réellement leur politique, et il y a quand même 2/3 des domaines qui ne gèrent pas encore le SPF.

Qu’attendez-vous pour activer SPF sur votre domaine, c’est juste un petit enregistrement dans le DNS qui pourrait mener la vie dure aux spammeur ! Le site de l’association OpenSPF? qui réalise l’écriture et la promotion de cette norme est bourré d’informations. Vous y trouverez sûrement toutes les réponses à vos questions. Vous y découvrirez notamment des implémentations pour tous les serveurs de mails OpenSource? existant, Postfix, Exim, Sendmail, etc … Des serveurs comme Courier intègre même déjà en natif le SPF.

Site de l’association OpenSPF
Site officiel de Postfix

Le spam ne passera pas par moi !

Source : Denis' Blog