> De plus, les RBLs faisant baisser considérablement la charge de nos machines, > c'est moi qui ne comprend pas pourquoi tout le monde, ou presque, et en train > de cracher dessus. Si > demain, vous utilisez les RBLs, ce ne sera plus un probleme.
Si demain, tout le monde utilise SPF, et que tous les serveurs SMTP
recquièrent l'utilisation de SPF, alors ça n'est plus un problème non
plus :)
> Je compte aussi utiliser dans peu de temps le système de greylist
Attention : si demain, tout le monde utilise le greylist, alors le
greylist ne sera plus efficace du tout puisque les spammeurs le
contourneront. (ça commence d'ailleurs a être le cas). Il suffit
d'embarquer un client SMTP capable de gérer un 2è envoi.
Au passage, le greylist n'est pas utilisable à très grande échelle, à cause
du nombre de triplets {IP, adresse source, adresse cible} générés.
> qui me semble aussi relativement prometteur et efficace. Je pense qu'en le
> positionnant avant les RBLs, on
> optimise bien la chaine: à la fois réduction du spam et réduction de la
> charge.
J'ai pu expérimenter en production une solution intéressante de couplage
de RBL et de greylist, mais pas comme tu dis :
Ici les clients SMTP figurant dans les RBL sont greylistés et non pas
blacklistés.
Cela réduit l'impact négatif de faux-positifs (ils sont "juste"
retardés), et ne réduit pas (ou peu) l'efficacité des RBL.
Malheureusement je constate une augmentation des spams résistants au
greylisting. Pas encore catastrophique cependant.
--
Raphaël Marichez
[EMAIL PROTECTED]
pgp3RknlEKTkX.pgp
Description: PGP signature
