URL: https://linuxfr.org/users/tmgo/journaux/spf-%C3%A7a-marche%C2%A0 Title: SPF, ça marche ! Authors: Thomas Bigot Date: 2008年10月11日T18:43:43+02:00 Tags: Score: 28 Ou comment ne pas recevoir des centaines de bounces pour des mails que vous n'avez pas envoyés... Comme beaucoup d’entre vous, je dispose d'un nom de domaine personnel. Je l'ai paramétré de sorte à recevoir tous les mails adressés à ce domaine (catchall). Belle aubaine pour les spammeurs qui ont trouvé là un tas d’adresses valides à qui envoyer leurs diverses... propositions commerciales. Les virus ont suivi. Puis j'ai trouvé une super parade : [http://www2uucpssh.org.](http://www2uucpssh.org.) Le filtrage des spams y est tout simplement parfait. Mais un ou des malins spammeurs ont eu l'idée d'utiliser intensivement quelques adresses (forcément valides) de mon domaine pour remplir le champ expéditeur de leurs messages. Donc depuis quelques mois, je recevais pas moins de dizaines de messages de bounce, vous savez, les messages qui vous signalent que le mail que vous avez envoyé n'a pas pu être livré, et qui répondent à de doux noms tels que : « Returned mail: see transcript for details », « Undelivered Mail Returned to Sender », « Delivery Status Notification (Failure) », « Mail delivery failed: returning message to sender »... Ces messages n’étant pas des spams, ils ne sont pas filtrés. Plusieurs solutions. La plus simple : une règle procmail qui redirige les messages selon le destinataire dans un dossier réservé. Mais il faut que le spammeur ne fasse pas d'envoi avec une adresse que vous utilisez réellement. Et ce n'est pas très satisfaisant techniquement, on continue de recevoir une grosse majorité de messages inutiles. Une autre solution est d'utiliser SPF (Sender Policy Framework). C’est un dispositif qui permet à un serveur de mail de savoir si un hôte a le droit de transmettre un message en provenance d'un domaine donné. Et c’est très efficace pour ne plus recevoir de bounces indus. En 24h, je suis passé de dizaines de messages à parfois un par jour, en ajoutant juste un champ TXT à ma zone DNS : TXT "v=spf1 ptr ptr:univ-lyon1.fr ptr:free.fr ptr:proxad.net ~all" ptr indique que je souhaite pouvoir envoyer mes mails depuis tout serveur qui résout en .mondomaine.net. ptr:univ-lyon1.fr indique que je peux aussi envoyer des mails depuis les machines de mon université. ptr:free.fr et ptr:proxad.net que les mails qui proviennent de ces domaines doivent être considéres comme légitimes également, puisque free est mon fournisseur (et proxad, le nom de son réseau). ~all signifie que des mails dont l’adresse d'expédition contenant mon domaine et étant envoyés par tout autre hôte doivent être considérés comme potentiellement illégitimes. Le tilde (~) indique un échec mou (softfail), donc le mail n'est pas vraiment rejeté. Mais c'est suffisant pour ne pas recevoir de bounces. Si on est sûr de son paramétrage, on peut utiliser un moins (-) à la place. Il existe plein d'autres moyens de spécifier des hôtes autorisés à envoyer des messages en provenance de votre domaine. On peut directement indiquer le nom d’une machine (A), ou tous les MX d’un domaine donné (MX). Voyez les documentations pour plus d’infos. En plus, ça permet potentiellement aux destinataires des spams de ne plus recevoir de messages provenant apparemment de votre domaine, s’ils n’ont pas réellement été envoyés par des machines autorisées. Par exemple, si j’envoie un mail sur une adresse google, je peux voir dans les en-têtes : Received-SPF: pass (google.com: domain of thomas.bigot@mondomaine.net designates 193.48.219.100 as permitted sender) client-ip=193.48.219.100; donc google utilise le SPF pour trier les spams. Le principe : [http://fr.wikipedia.org/wiki/Sender_Policy_Framework](http://fr.wikipedia.org/wiki/Sender_Policy_Framework) Valider ses enregistrements DNS : [http://www.kitterman.com/spf/validate.html](http://www.kitterman.com/spf/validate.html) Une dépêche linuxfr : [http://linuxfr.org/2004/02/18/15467.html](http://linuxfr.org/2004/02/18/15467.html)

AltStyle によって変換されたページ (->オリジナル) /