On Thu, 06 Sep 2007 10:11:38 -0700
JT Moree <[EMAIL PROTECTED]> wrote:
> > My idea would be that there are only two things that can be whitelisted:
> > connections and transactions. On the base of what logic, and at what
> > stage, is up to the plugin, but if the whitelist flag is set, any DENY*
> > return value from subsequent plugins' hooks should be treated as DECLINED.
>
> The real question is what does whitelisting mean? This is one thing it
> can mean. It could also mean that a plugin MUST return DECLINED when
> the whitelist flag is set. Your case allows for OK. My case does not.
> (I kinda like yours better).
[...]
> The problem seems to be that whitelisting means different things to
> different plugins. I started thinking of creating a whitelisting
> subsystem where each plugin could share in a global whitelist or have
> one of it's own.
>
> If we can narrow the definition, scope, and effects of 'whitelisting' it
> may then be possible to implement something that all/most plugins could
> use.
I'm not really happy with the all or nothing approach of whitelisting /
blacklisting. There should be a score based whitelist, which can be
fine tuned by the admin.
The current dnsbl plugin returns DENY if the client is in one of the
given lists, but there are some lists I trust more than others. I'd
like to see something where I can set a score right below the threshold
for (e.g.) the geoip plugin and then add the scores from the dnsbl
plugin. "Whitelisted" clients can be given a large negative score, that
this client never reaches the threshold of being blocked.
Hanno
