This is a discussion on Re: These are getting through SA... - SpamAssassin ; Mark Martinec wrote the following on 6/12/2007 3:53 AM -0800: > Luis, > > >> I don't have any URIBL rules firing up (SA 3.2.0 from source here, >> most of the other relevant info is in the header of ...
Mark Martinec wrote the following on 6/12/2007 3:53 AM -0800:
>> I don't have any URIBL rules firing up (SA 3.2.0 from source here,
>> most of the other relevant info is in the header of the mail I sent
>> before to test). Where did you get them?
>> But the main difference between the live run and the ones I did with
>> SA by itself (both as root and as user amavis) is the URIDNSBL hit.
>> From this debug, I see Amavis loading up the URIDNSBL plugin at startup,
>> but lately it simply doesn't fire up on any spammy link (I googled
>> for them, since the DDoS attack blocked the website).
> I came across the same issue yesterday, with the same type
> of a spam message, which would mostly get hits from URIBL tests,
> but lots of other RBL checks come back emptyhanded.
> On the first appearance it seems that SA under amavisd-new didn't
> fire on DNSBL tests, but spamassassin from a command line did.
> Investigating the problem more thoroughly turned out that even
> a command line SA check behaved intermittently, sometimes
> returning URIBL_BLACK, URIBL_JP_SURBL, etc, and sometimes
> none of these URIBL tests - they were timing out.
> What is your setting for rbl_timeout ?
> Mine was fairly low, 5 seconds, and I find the dynamic timeout
> (for rbl_timeout) cutback logic (man Mail::SpamAssassin::Conf)
> does not work as advertised:
> In addition, whenever the effective timeout is lowered due to addi-
> tional query results returning, the remaining queries are always
> given at least one more second before timing out
> Namely with 22 RBL results coming back, the last one
> (which was the crucial URIBL test) had a timeout of 0
> and was ignored even though dns result did arrive.
> Moreover, there is a bug in Mail::SpamAssassin:ns, where
> a late-spawned URIBL queries (which only start after Razor,
> DCC and Pyzor are run) are being timed against start time
> of the first wave of plain RBL dns queries, which are fired-off
> seconds earlier, so there is a good chance that URIBL queries
> time out in 0 seconds and their resultes are never collected.
> The problem is made worse when for example Razor itself also
> times out (thus extending time between the two rounds of
> dns queries being sent).
> Luis, check your DNS if it is responponding quickly,
> try extending rbl_timeout to maybe 10 seconds, see if
> there are many timeouts in RBL, URIBL, Razor or DCC queries.
Mark, just curious if you are running Botnet? I found that some
messages cause the Botnet RDNS test to timeout after hanging for about
30 seconds, and then network test randomly fail (primarily URIBL
tests). I found that if I disable Botnet, then all network tests will
run fine on the very same messages.