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.