Hello Matt, thanks for the response. > -----Original Message----- > From: Matt Kettler [mailto:mkettler...@verizon.net] > Sent: Wednesday, 8 April 2009 11:26 a.m. > To: Michael Hutchinson > Cc: users@spamassassin.apache.org > Subject: Re: 20_dnsbl_tests.cf > > 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. > > > > 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. > This is, in general, a very bad idea. Those files get dropped or > deleted > when you run sa-update. So now you have to make sure you never run > sa-update or your changes might get nuked. > > Better to make your over-rides in a file in /etc/mail/spamassassin.
Yes, I understand and had thought that as well. Considering my SA is version 3.1.7, no updates are coming out for it at the moment anyway. So, I would only run SA-update to get 3rd party rules (ie SARE) but I understand there are no updates for those rulesets either, so probably won't run sa-update until we have upgraded the server. I know I can override the scores in /etc/mail/spamassassin.. But how would I disable any one specific DNSBL test from there? (didn't see a way to do it before, hence the edits of the cf file directly). (And I know I can't run sa-update now). > > I basically just removed 2 DNSBL > > lookups that are redundant. > Which ones? Heh.. the list is a bit longer than I might have previously suggested: This one got nuked: header RCVD_IN_NJABL_DUL eval:check_rbl('njabl-lastexternal', 'combined.njabl.org.', '127.0.0.3') describe RCVD_IN_NJABL_DUL NJABL: dialup sender did non-local SMTP tflags RCVD_IN_NJABL_DUL net #reuse RCVD_IN_NJABL_DUL SBL_XBL got changed to ZEN. No biggie there. PBL added: # PBL is the Policy Block List: http://www.spamhaus.org/pbl/ header RCVD_IN_PBL eval:check_rbl('zen-lastexternal', 'zen.spamhaus.org.', '127.0.0.1[01]') describe RCVD_IN_PBL Received via a relay in Spamhaus PBL tflags RCVD_IN_PBL net #reuse RCVD_IN_PBL T_RCVD_IN_PBL_WITH_NJABL_DUL RCVD_IN_NJABL_DUL These nuked: header DNS_FROM_RFC_POST eval:check_rbl_sub('rfci_envfrom', '127.0.0.3') describe DNS_FROM_RFC_POST Envelope sender in postmaster.rfc-ignorant.org tflags DNS_FROM_RFC_POST net #reuse DNS_FROM_RFC_POST header DNS_FROM_RFC_ABUSE eval:check_rbl_sub('rfci_envfrom', '127.0.0.4') describe DNS_FROM_RFC_ABUSE Envelope sender in abuse.rfc-ignorant.org tflags DNS_FROM_RFC_ABUSE net #reuse DNS_FROM_RFC_ABUSE header DNS_FROM_RFC_WHOIS eval:check_rbl_sub('rfci_envfrom', '127.0.0.5') describe DNS_FROM_RFC_WHOIS Envelope sender in whois.rfc-ignorant.org tflags DNS_FROM_RFC_WHOIS net #reuse DNS_FROM_RFC_WHOIS And these got nuked too: # CompleteWhois blacklists header __RCVD_IN_WHOIS eval:check_rbl('whois', 'combined-HIB.dnsiplists.completewhois.com.') tflags __RCVD_IN_WHOIS net header RCVD_IN_WHOIS_BOGONS eval:check_rbl_sub('whois', '127.0.0.2') describe RCVD_IN_WHOIS_BOGONS CompleteWhois: sender on bogons IP block tflags RCVD_IN_WHOIS_BOGONS net header RCVD_IN_WHOIS_HIJACKED eval:check_rbl_sub('whois', '127.0.0.3') describe RCVD_IN_WHOIS_HIJACKED CompleteWhois: sender on hijacked IP block tflags RCVD_IN_WHOIS_HIJACKED net header RCVD_IN_WHOIS_INVALID eval:check_rbl('whois-lastexternal', 'combined-HIB.dnsiplists.completewhois.com.', '127.0.0.4') describe RCVD_IN_WHOIS_INVALID CompleteWhois: sender on invalid IP block tflags RCVD_IN_WHOIS_INVALID net #reuse RCVD_IN_WHOIS_INVALID RCVD_IN_RFC_IPWHOIS # another domain-based blacklist header DNS_FROM_SECURITYSAGE eval:check_rbl_envfrom('securitysage', 'blackhole.securitysage.com.') describe DNS_FROM_SECURITYSAGE Envelope sender in blackholes.securitysage.com tflags DNS_FROM_SECURITYSAGE net #reuse DNS_FROM_SECURITYSAGE I have refrained from adding any new ones, apart from the PBL. > > This is done in attempt to solve an issue > > random scan times of 30 seconds plus. > > > > 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. > > > > Any pointers would be greatly appreciated ;) > > > Upgrade to 3.2.x. > > Seriously, 3.1.7 is vastly to old to be very effective, it was released > over 2 years ago. Agreed, but I need to fix this server. We have an upgrade plan that will see us build a new Mail Server to replace this one after the end of the month. I have pushed to get this to happen sooner, but it will not. Unfortunately I cannot just upgrade SA. We are bound to a max version of 3.1.7 due to our Operating System version. There is no upgrade path left, it will get a complete rebuild. > It also has security holes in it (CVE-2007-0451 > <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0451> and > CVE-2007-2873 > <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2873>). Hmm.. may have to see about working around those, this server has to operate for at least another 20 days. Thanks and Cheers, Michael Hutchinson