http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3109
------- Additional Comments From [EMAIL PROTECTED] 2006-04-04 00:34 -------
So I've applied *most* of the patch to svn trunk ;)
1. There does seem to be an issue with what it does to HARVEST_DNSBL_PRIORITY,
changing it from 500 to -800. AFAIK, this causes DNSBLs to be harvested pretty
much immediately, instead of letting those network queries percolate in the
background while we do other stuff.
normally we'd do:
- start all DNSBL lookups (in the background)
- do head tests, body tests, etc. for several seconds
- wait several seconds for DNSBL results
- do meta tests
- AWL
- return
with the HARVEST_DNSBL_PRIORITY change it becomes
- start DNSBL lookups (in the background)
- wait several seconds for DNSBL results
- do head tests, body tests, etc. for several seconds
- start more DNSBL lookups (at another priority level)
- wait several seconds for those DNSBL results
- ...
I'm worried that that'll have pretty major knock-on effects on speed. :( So I
haven't applied that change to HARVEST_DNSBL_PRIORITY, and it's still at +500.
(META_TEST_MIN_PRIORITY is indeed now -500, though, so metas of non-network
rules can now be used for shortcircuiting. I couldn't see any bad
side-effects of that.)
But use of net/DNSBL tests in a short-circuit, needs a better way to do this
than causing it to attempt to harvest *all* network lookups early -- I think it
will need a way for the "shortcircuit SC_URIBL_SBL spam" line to cause the meta
dependency chain to be followed up to the network rule, and some logic to
realise that that implies that the URIBL lookups -- and just those -- therefore
need to be waited for before that meta rule can be evaluated correctly.
I think there's more work needed there.
2. I'm not convinced about "shortcircuit default" btw... I left it in, anyway,
for now. I would prefer to take it out though, unless there's a good reason
to have both it *and* the "ham/spam" version.
3. "t/dnsbl.t" fails, but it's failing before this patch was applied
anyway. something's up there in trunk :(
4. the "no shortcircuit" SCTYPE token for X-Spam-Status got changed to "no" to
match "autolearn=no".
5. added code to mass-check to ignore messages where X-Spam-Status =~
/shortcircuit=(?:yes|no|default)/.
apart from that -- looks good to me! checked in as r391177.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
