http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4860
Summary: consolidate DNSBL-lookup async infrastructure, allow
early exit
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: minor
Priority: P5
Component: Libraries
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
This patch (on the way) fixes the following issues:
- 1. We currently have two event loops for DNSBL lookups, one in Dns.pm and one
in URIDNSBL.pm. This is slow, complex and wasteful.
- 2. When the DNS lookup code receives a response from the DNS server, it adds
it to a hash, and then returns. Later another function runs, gets the
response from the hash, and *then* deals with it. It should just deal with
it immediately; the other way is inefficient.
- 3. The Dns.pm code isn't short-circuit-friendly, since it won't return any
results until the full "wait for all results to complete/rbl_timeout" loop is
completed.
- 4. There's no way to wait for certain rules to complete, which again is
very useful for short-circuiting.
So here's the upshot -- Mail::SpamAssassin::AsyncLoop. This class is basically
the async event loop from URIDNSBL, abstracted and made more generic.
Mail::SpamAssassin::Dns: code rewritten to use that event loop.
Mail::SpamAssassin::Plugin::URIDNSBL: ditto.
Added: PerMsgStatus::is_rule_complete($rule), which can be called by
short-circuiting code to determine if a rule has completed its lookup yet, or
not. The idea is that, if a shortcircuit at priority N depends on a DNSBL or
URIBL lookup (directly or via meta dependency tree), this can be detected by
Mail::SpamAssassin::Conf::Parser somehow ;), and a note made that before the
shortcircuit rule at priority N can be executed,
PerMsgStatus::is_rule_complete($rule) should be called for all the network
tests it relies on, and a loop be executed until is_rule_complete() returns
1 for all those rules.
In the same patch: t/dnsbl.t: changed the rbl_timeout to 30 seconds, since I'm
getting timeouts otherwise on my crappy DSL these days :(
There is an issue that I haven't taken care of, though, regarding the
test_log() output from multiple hits of the same rule on different IPs/URIs:
+ # TODO: this may result in some log messages appearing under the
+ # wrong rules, since we could see this sequence: { test one hits,
+ # test one's message is logged, test two hits, test one fires again
+ # on another IP, test one's message is logged for that other IP --
+ # but under test two's heading }. Right now though it's better
+ # than just not logging at all.
this is a side-effect of evaluating handle_hit() immediately when the
rule actually hits, instead of waiting until end-of-scan.
all tests pass, of course ;) note: you'll need to "make clean" to try this
out, since this adds a source file.
This is strictly 3.2.0 stuff, in my opinion. I'll be checking it in
if we're ok with it...
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
