http://bugzilla.spamassassin.org/show_bug.cgi?id=3997
------- Additional Comments From [EMAIL PROTECTED] 2005-01-18 10:49 -------
I was looking over Vance's comment #23 and had an idea. We're sending out
multiple DNS queries that run in the background, then match up results with
queries as they come in. If that is getting mixed up, then the results would be
wrong. The URIBL_ tests that are matching are defined in the rules with, for
example,
URIBL_SC_SURBL multi.surbl.org. A 2
This says to match a bitmask of 2 to the return value of the lookup. A correct
return value of the lookup will be of the form 127.0.0.*, but the rule will
match any bogus return value that has 2 bit set in the last octet.
We can test if we are getting bogus return values from the DNS lookup by adding
a rule that looks for
urirhssub URIBL_TEST_SURBL multi.surbl.org. A ^127\.0\.0\.\d{1,3}$
body URIBL_TEST_SURBL eval:check_uridnsbl('URIBL_TEST_SURBL')
describe URIBL_TEST_SURBL URL validly listed in SURBL blocklist
tflags URIBL_TEST_SURBL net
score URIBL_TEST_SURBL 0 0.1 0 0.1
Somebody please correct me if I got that wrong, as I am not in a position to
text anything right now. It is supposed to trigger the rule for any URI with an
entry in multi.surbl.org but not for any bogus result that is not
127.0.0.something.
With this in your local.cf, if you see a URIBL_TEST_SURBL hit whenever you see
any other URIBL_*_SURBL rule hit. If my conjecture about what is happening is
correct, the bogus URIBL_*_SURBL hits will not be accompanied by a
URIBL_TEST_SURBL hit.
It would be even better if someone can suggest a regular expression that will
match any ip address return value except 127.0.0.\d{1,3} so the test rule can
more directly check for a bogus return value and then it would appear on a hit
in the bad cases instead of in all the good cases.
Vance, can you try this out and see what results you get?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
