Journal SPF, ça marche !

Posté par Thomas Bigot le 11 octobre 2008 à 18:43.

Étiquettes : aucune

oct.

2008

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. 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
Valider ses enregistrements DNS : http://www.kitterman.com/spf/validate.html
Une dépêche linuxfr : http://linuxfr.org/2004/02/18/15467.html

# url

Posté par Rémi baudruche le 11 octobre 2008 à 20:12. Évalué à -2.

http://www2uucpssh.org./

on dirrai qu'il y a une erreure critique dans l'url...
- [^] # Re: url
  
  Posté par TheFloZ le 11 octobre 2008 à 20:19. Évalué à 8.
  
  la bonne url semble être http://www2.uucpssh.org/
# Spambots

Posté par Larry Cow le 11 octobre 2008 à 21:22. Évalué à 5.

La faiblesse de ton système, c'est qu'un spambot tournant sur une machine hébergée chez Free/Proxad pourra émettre en ton nom sans problème. La probabilité que ça arrive est peut-être faible dans ce cas précis, mais elle peut augmenter facilement (notamment si tu as besoin d'envoyer des mails depuis Orange, ou autre).

L'idée, si je me souviens bien (j'ai pas touché à SPF depuis un moment), ça serait plutôt de n'autoriser que ton serveur (ou éventuellement tes MX supplémentaires si besoin), et c'est marre. Pour poster depuis un réseau tiers, tu passes par ton SMTP (via SMTP/TLS, par exemple).

Enfin ça fait plaisir de voir que ça commence à être pris en compte : quand j'avais joué avec ça, on nous disait que ça finirait par être utile, mais personne de sérieux ne les vérifiait, ces fichus enregistrements SPF.
- [^] # Re: Spambots
  
  Posté par Dup (site web personnel) le 11 octobre 2008 à 22:23. Évalué à 1.
  
  Non seulement ca avance mais ca devient un standard, en effet au niveau DNS il est maintenant conseillé d'ajouter aussi un champ SPF en plus du champs TXT ;) (faut un bind 9.5 mini je crois)
  
  Me semble que chez hotmail ca gère aussi le SPF, donc si chez crosoft on le prend en compte ca semble bénéfique pour son adoption rapide.
- [^] # Re: Spambots
  
  Posté par jeffcom le 12 octobre 2008 à 03:39. Évalué à 2.
  
  La faiblesse de ton système, c'est qu'un spambot tournant sur une machine hébergée chez Free/Proxad pourra émettre en ton nom sans problème.
  
  Exactement, le mieux, si on dispose d'une ip fixe chez free est de personnaliser son reverse dns avec un sous-domaine de son domaine, et d'inscrire dans le spf que seule cette machine, ou ce domaine, peut envoyer des mails pour le domaine.
  
  Je ne sais pas si on peut personnaliser le reverse chez d'autres fai (Orange, Neuf/SFR...)
  - [^] # Re: Spambots
    
    Posté par ohmer le 12 octobre 2008 à 06:34. Évalué à 1.
    
    C'est pas grave le reverse, tu peux autoriser une ip static explicitement avec SPF.
    - [^] # Re: Spambots
      
      Posté par jeffcom le 13 octobre 2008 à 00:31. Évalué à 2.
      
      oui mais c'est plus simple, si on change de fai par exemple ou simplement ou simplement qu'on change de serveur de mail (oui je sais c'est paresseux comme système...)
- [^] # Re: Spambots
  
  Posté par Thomas Bigot le 12 octobre 2008 à 14:20. Évalué à 5.
  
  Oui, mais je recevais des centaines de bounces de mails envoyés depuis des machines de l'Europe de l'Est. Et aucune depuis la France.
  
  En plus, il faut savoir que des spambots chez free, il n'y en a plus trop, depuis qu'ils ont bloqué la sortie du port 25 par défaut (c'est débrayable avec une simple option dans l'interface d'administration).
  
  Donc même si ça n'empêche pas totalement que du spam soit envoyé avec mon domaine dans le champ expéditeur, ça en diminue fortement le nombre, et pour mon cas, ça a stoppé complètement la nuisance.
  
  Ça ne me semble pas un problème d'ajouter un FAI et une université français dans les serveurs autorisés sachant qu'ils seront très certainement beaucoup plus réactif qu'un sombre propriétaire de bloc d'IP en Russie en cas d'abus.
# moi aussi :-)

Posté par PLuG le 11 octobre 2008 à 22:35. Évalué à 4.

C'est vrai qu'on ne fait peut-être pas assez de pub autour de SPF, mais je l'ai mis en place il y a plus de deux ans avec un effet IMMEDIAT sur le nombre de spams reçus ...
SPF ça marche, et c'est pas nouveau ... ça fait des années que c'est ESSENTIEL à configurer sur vos serveurs SMTP.
# À première vue...

Posté par Sébastien Le Ray le 12 octobre 2008 à 12:17. Évalué à 4.

Oui, à première vue, SPF c'est super.
Toutefois l'utilisation de ptr est déjà une faiblesse en soit (tu possèdes peut être toto.com mais tu ne contrôles aucun reverse, après je sais pas si dans la gestion des SPF on vérifie IP => reverse => IP pour éviter les faux).
Et surtout, le jour où tu as une machine qui forwarde vers ton domaine, il faut l'ajouter à ton SPF, on voit que ça devient vite ingérable (la gestion des forwards, cf. http://www.openspf.org/FAQ/Forwarding). Il faut passer par des gros hack "je réécris l'adresse, je maintiens un cache des adresses que j'ai réécrites des fois que ça bounce, un merdier pas possible).
Donc oui ça semble être une bonne idée, non en pratique c'est pas top (je sais j'ai fait comme toi quand j'ai découvert ça et après j'ai réfléchi aux forwards, j'ai cherché et j'ai eu la confirmation de mes craintes).
- [^] # Re: À première vue...
  
  Posté par PLuG le 12 octobre 2008 à 12:35. Évalué à 3.
  
  A mon avis pour la majorité des cas (des domaines possédés par des entreprises qui maitrisent les passerelles SMTP par lequel sortent leurs emails), le SPF rend complètement service. Meme avec des employés "nomades", il suffit de les forcer à utiliser les infrastructures habituelles de l'entreprise (en gros ils montent d'abord un VPN d'entreprise ...).
  
  Peux-tu nous dire dans quels cas ces forward sont necessaires pour un domaine ?
  - [^] # Re: À première vue...
    
    Posté par Sébastien Le Ray le 13 octobre 2008 à 09:35. Évalué à 2.
    
    J'ai des dizaines de clients qui ont 0 boîtes mails sur leur domaine, uniquement des forwards vers des boîtes.
    Si toto@pouet.com envoie un message à un de ces clients, mon serveur mail le forward et expédie donc un mail avec une adresse en pouet.com. Si le SPF de pouet.com ,indique que seules les machines en pouet.com (ou certaines adresses) peuvent envoyer des mails, alors mon mail peut être considéré comme spam/invalide...
    - [^] # Re: À première vue...
      
      Posté par PLuG le 16 octobre 2008 à 01:34. Évalué à 1.
      
      C'est donc toi qui possede le MX des domaines de tes clients ...
      donc il suffit que tes clients n'implémentent pas SPF chez eux, et que toi tu implémente SPF pour les protéger ... non ?
      Eux de leur coté n'ont plus qu'a accepter uniquement les mails relayés par toi ...
      - [^] # Re: À première vue...
        
        Posté par Sébastien Le Ray le 16 octobre 2008 à 09:33. Évalué à 1.
        
        Généralement les forwards sont vers orange & Cie, je pense pas qu'ils attachent des masses d'importance à ce que je pourrais leur dire :)
        
        Sinon oui quand y a un contrôle de bout en bout, il faut whitelister la machine qui forwarde ou passer par des trucs gruiks pour réécrire l'adresse ce qui démontre que le protocole est foireux et qu'ils n'ont pas pensé (ou volontairement écarté) ce cas de figure lors de sa conception
# 2 choses

Posté par FRLinux (site web personnel) le 13 octobre 2008 à 01:27. Évalué à 1.

J'utilise SPF depuis près de 3 ans, et c'est vrai que ca avoine bien les mammouths.

1/ ptr : oui et non. Le PTR peux poser deux problèmes, le premier étant le contrôle du reverse (abordé plus haut). Le second étant la charge de requêtes sur l'interrogation des mails. Sur un petit domaine à une centaine de mails par jour ça va mais à partir du millier, ca peux devenir paralysant.

2/ ipv6 : on en parle pas assez mais SPF comprends aussi ipv6 par le simple champ ip6: donc pensez à l'utiliser si vous avez une adresse, surtout que celle-ci est généralement statique :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.