Upstream bug's description: ============================================================== Net::DNS version 0.76 changed the field name holding a set of nameservers in a Net::DNS::Resolver object: it used to be 'nameservers', but is now split into two fields: 'nameserver4' and 'nameserver6'. Mail/SpamAssassin/DnsResolver.pm relied on the internal field name of a Net::DNS::Resolver object to obtain a default list of recursive name servers, so the change in Net::DNS broke that. As a result, SpamAssassin now fails DNS checks and reports: dns: eval failed: available_nameservers: No DNS servers available! when used with Net::DNS 0.76 or later and no DNS servers are configured explicitly in a custom .cf file (config option: dns_server). The problem was reported by Walter Hurry on a mailing list, 2014-06-17. The solution is to use an official access method to obtain this information from Net::DNS::Resolver. Apparently early versions of Net::DNS lacked such official access method, which is why we needed to peek under the Net::DNS hood. ============================================================== Upstream bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7057 Locally observable indicator is entries like the following in logs: ============================================================== Apr 6 22:22:36 ip-172-30-3-20 spamd[14660]: rules: failed to run NO_DNS_FOR_FROM RBL test, skipping: Apr 6 22:22:36 ip-172-30-3-20 spamd[14660]: (available_nameservers: [...] No DNS servers available!) Apr 6 22:22:36 ip-172-30-3-20 spamd[14660]: spf: lookup failed: available_nameservers: No DNS servers available! Apr 6 22:22:36 ip-172-30-3-20 spamd[14660]: spf: lookup failed: available_nameservers: No DNS servers available! Apr 6 22:22:36 ip-172-30-3-20 spamd[14660]: rules: failed to run DKIM_ADSP_CUSTOM_MED test, skipping: Apr 6 22:22:36 ip-172-30-3-20 spamd[14660]: (available_nameservers: [...] No DNS servers available! Apr 6 22:22:36 ip-172-30-3-20 spamd[14660]: ) Apr 6 22:24:01 ip-172-30-3-20 spamd[14660]: plugin: eval failed: available_nameservers: No DNS servers available! ============================================================== Upstream's patch: ============================================================== --- Mail/SpamAssassin/DnsResolver.pm.orig 2014-05-07 17:54:29 +0200 +++ Mail/SpamAssassin/DnsResolver.pm 2014-06-18 02:13:32 +0200 @@ -205,6 +205,8 @@ dbg("dns: servers set by config to: %s", join(', ',@ns_addr_port)); } elsif ($res) { # default as provided by Net::DNS, e.g. /etc/resolv.conf - @ns_addr_port = map(untaint_var("[$_]:" . $res->{port}), - @{$res->{nameservers}}); + my @ns = $res->UNIVERSAL::can('nameservers') ? $res->nameservers + : @{$res->{nameservers}}; + my $port = $res->UNIVERSAL::can('port') ? $res->port : $res->{port}; + @ns_addr_port = map(untaint_var("[$_]:" . $port), @ns); dbg("dns: servers obtained from Net::DNS : %s", join(', ',@ns_addr_port)); } ============================================================== NOTE: Fixed in SpamAssassin 3.4.1.
Ah, looks like the stablization of dev-perl/Net-DNS-1.40.0 on 2016-04-02 (See Bug #578652) and removal of earlier versions on the same day is why this just popped up. (I was wondering why a bug that was fixed in 2014 was just popping it's head up.)
Please also look at https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7223 , when resolver is on other host spamassasin is getting REFUSED when queries rbls. Fix for this bugs are simple, I hope it will not be waiting till SA will have full time maitainer.
(In reply to Marcin Mirosław from comment #2) > Please also look at https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7223 > , when resolver is on other host spamassasin is getting REFUSED when queries > rbls. > Fix for this bugs are simple, I hope it will not be waiting till SA will > have full time maitainer. Yes, spamassassin-3.4.1-r2 needs this patch from the mentioned bug, otherwise the SPF plugin isn't working (T_SPF_HELO_TEMPERROR,T_SPF_TEMPERROR and dns: select timed out 1.000 s). See https://mail-archives.apache.org/mod_mbox/spamassassin-users/201512.mbox/%3C73E0FEBC5D91BC96218FA670@%5B192.168.1.9%5D%3E --- lib/Mail/SpamAssassin/DnsResolver.pm 2016-04-29 13:17:49.000000000 +0200 +++ lib/Mail/SpamAssassin/DnsResolver.pm 2016-05-05 18:39:47.000000000 +0200 @@ -592,6 +592,9 @@ }; if ($packet) { + # RD flag needs to be set explicitly since Net::DNS 1.01, Bug 7223 + $packet->header->rd(1); + # my $udp_payload_size = $self->{res}->udppacketsize; my $udp_payload_size = $self->{conf}->{dns_options}->{edns}; if ($udp_payload_size && $udp_payload_size > 512) {
Created attachment 433318 [details, diff] files/spamassassin-3.4.0-dnsresolver-bug579222.patch -- upstream's patch with added description comment
Created attachment 433320 [details] spamassassin-3.4.0-r2.ebuild that applies spamassassin-3.4.0-dnsresolver-bug579222.patch I've made a 3.4.0-r2 ebuild in hopes we can get something in the portage tree that fixes this. It works for me. I should note that I didn't add any platform keywords. The spamassassin-3.4.0-dnsresolver-bug579222.patch file needs to be placed in the files/ directory, and then this ebuild just applies the patch during src_prepare().
Marcin / Atman: The upstream issue I opened this bug for is fixed in 3.4.1, whereas the one you're referring to is in 3.4.0 & 3.4.1. If I make you an ebuild, can one of you test it out?
Created attachment 433328 [details, diff] files/spamassassin-3.4.0-dnsresolver-bug579222.patch -- upstream's patch with added description comment
Created attachment 433330 [details, diff] spamassassin-3.4.0-r2.ebuild that applies spamassassin-3.4.0-dnsresolver-bug579222.patch Updated 3.4.0 patch & ebuild to also apply changes from comment #3
Created attachment 433332 [details, diff] files/spamassassin-3.4.1-dnsresolver-bug579222.patch -- upstream's patch with added description comment Unlike the 3.4.0 patch, this only fix from comment #3, as the original issue is already fixed in 3.4.1.
Created attachment 433334 [details] spamassassin-3.4.1-r3.ebuild that applies spamassassin-3.4.1-dnsresolver-bug579222.patch
Phillipe, I had problem with resolver also with spamassasin-3.4.1-r2. I tried your ebuild for spamassassin-3.4.3-r3, compiles and installs fine. Works also fine, without problem with queries resolver.
Is any of you willing to proxy maintain this? https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Thanks
Spamassassin is too widely used to be not maitained. I don't promise quick fixes - I hope that someone else also will become proxy maint. Yup, let me be proxy maintainer.
If Marcin wants a co-maintainer for SpamAssassin, I'd be glad to co-maintain it with him. I agree with his statement that it's too important to too many users to let hang.
You can also add me, if there is need.
I experienced the same problem and the patch of comment #9 fixes it. Thanks!
Created a pull request on Github in hopes of moving things along/ease of use: https://github.com/gentoo/gentoo/pull/1520
Opened bug #583908 per https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_and_Maintainership_Requests with respect to the proxy maintainership request conversation. I've CC'ed Marcin & Alman on it.
I just fixed this with an -r3: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=323640f36b897eb908b406dfd570613dd323af9c I applied three patches, from upstream bugs 7223, 7231, and 7265. (One of my patches contains two of upstreams -- there were two revisions made on the same bug.) Thanks everyone for figuring out what the problem was and how to fix it.
For those wondering if their request went unnoticed, mjo@ will now be maintaining this package along with those asking for maintainership in this bug! See https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bcd92038135dae3fea3f1cdeb70674de3e4860ef
