On Fri, 2008-10-24 at 15:24 +0200, Francois Petillon wrote:
> Jerome Martin wrote:
> > Juste pour rebondir, pas d'augmentation brutale non plus de mon coté.
> > Je te suggère le greylisting pour alleger la charge de ton
> > anti-{spam,virus}, ca a radicalement changé la donne sur nos serveurs de
> > mails.
>
> Le greylisting me semble être une fausse bonne idée et surtout, à
> l'instar du P2P (tiens, un troll pour le vendredi), un comportement asocial.Youpi. Mais cétait deja parti en sucette de toutes facons, qu'est-ce qui m'a pris de vouloir suggerer quelque chose a quelqu'un .... > Pourquoi serait-ce une fausse bonne idée et un comportement asocial ? > Déjà, il est très facilement contournable : il suffit de mettre en place > des outils simples pour regénérer des séquences d'envois identiques > (emetteur/destinataire/IP) pour contourner le greylisting. De fait, > c'est déjà utilisé et il est assez fréquent de voir des spams arriver en > multiples exemplaires sur un même compte. Oui. Mais en restant pragmatique, en pratique, ca fonctionne. Ca ne fonctionnera pas eternellement, mais ceux qui croient au père noel ne devraient pas se lancer dans la lutte anti-spam. > Et là, on voit tout de suite > l'effet pervers : les domaines qui ne l'implémentent pas se prennent une > volumétrie de spam plus importante du fait de ces doublons (bref, les > domaines tiers en payent les conséquences). Exact. Tout comme les voitures portant un autocollant "attention alarme" provoquent une augmentation du risque pour les voitures sans alarme. Comme une maison avec des barreaux aux fenetres pousse les cambrioleurs vers la maison d'a coté, non protégée. Dans un monde parfait, ni barreaux, ni alarmes. Mais nous sommes dans la vraie vie. La démagogie est convaincante car elle exploite un biais cognitif humain, mais comme la peur, elle n'evite pas le danger, ni ne résoud les problèmes. > De plus, lorsqu'un serveur SMTP tente d'envoyer un mail sur votre > domaine, la première tentative d'envoi (celle qui se fait alors que le > mail est susceptible d'être encore dans le buffer-cache) est refusé. Sur > la tentative suivante, les probabilités pour que le mail ne soit plus > dans le buffer-cache sont pour le coup beaucoup plus importantes. Exact. Par contre, les tentatives suivantes (selon l'implementation de greylisting, les tentatives suivantes ayant le meme couple expediteur/IP, le meme tuple expediteur/recipiendaire/IP, etc.) ne sont pas impactées. Et ce que l'on pert d'un coté (expedition), on le gagne au centuple de l'autre (CPU bouffé par l'AV, connexions aux RBL, etc.). Bref, au total, je ne sais pas si l'on est a l'équilibre, mais c'est un calcul trop complexe pour etre simplifié comme cela. > Donc, > non content de représenter une charge CPU plus importante pour > l'emetteur (sans contre-partie pour lui) La contre partie existe dans certains cas. Certains de mes clients ayant des zombies dans leur réseau (ca arrive meme aux meilleurs :-) ) ont ainsi évité pas mal de soucis. > , vous augmentez également la > charge en IO disque. Si tous les domaines mettaient en place ce type de > mesure, il faudrait faire un upgrade conséquent sur les serveurs SMTP > dont le traffic est non négligeable (et vous faites donc une seconde > fois porter le coût de votre protection à des tiers). Encore une fois, si l'on globalise la mesure, en supposant qu'elle reste efficace (ce qui ne serait pas le cas je pense), le gain en CPU/reseau des messages a filtrer en moins (AV, etc...) est bien supérieur au simple miss de cache disque coté expediteur. Faut pas charrier, relire un mail sur disque reste moins couteux que le scanner, en faire un checksum, se connecter à 5 RBL et lire leur reponse, passer a la moulinette d'un filtre bayésien, etc... Cordialement, Jérôme Martin | LongPhone Responsable Architecture Réseau 122, rue la Boetie | 75008 Paris Tel : +33 (0)1 56 26 28 44 Fax : +33 (0)1 56 26 28 45 Mail : [EMAIL PROTECTED] Web : www.longphone.com
<<attachment: stock_smiley-1.png>>
