I assume this is because mailinabox is forwarding all DNS queries to a public upstream DNS service? How have others fixed this - just ignore it, or change the configuration to use a local recursive DNS resolver like Unbound?
Looking at /etc/resolv.conf, there is only 1 entry for localhost (127.0.0.1). Port 53 (DNS) on localhost is used by named according to the lsof command, meaning mailinabox is using bind9 for DNS resolution. This brought me to the configuration files in /etc/bind, which show a basic bind9 configuration for recursive DNS lookups. Since there is no special DNS configuration in /etc/spamassassin/local.cf, this leads me to believe that Spamassassin is using the system’s default DNS server (which, as noted, is bind9).
So I don’t understand why the lookups to Validity are failing. Validity allows 10,000 anonymous lookups per month, and there’s no way my tiny mail server has anywhere near that volume of mail traffic. Any ideas?
Same here. I’m not sure whether I’ll leave the Validity registration in place, however, since there is a privacy issue: It enables Validity to know the IP (which can easily be reverse-resolved to a domain name via PTR lookup) of every sender. So basically, Validity knows everyone that is sending you email.
Thank you for this! I had the same error messages in my email headers and had no idea.
I signed up for the Validity.com account, added my server’s IP, but still no luck
I had to do 1 more step. I went to /etc/mail/spamassassin/local.conf and add the following somewhat towards the top (I added it in the "rewrite header section):
dns_server 127.0.0.1
(I initially added it to the bottom, but that didn’t work.)
For me, there was a delay of a few hours between creating a Validity account and the time when it started working. I don’t think it’s necessary to add that configuration line, since Spamassassin’s default is to use the system DNS servers in /etc/resolv.conf, which is 127.0.0.1 unless you changed it. So it was probably coincidence that it started working when you added that line to the config: The time delay probably just elapsed.
Ahh, yes. Looks like you were correct. I removed the dns_server 127.0.0.1, rebooted, and it all still looks good. I will update my notes. Thanks for that tip!
Strange. I checked email headers today and the error came back after removing dns_server 127.0.0.1. Maybe it is required since I’m using Secondary nameservers for Mail-in-a-Box?
I inserted dns_server 127.0.0.1 back into the local.conf file, rebooted, waited a bit, and now the errors are gone again and can’t be found anywhere in newer e-mails received.