"Les spammeurs sont très bon a signer leur mails et utiliser SPF"
Oui, mais s'ils signent ou SPF, alors il devient très facile de les identifier et une fois identifier, hop, direct dans la RBL, non ? Je ne connaissais pas le domain tasting. Effectivement, ca n'aide pas, mais je pense que cela joue à la marge : quand on voit le chiffre d'affaire que peut rapporter une campagne de spam, l'acquisition, même à long terme, d'un nom de domaine ne représente pas un facteur suffisamment dissuadant. "Il fait un SFP qui dit "accept tout de partout" :D" Autant dire que le SPF record qui accepte tout devrait être considéré comme pire que l'absence de SPF record, tant il n'y a aucune bonne raison de le configurer ainsi. "Et vu que SFP casse le revoie de mail beaucoup de domaines n'auront jamais de SPF - car personne dans la SME comprends ce que c'est et comment ca marche." Le SPF casse le renvoi de mails ? Je ne comprends pas en quoi. Pour ce qui est des SME, si elles ne comprennent pas et ne font pas l'effort, elles prennent un prestataire, et si elles veulent faire elles-même, de toute facon, à l'heure actuelle, elles doivent déjà faire des prouesses pour comprendre la liste des "bidouilles" qu'il faut faire pour se faire accepter ses mails par untel ou untel (hotmail au hasard). Je pense donc que ca ne change pas le problème. "Ca aide spam assassin - c'est ou que je commence la thread sur le cout en CO2 du spam ?? http://motherjones.com/blue-marble/2009/04/spams-co2-emissions Tu veux vraiment eviter autant de spam que possible aux MX car l'analyse du contenu ca coute en ressources (machines, etc.)" Bof, si on place le filtrage par réputation avant le filtrage par SPF/DKIM, on économise déjà bcp de traitement. Je sais bien que le SPAM produit indirectement bcp de CO2, mais si ces pratiques coutent nettement moins cher que les pseudo calculs statistiques d'outils comme SPAM Assassin qui vérifient 15000 règles qui ne sont pas spécialement économes (si on était vendredi, je m'interrogerai sur le pourquoi de Perl, vis à vis des performances =)) Je n'ai pas d'action chez Cisco, mais les Ironport faisait du bon boulot à ce niveau, du temps où j'en avais dans les mains. "Hum, je me creuse la tete mais quelle raison peut on avoir de ne pas mettre de rDNS ou un helo correct sur un serveur de mail destiné à communiquer avec l'extérieur ?" Disons qu'en soit, pouvoir résoudre une vérification reverse-forward est une bonne idée. Ce qui est problematique, c'est quand un fournisseur de service te demande de résoudre reverse-forward + reverse et ehlo = domaine d'expédition, puisque plusieurs A record peuvent pointer sur la même IP alors qu'on n'a qu'un seul PTR. J'ai déjà eu le cas. "Je suis un peu d'accord, cela dit les usagers/clients veulent une 'solution' la maintenant, pas dans 10ans :-) Cela dit rien n'empeche de reflechir à la solution pour dans 10ans." Sans vouloir troller, ca me rappelle la discussion sur le Green IT : Si personne ne lance la machine, elle ne démarrera pas. On a l'avantage que SPF, DKIM et les RBL existent depuis déjà des années. J'ai juste souvent le sentiment (je ne pointe personne de précis du doigt en disant ça) que certains aiment bien ces bidouilles et aiment en inventer d'autres parce que ca les rend savant (= business), et que ca permet de palier temporairement au spam. Florian MAURY --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
