Hello Matt, thanks for the response.
> -----Original Message-----
> From: Matt Kettler [mailto:[email protected]]
> Sent: Wednesday, 8 April 2009 11:26 a.m.
> To: Michael Hutchinson
> Cc: [email protected]
> 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
