On Fri, 2008-10-24 at 16:23 +0200, Francois Petillon wrote: > Jerome Martin wrote: > >>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. > > Non. Pour reprendre votre exemple, les voitures portant un autocollant > "attention alarme" et les maisons avec des barreaux aux fenetres ne > suggèrent pas aux cambrioleurs d'augmenter la fréquence de leur larcin. > Ces protections se limitent à leur suggerer de s'attaquer à une proie > plus facile.
Et c'est bien ce qui se passe avec le report des spammeurs vers les serveur qui n'implementent pas le greylisting. Sinon merci de bien vouloir réexpliquer ... > > 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. > > Deux choses. Primo, ce que vous économisez de votre coté est payé par un > tiers. Oui. Et alors ? C'est la nature d'Internet, l'interdependance. > Il est difficile de parler d'équilibre alors que les pertes et > les gains ne sont pas assumés par le même acteur. Absolument pas. La preuve, je le fait tres simplement. En parlant du système global. Honnetement, à l'echelle d'un seul serveur de mail, tout cela est bien marginal. > Secundo,le greylisting > ne vous dédouane pas de faire du filtrage et donc de scanner les mails. Exact. Simplement j'en ai BEAUCOUP moins a filtrer/scanner. > >>, 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... > > À nouveau, le gain et les pertes ne sont pas à la charge du même acteur. > Il est donc difficile de parler d'équilibrage. c.f. plus haut. > Et oui, du fait des courbes d'évolutions de la puissance CPU et de la > capacité en IO des disques, j'ai souvent plus tendance à préférer > bouffer du CPU que de bouffer de l'IO disque (bon, reste à voir avec les > SSD si ceci ne sera pas mis à mal prochainement). Moi, je prefere bouffer du chocolat que des patates. Dans l'absolu. Sauf que si le deal est de bouffer 30kg de chocolat vs 100g de patates, je prends les patates. 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
