dns: sendto() failed:

[roblingelbach]

Been running Spamassassin for a long time with no problems until a  
recent update of various packages including perl (but no other  
immediately perceptible relevant update) and now this error:

Oct 30 15:34:31 <hostname deleted>  spamd[16264]: dns: sendto()  
failed: Connection refused at /usr/lib/perl5/vendor_perl/5.8.8/Mail/
SpamAssassin/DnsResolver.pm line 395, <GEN3116> line 485.

The <GEN3116> line 485  varies from error msg to error msg, but it  
seems every message hitting spamd is generating this error.

OS is CentOS 5.4-4
SpamAssassin version 3.2.5  running as:
/usr/bin/spamd -d -c -m9 -H -r /var/run/spamd.pid

Perl just updated to perl-5.8.8-27.el5.i386

thanks in advance for any help.
Rob
--
Rob Lingelbach
rob@...

[Mark Martinec]

Rob,

> Been running Spamassassin for a long time with no problems until a
> recent update of various packages including perl (but no other
> immediately perceptible relevant update) and now this error:
>
> Oct 30 15:34:31 <hostname deleted>  spamd[16264]: dns: sendto()
> failed: Connection refused at /usr/lib/perl5/vendor_perl/5.8.8/Mail/
> SpamAssassin/DnsResolver.pm line 395
>
> CentOS 5.4-4, SpamAssassin 3.2.5  running as:
> /usr/bin/spamd -d -c -m9 -H -r /var/run/spamd.pid
> Perl just updated to perl-5.8.8-27.el5.i386

man 2 send

[ECONNREFUSED]
  The socket received an ICMP destination unreachable
  message from the last message sent.  This typically
  means that the receiver is not listening on the remote port.


Check health of the first DNS resolver as specified in your /etc/resolv.conf.
Is it alive? Is a firewall or OS policy blocking queries?

  Mark

[roblingelbach]

On Oct 30, 2009, at 2:17 PM, Mark Martinec wrote:

>> immediately perceptible relevant update) and now this error: (CentOS)
>>
>> Oct 30 15:34:31 <hostname deleted>  spamd[16264]: dns: sendto()
>> failed: Connection refused at /usr/lib/perl5/vendor_perl/5.8.8/Mail/
>> SpamAssassin/DnsResolver.pm line 395

> Check health of the first DNS resolver as specified in your /etc/
> resolv.conf.
> Is it alive? Is a firewall or OS policy blocking queries?

This indeed turned out to be the problem.  Iptables was reinitialized  
with values other than those which I thought I had saved.  The other  
possibility arose that because SELinux was also somewhat changed in  
the multi-package update, that it was being more strict, but adjusting  
iptables for port 53 fixed.   thank you Mark.

Rob
--
Rob Lingelbach
rob@...

[Martin Gregorie-2]

On Fri, 2009-10-30 at 19:09 -0200, Rob Lingelbach wrote:

> The other  
> possibility arose that because SELinux was also somewhat changed in  
> the multi-package update, that it was being more strict, but adjusting  
> iptables for port 53 fixed.   thank you Mark.
>
IME SELinux is a pain in the butt. Its more trouble than its worth
because I run both non-standard services and standard services with
non-standard file system usage.

Consequently, my first action after a clean install is to disable
SELinux. My firewall doesn't accept any inward connections and I'm
fairly careful with cross-user permissions, so I don't think this adds
appreciably to systemic risk.


Martin