> -----Original Message----- > From: Karsten Bräckelmann [mailto:guent...@rudersport.de] > Sent: Wednesday, 8 April 2009 11:31 a.m. > To: users@spamassassin.apache.org > Subject: Re: 20_dnsbl_tests.cf > > On Wed, 2009-04-08 at 11:09 +1200, Michael Hutchinson wrote: > > Hello everyone, > > > > Does anyone know of a way to perform individual debug tests on the > > DNSBL's listed in 20_dnsbl_tests.cf? In essence I need to see > failures > > and/or timeouts. > > spamassassin -D. In particular, I believe -D dns should limit it to the > results you're after. Sorry, from memory, not tested. Too lazy and too > late this night. ;)
I have done this, and appear to have quite a nominal time for those checks: MailServer:~/spamassassin# spamassassin -D dns -t </root/SpamA.txt [27256] dbg: dns: is Net::DNS::Resolver available? yes [27256] dbg: dns: Net::DNS version: 0.61 [27256] dbg: dns: name server: 127.0.0.1, family: 2, ipv6: 0 [27256] dbg: dns: testing resolver nameservers: 127.0.0.1 [27256] dbg: dns: trying (3) motorola.com... [27256] dbg: dns: looking up NS for 'motorola.com' [27256] dbg: dns: NS lookup of motorola.com using 127.0.0.1 succeeded => DNS available (set dns_available to override) [27256] dbg: dns: is DNS available? 1 [27256] dbg: dns: checking RBL zen.spamhaus.org., set zen-lastexternal [27256] dbg: dns: checking RBL zen.spamhaus.org., set zen [27256] dbg: dns: checking RBL sa-other.bondedsender.org., set bsp-untrusted [27256] dbg: dns: checking RBL plus.bondedsender.org., set ssc-firsttrusted [27256] dbg: dns: checking RBL combined.njabl.org., set njabl [27256] dbg: dns: checking RBL bl.spamcop.net., set spamcop [27256] dbg: dns: checking RBL sa-trusted.bondedsender.org., set bsp-firsttrusted [27256] dbg: dns: checking RBL zen.spamhaus.org., set zen-lastexternal [27256] dbg: dns: checking RBL dnsbl.sorbs.net., set sorbs-lastexternal [27256] dbg: dns: checking RBL dnsbl.sorbs.net., set sorbs [27256] dbg: dns: checking RBL iadb.isipp.com., set iadb-firsttrusted This took about 2 seconds or less. So I'm guessing that is quite normal. I suspect that some of these may be failing occasionally, perhaps this suggests some kind of occasional DNS lookup failure... > > I have made some changes to my SA 3.1.7 20_dnsbl_tests.cf when I > > compared it to the 3.2.5 release. I basically just removed 2 DNSBL > > lookups that are redundant. This is done in attempt to solve an issue > > random scan times of 30 seconds plus. > > It would help to let us know about the changes. That way we might > already be able to tell you, if it possibly could fix such issue. > > Other than that -- update. :-) Can't for reasons already described. Sorry for trying to get you guys to help me fix old technology. Eh. > > There does not appear to be any common rule firing against the E- > Mails > > that take 30+ seconds to scan. > > I have not managed to replicate the long scan time by testing > > Spamassassin locally with network tests enabled. > > Size? Well, maybe not, given the non-reproducibility. DNS timeouts? > Possibly. See above... > > > Any pointers would be greatly appreciated ;) > > Some real meat in your problem description would be appreciated as > well. ;) Now.. Meat.. Sorry about the address rewrites.. Been told by the boss.. Apr 8 11:47:02 tuatara spamd[23141]: spamd: result: Y 23 - BAYES_99,HTML_MESSAGE,HTML_SHORT_LINK_IMG_3,MIME_HTML_ONLY,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_XBL,TW_AQ,TW_JW,TW_QJ,TW_QK,TW_QZ,TW_YF,URIBL_AB_SURBL,URIBL_BLACK,URIBL_SBL scantime=30.3,size=2233,user=ema...@hosteddomain1.co.nz,uid=0,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=56696,mid=(unknown),bayes=0.999998520162275,autolearn=spam Apr 8 11:47:08 tuatara spamd[23298]: spamd: result: Y 17 - BAYES_80,HELO_DYNAMIC_IPADDR,HTML_30_40,HTML_MESSAGE,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RCVD_IN_XBL,UNPARSEABLE_RELAY,URIBL_AB_SURBL scantime=30.4,size=30018,user=ema...@hosteddomain2.co.nz,uid=0,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=56703,mid=<000d01c9b7db$12f8b5e0$6400a...@disputesle13>,bayes=0.887238649863803,autolearn=spam Apr 8 11:47:57 tuatara spamd[22212]: spamd: result: . 0 - AWL,BAYES_00,NO_REAL_NAME scantime=30.0,size=27338,user=ema...@hosteddomain3.co.nz,uid=0,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=56719,mid=<58215568.1239148009994.javamail.j...@akcux371>,bayes=0.000695157869939289,autolearn=no See the horrible scantimes. These are logged in between other tests that look quite normal: Apr 8 11:59:49 tuatara spamd[25073]: spamd: result: Y 18 - AWL,BAYES_50,DATE_IN_PAST_24_48,HTML_MESSAGE,HTML_TAG_BALANCE_BODY,TW_YC,UNPARSEABLE_RELAY,URIBL_AB_SURBL,URIBL_BLACK,URIBL_JP_SURBL,URIBL_SBL,URIBL_WS_SURBL scantime=2.6,size=8192,user=clamav,uid=0,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=57186,mid=<49826502-d1f5-4d43-b329-9e8a6eb34...@aloha.wst.pwsrotterdam.nl>,bayes=0.528807234903339,autolearn=no There does not appear to be a common rule that hits the Mail that takes too long to scan. I'd say that around 1/4 of all mail, perhaps less (without knowing for sure) takes an excessive amount of time to scan. Cheers, Mike
