stevek wrote:
> We are currently testing SA 3.1.0 - as our installation may end up
> being quite large. For several years we have run our own dnsrbl lists
> and would like to incorporate them into SA. Most are IPV4sets, but we
> do have one RHBL list. Unfortunately, we have not been successful in
> getting the rules to fire. We have tried adding them to both a
> variation of 20_dnsbl_tests.cf and to the local.cf.
>
>
> Here is a sample of the type of rule we are loading:
>
> ## Local RBL
>
> header RLBL_OSH_RBL rbleval:check_rbl('rblos', 'rbl.onshore.com.')
> describe RLBL_OSH_RBL rbl.onshore.com
> tflags RLBL_OSH_RBL net
>
> header RLBL_OSH_RBL rbleval:check_rbl_results_for('rblos',
> '127.0.0.4')
> describe RLBL_OSH_RBL Host in rbl.onshore.com
> tflags RLBL_OSH_RBL net
>
> score RLBL_OSH_RBL 3.0
Two things:
First, rename the first grouping of header, describe and tflags to
__RLBL_OSH_RBL. Note the addition of double-underscore at the beginning.
This choice of naming is key if you don't want the base rule to fire off
with a score of 1.0 if the RBL returns anything at all.
You cannot ever have two rules with the same name. If this ever happens,
the second declaration over-writes the first. This is very much
intentional, as it allows local configurations to "patch" the default
rulesets, if they so desire, by over-writing the rule with a different
version. Basically, your setup using the same name causes the second
group of three to over-write and destroy the first three, preventing the
rule from running because there is no check_rbl call.
Second, I'd also suggest changing "check_rbl_results_for" to
"check_rbl_sub". check_rbl_results_for is deprecated, and present for
backward compatibility only.
>
> spamassassin -D --lint shows no errors; however the rules don't seem
> to get called, or fire when we send a test mail from a host listed in
> the RBL. Other dnsrbls -- ie. spamcop, sorbs -- seem to work fine.
>
>
> Any help would be appreciated.
YW.
