Apache SpamAssassin 3.0.4 breaks network checks (?)

I confirm this
Don't see few things happening as it was pre upgrade.

Anup

 

I am watching and i definitely do not see the RBL network tests happening which is just letting few more length enhancers move in

Anup

 

Have you opened a ticket or bugzilla with cPanel to inform them and have them investigate?

 

It also seems to be a problem with Net::DNS version: 0.51 which I noticed was updated last night. If I run "spamassassin -D --lint" I see the following in the results:

debug: is Net::DNS::Resolver available? yes
debug: Net::DNS version: 0.51
debug: trying (3) ebay.com...
debug: looking up NS for 'ebay.com'
debug: NS lookup of ebay.com failed horribly => Perhaps your resolv.conf isn't pointing at a valid server?
debug: All NS queries failed => DNS unavailable (set dns_available to override)
debug: is DNS available? 0

How does one roll back to Net :: DNS 0.48 ?

Thx -

 

Waiting still for a bugzilla entry on Features Manager bug wrt catchall and forwarders to be fixed.

--lint -d :

debug: is Net::DNS::Resolver available? yes
debug: Net::DNS version: 0.50
debug: trying (3) sun.com...
debug: looking up NS for 'sun.com'
debug: NS lookup of sun.com failed horribly => Perhaps your resolv.conf isn't pointing at a valid server?
debug: All NS queries failed => DNS unavailable (set dns_available to override)

Anup

 

rollback to 0.48 gets everything firing up again.

debug: Net::DNS version: 0.48
debug: trying (3) yahoo.com...
debug: looking up NS for 'yahoo.com'
debug: NS lookup of yahoo.com succeeded => Dns available (set dns_available to hardcode)
debug: is DNS available? 1

running upcp would again upgrade Net::DNS?

Anup

 

so that explains the extra spams getting through. I'm getting a lot more "Spam Assassin Time Outs" since the update. I hadn't had time to track down the cause, so not sure if it's related, but likely is.

 

Very much in the same scenario as yours.
Have had auto updates off eversince one night it brought my server down long back. So wouldn't do a upcp for quite sometime now

Anup

 

Just been looking at this in the SpamAssassin code. Haven't nailed it down yet, but if you are desperate for a quick and dirty (very dirty) workaorund, you can:

Edit /usr/lib/perl5/site_perl/5.8.1/Mail/SpamAssassin/Dns.pm (sub your version of perl in to the path as appropriate) and change line 1264 from:

Code:

      $IS_DNS_AVAILABLE = 0; # should already be 0, but let's be sure.

to:

Code:

      $IS_DNS_AVAILABLE = 1; # should already be 0, but let's be sure.

The subsequent URIDNSBL checks will then be done. As I said, this is not a fix, just a way of getting it working until the problem can be found.

 

Scratch that, the prettier workaround is to edit /etc/mail/spamassassin/local.cf and add:

dns_available yes

SpamAssassin will then skip the NS record test and continue on working.

 

The problem lies between the Net::DNS module and Mail::SpamAssassin, cPanel simply installs the latest version from cpan.org whenever upcp runs and so are pretty much out of the picture.

Having done some extensive debugging it looks like there's a problem the the Net::DNS persistence as the port is not being kept open after the initiation of the DNS query.

If you change the following part of Mail::SpamAssassin::Dns.pm from (line 1046):

Code:

      my $query = $self->{res}->search($dom, 'NS');

to:

Code:

	  my $resme = Net::DNS::Resolver->new;
	  my $query = $resme->search("$dom", 'NS');

then it all works OK. this doesn't show whether the problem is in the SpamAssassin module or the Net::DNS module, but that is where the problem is. I would suspect that this is something the SpamAssassin team will have to investigate. Feel free to post it on the SA bugzilla.

If you have a lot of servers, the following will save you some typing:

echo dns_available yes >> /etc/mail/spamassassin/local.cf

 

so adding dns_available yes would fix the problem or need to edit Dns.pm too?

 

You just need to add the directive, no need to edit DNS.pm - that was just me working through how to get around the issue.

 

Here is the SpamAssassin Bugzilla report on this issue for those that are interested:

http://bugzilla.spamassassin.org/show_bug.cgi?id=4403

It's apparently been closed as a WON'T FIX as it is working fine in the 3.1.x branch of SpamAssassin with the latest version of NET:: DNS