Re: [Httpbl-beta] Getting help

[David W. <djw...@gm...>]

James,
   Thanks for the analysis.

   I was too tired to address the problem which started this thread and
should not have replied.  You are right that the HTTPBLRBLReqHandler I
pointed out works only with Search Engines and should be there.  I probably
confused a lot of people with my erred response.

   I am probably still too tired to fix the issues you brought up in
tonight's revision of the code.  The intention of the HTTPBLRBLReqHandler
directives was to create a fine-grained ruleset for handling httpbl
responses.  In any case, I have almost finished a wizard/webpage to simplify
the creation of HTTPBLRBLReqHandler directives.  Whether the decision is to
keep the category bitsets working the way they do (ANDed bits) or to change
it to ORed bits, the wizard/webpage will create the correct directive code.
I will keep the mailing list updated if I make a large change like that.

Dave



On 5/30/07, James Beckett <jmb...@ha...> wrote:
>
> David Wortham wrote:
> >    You want to remove the line "HTTPBLRBLReqHandler 255:0-255:0-255:0
> > allow" from your configurations if you want to filter out any IPs.  This
> > line explicitly allows all IPs access to any page in this directory
> > before any other checks are done.
>
> David,
>
> This is the "allow search engines" line, isn't it?  Throughout the
> documentation this is given as an example to match addresses of
> known search engines and permit them, ahead of deny lines for
> other offender categories (with the catch-all "255" given as the
> category bitmask).
>
> The documentation isn't explicit about how bitset tests are
> performed, but the natural reading would seem to be that the
> category bitset in the config line is ANDed with the returned
> category value, and if anything remains, match the rule, with 0 as
> a special case to match 0 alone - thus the example
>
> HTTPBLRBLReqHandler 255:0-30:0-255:255 deny
>
> picks up responses with *any* category bit set. However, I've had
> a look at the tests in the code, and it seems the logic is quite
> different - *all* '1' bits given in the bitset must match the returned
> category value -
>
> static int does_bitset_accept_value(unsigned int bitset, unsigned int
> value)
> {
>    return ((bitset&value) == bitset);
> }
>
> which gives these corollaries:
>
> * a "0" in the rule always matches, giving the counterintuitive
> and counter-documentation behaviour you describe above
>
> * there is no way to match iff octet4==0 at all, so you *cannot*
> make a rule for matching search engines
>
> * a "255" (also as given in the examples) is unlikely to match,
> as it includes as-yet-reserved bits
>
> * there is no way to say "harvester OR spammer" in a single rule,
> as 2+4 means "this IP is flagged both as harvester AND spammer"
>
> * Thus you *cannot* make a rule with a catch-all on the category.
>
> I humbly submit that this logic is flawed, and doesn't make for
> sensible configurations. I think the special-case of "0" is a
> recipe for much confusion.
>
> At present I have this in my httpBL.conf, which seems to have the
> required effect (but can't handle search engines):
>
>    HTTPBLDefaultAction     allow
>    # ...
>    HTTPBLRBLReqHandler 255:0-255:0-255:1 deny
>    HTTPBLRBLReqHandler 255:0-255:0-255:2 deny
>    HTTPBLRBLReqHandler 255:0-255:0-255:4 deny
>    HTTPBLRBLReqHandler 255:0-255:0-255:8 deny
>
> (The HTTP method bitset test is performed with explicit and/or
> comparisons, so doesn't suffer this problem. Actually, it suffers
> an entirely different problem, which I'll leave for another mail)
>
> cheers,
> James
> --
> James Beckett <jm...@ha...> <http://www.hackery.net/jmb/>
> F601 C085 1482 B92A C812  556C A985 1497 209B 4E65
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Httpbl-beta mailing list
> Htt...@li...
> https://lists.sourceforge.net/lists/listinfo/httpbl-beta
>