Défaut du SPF

A première vue le système SPF est un moyen efficace de lutter contre le spam: on indique (via les DNS) quels sont les serveurs autorisés à envoyer un email pour un domaine donné.
Par exemple, on indique que seul smtp.company.com et smtp2.company.com sont autorisés à envoyer du courrier en @company.com via la ligne suivante ajoutée dans le DNS gérant company.com :

company.com descriptive text "v=spf1 a:smtp.company.com a:smtp2.company.com ~all"

Par exemple, Gmail gère très bien le SPF, on le voit via cette ligne dans les entêtes emails lorsqu’on y envoie un email :

mx.google.com; spf=softfail (google.com: domain of transitioning chris@company.com
does not designate 213.251.138.179 as permitted sender)

ou

mx.google.com; spf=pass (google.com: domain of chris@company.com
designates 12.123.21.80 as permitted sender) smtp.mail=chris@company.com

Aujourd’hui je me suis rendu compte que GMail considère comme échoué le teste SPF si on envoi vers une email qui n’est qu’une redirection (si courant dans le monde des PME).
Donc si j’envoie un courrier à chris@gonzofamily.com , comme c’est une redirection OVH vers mon email gmail, gmail pense que le courrier provient d’OVH. Le serveur mail de ce dernier n’est pas autorisé dans la ligne SPF pour le domaine @company.com, le test échoue.

Et voila comment j’augmente mes chances de voir mon email considéré comme indésirable alors qu’au départ je croyais bien faire.

Une solution semble de ne plus utiliser l’option disant que seuls ces serveurs sont autorisés à émettre du courrier pour ce domaine, mais nous perdons alors un des meilleurs moyens de lutter contre le spam. J’ai du donc remplacer

v=spf1 a:smtp.company.com a:smtp2.company.com ~all

par

v=spf1 v=spf1 a:smtp.company.com a:smtp2.company.com ?all

J’imagine qu’alors nos emails provenant de smtp.company.com sont considérés comme légitimes plus facilement, mais que s’ils proviennent d’autre part ce n’est pas pénalisant.

PS du 22/06/2008 : pour en savoir plus sur le fonctionnement d’SPF cette url est vraiment complète : http://www.openspf.org/SPF_Record_Syntax

4 thoughts on “Défaut du SPF”

  1. j’obtiens
    neutral (google.com: 213.251.138.179 is neither permitted nor denied by domain of chris@company.com) client-ip=213.251.138.179;

    avec l’ouverture que j’ai choisie lorsqu’il y a un passage par un serveur tier. Neutral c’est mieux que failed

  2. oui sauf qu avec un ? a la place du ~ tu autorise tout le monde a envoyer du mail en @tondomaine.tld , le ? c est tres mal , le ~c est mal, le – c’est bien, mais pour ca faudrait démocratiser le SMTP AUTH … ce qui n a rien de difficil d ailleur …

  3. je pense que tu as mal compris l’article ou alors nous ne nommons pas SMTP AUTH la même chose. Si SMTP AUTH c’est le fait de pouvoir envoyer ton courrier de n’importe où (maison, hotel, bureau…) toujours par le même serveur grave à une authentification alors tu as mal compris l’article.
    Ce que je dis c’est que lorsqu’on écrit à quelqu’un qui fait une redirection, par exemple mon email chris@gonzofamily.com chez ovh, ovh reçoit sur son serveur puis renvoie vers mon compte gmail. Gmail ne voit plus le courrier arriver d’un serveur autorisé par SPF mais par OVH…. c’est pour ça que j’ai été obligé de mettre un ?
    Il faut noter qu’énormément de PME utilisent les redirections…
    Le soucis est du coté du serveur qui reçoit l’email, il aurait fallu qu’il remonte tous les serveurs au lieu de ne regarder que le dernier relais..

  4. en tout cas merci Julien pour ces précisions qui m’ont amené à tout étudier sur ce lien : http://www.openspf.org/SPF_Record_Syntax
    Le SPF est une excellente chose très bien pensée, peut être ai je soulever un soucis qui ne concerne que son utilisation par les serveurs, ils devraient ne pas regarder que le dernier serveur ayant effectué le relais

Leave a Reply

Your email address will not be published. Required fields are marked *