Well, I dint't have rbl_timeout set, but after your mail, I did. The DNSs I have set in resolv.conf are mine, they both cache and work as internal and external resolvers. But the UNLP NOC got screwed in the last days, so setting the timeout a little higher wont't hurt. Thanks for the suggestion. However, I upgraded to Amavis 2.5.1 yesterday (and rebuilt the AWL and the Bayes SQL databases, because they got corrupted) and everythig got back to normal. Updated several modules as Amavis required, and everything got back to the usual behavior. URIBL rules got fired (on several mails), and Razor and Pyzor got me results again. Additionally, SA stopped complaining about some minor issues when running sa-compile.
Thanks again, Luix 2007/6/12, Mark Martinec <[EMAIL PROTECTED]>:
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 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::Dns, 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
-- ------------------------------------------------- GNU-GPL: "May The Source Be With You... Linux Registered User #448382. When I grow up, I wanna be like Theo... -------------------------------------------------
