> There seems to be a full-external check of bb.barracudacentral.org,
> which I think was mistakenly not removed when bug 5984 was closed and
> RCVD_IN_BRBL_LASTEXT was implemented

Indeed.

> Neither the 'brbl' set nor the subrule are used anywhere I can find,
> so this seems to be a waste of bandwidth and so on.

Found two more vestiges of the __RCVD_IN_BRBL rule.
Replacing __RCVD_IN_BRBL with RCVD_IN_BRBL_LASTEXT throughout:

trunk:
  Remove __RCVD_IN_BRBL
  Sending rulesrc/sandbox/jhardin/20_misc_testing.cf
  Sending rulesrc/sandbox/jm/20_bug_5984.cf
  Sending rulesrc/sandbox/khopesh/20_khop_bl.cf
Committed revision 1150715.


The DNSBL_INDIRECT, DNSBL_INDIRECT_UNSAFE and DNSBL_INDIRECT_UNSAFE_2
in sandbox/khopesh/20_khop_bl.cf might need reconsidering, as they
were using both the __RCVD_IN_BRBL as well as the RCVD_IN_BRBL_LASTEXT.

(In reply to comment #0)
> There seems to be a full-external check of bb.barracudacentral.org, which I
> think was mistakenly not removed when bug 5984 was closed and
> RCVD_IN_BRBL_LASTEXT was implemented:
> 
> ifplugin Mail::SpamAssassin::Plugin::DNSEval
> header __RCVD_IN_BRBL   eval:check_rbl('brbl','bb.barracudacentral.org')
> tflags __RCVD_IN_BRBL   net
> endif

That was the format we used for other DNSBL rules like __RCVD_IN_ZEN and __RCVD_IN_SORBS, though both of those rules have check_rbl_sub() calls on those lookups that pay attention to non-lastexternal whereas the only dependencies of non-lastexternal __RCVD_IN_BRBL were in my sandbox.


(In reply to comment #1)
> The DNSBL_INDIRECT, DNSBL_INDIRECT_UNSAFE and DNSBL_INDIRECT_UNSAFE_2
> in sandbox/khopesh/20_khop_bl.cf might need reconsidering, as they
> were using both the __RCVD_IN_BRBL as well as the RCVD_IN_BRBL_LASTEXT.

The problem with those is that some quirk in the mass-check system prevents running certain rules too many times (presumably due to being deemed too expensive).  A large number of my DNSBL tests have fallen into this category (another example is RCVD_IN_SPAMCOP, which limits hits to last-external).

The last net run (with decent volume) was 20110709 (today's net run at http://ruleqa.spamassassin.org/20110725-r1150068-n has only 3254 hams at the moment, so I assume it is still processing).  In that run, the only non-shipped DNSBL rule (or dependency) in 20_khop_bl.cf that was evaluated was T_RCVD_IN_NIX_SPAM (which we've already determined is incompatible with our testing process).

http://ruleqa.spamassassin.org/20110709/?srcpath=20_khop_bl.cf


Does anybody know of a good way to dig back to the last net run that had data for these rules?


As Mark suspected, the removal of __RCVD_IN_BRBL makes my DNSBL_INDIRECT_* rules completely useless since they were there primarily to test the differences between __RCVD_IN_BRBL and RCVD_IN_BRBL_LASTEXT (Mark's edit turned that portion of these rules into A && !A).

The two options are:

1. Scrap the DNSBL_INDIRECT_* rule experiments.
2. Return __RCVD_IN_BRBL as "nopublish" (assuming no issues via bug 6527).
3. Gimp the DNSBL_INDIRECT_* experiments by removing the BRBL portion.

For now, I've checked in #3 as r1150904.  #2 is ready to go (commented in aforementioned commit).

Moving all open bugs where target is defined and 3.4.0 or lower to 3.4.1 target

This is a rules discussion so changing to undefined target.

No variant of RCVD_IN_BRBL is being published, all mentions in sandboxes are commented out. This is no longer a live issue that anyone cares about.