I had one of these moments:
My logs looked like this:
plugin: eval failed: available_nameservers: No DNS servers available! plugin: eval failed: available_nameservers: No DNS servers available! rules: failed to run NO_DNS_FOR_FROM RBL test, skipping: (available_nameservers: [...] No DNS servers available!) (available_nameservers: [...] No DNS servers available!
My /etc/resolv.conf was correct and had two valid DNS servers listed. Also, the permissions set on /etc/resolv.conf were reasonable (0644) and the SELinux context applied to the file was appropriate (net_conf_t). Everything else on the system was able to resolve DNS records properly. Even an strace on the spamd process showed it reading /etc/resolv.conf successfully!
It was Google time. I put some snippets of my error output into the search bar and found a spamassassin bug report. Mark Martinec found the root cause of the bug:
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.
The patch from the bug report worked just fine on my Fedora 20 mail server. Be sure to restart spamd after making the change.
There’s a Fedora bug report as well.
If anyone is interested, I plan to write up my email configuration on Fedora soon for other folks to use. I might even make some ansible playbooks for it. ;)
Fedora update: Fedora’s spamassassin package has been updated to 3.4.0-7 and it fixes two bugs. You’ll find it in the stable repositories in a few days.