From: Michel B. <mi...@bo...> - 2005-06-29 15:24:31
|
Please don't take this as the start of a troll-war Lionel, I just want to= =20 answer your points... Le Mardi 28 Juin 2005 23:00, Lionel Bouton a =E9crit : > > SQLgrey already does more than pure greylisting. It uses a specific > whitelist and AWLs, 1.7.x even does throttling. All this _is_ pure greylisting. It is intelligent greylisting, but it is = only=20 based upon whether or not hosts are able to reconnect for resending=20 temporarily rejected messages, with AWLs "memorizing" it automatically, a= nd=20 throttling avoiding that a machine that does not retry fills up a connect= =20 table with hundreds or thousands of dummy "first tries". And the manual whitelists are just here to be able to let pass some rare=20 "known good" hosts which couldn't pass greylisting otherwise, because the= y=20 don't behave as they should (they are "good" hosts, but they violate RFCs= ). This is only greylisting. Good and intelligent one. > Whatever will be added=20 > to SQLgrey will try to help fine-tune the greylisting process more or > less in the same way: > - either try to avoid greylisting "know good" clients as is done today, > - maybe discriminate among senders, enforcing different reconnect delay > or reconnect tries before they enter AWLs and/or are allowed to pass. Then what you use for this "discrimination" clearly makes you step out of= =20 greylisting, because you will take into account information of different=20 kinds, that have nothing to do with greylisting itself. > The keyword here is *combination*: if we can combine other informations > about the connection to help fine-tune the greylisting process I don't believe that those kinds of "combinations" will make the greylist= ing=20 any better. Only heavier, more complicated, more bug-prone... > *and* it is impossible to do with Postfix alone or really difficult (Mi= chel, > I don't want to awaken another thread but you are the one asking for "M= AIL > FROM:" whitelists in SQLgrey That's true. When you build a filter of any kind, making provisions for=20 (manual) exceptions that should be allowed thru seems to me to stay withi= n=20 the scope of the given filter. > although it is rather easy to use them with Postfix, Nope. Because if you have a series of 10 Postfix restrictions, and let's = says=20 SQLgrey comes #5, but you want to skip greylisting for a given sender, if= you=20 use to Postfix table to say "OK" for the given sender, then you don't onl= y=20 skip greylisting, but also skip the 4 following other rules, which you mi= ght=20 want to enforce. That's why it's impractical. Yes, I know, you can create specific chains of "smtpd_restriction_classes= " as=20 well, but the number of possible combinations grows exponentially as the=20 number of rules or filters you use grows. That's why I think that it makes sense that each filters makes provisions= for=20 its exceptions... > your position here surprises me...) I hope I made it clearer... > then adding code to SQLgrey makes sense (especially when SQLgrey will b= e > modular).=20 Now your position suprises me ;-) I've always seen you very reluctant abo= ut=20 adding new features or algos to SQLgrey, and very hard to convice that a=20 suggestion may be useful. It takes time and effort before convicing you t= hat=20 a given idea could be good and worth implementing. I think this is good,=20 because this way of working allows you to keep the software simple and=20 efficient, and avoid it becoming bloated with tons of more or less=20 useful(-less) features... So well, I admit this easily, even if you refuse to integrate some featur= es I=20 would like, as a sender regexp whitelist. And now I see you considering adding tons of new features that have stric= tly=20 nothing to do with greylisting, and for which the usefulness of combinati= on=20 with greylisting still needs to be precisely demonstrated (which I doubt = very=20 much). So now I am suprised by your own positions ;-) Mine is clear and simple : Let's SQLgrey be the best and more complete=20 greylisting tool out there. Let it do well everyting that relates to=20 greylisting. And don't do anything that doesn't directly relate to=20 greylisting... But of course, this is your "child", so you're the boss ;-) --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |