Problem: spamassassin does not seem to use DNS blacklists and therefore has a poor detection rate
The fact that spamassassin does not use any/only some DNS blacklists can be recognized, for example, by the fact that the test URIBL_BLOCKED is listed in the mail header X-Spam-Status:.
Solution:
Various DNS blacklist operators have defined query limits that restrict requests from a single IP address. If the number of queries exceeds the limit, the requesting IP address is blocked. If you really operate a high-volume mail server, it may be unavoidable to have your IP address reactivated by paying a fee to the DNS blacklist operator.
With a low-volume mail server another problem usually occurs: the DNS server of the provider is used as forwarding server. All DNS queries that the UCS DNS server cannot answer directly from its LDAP or cache are forwarded directly to the internet provider, who then queries the DNS blacklist, for example. As a rule, the DNS servers of the provider quickly exceed the request limit and are blocked, so that the UCS DNS server no longer receives meaningful DNS responses.
The solution can be to configure the local UCS DNS server on the mail system as a “recursive resolver”. DNS requests are then no longer forwarded to the internet provider, but the UCS DNS server is traversing through the DNS hierarchy via the DNS root servers until it receives a response to its request.
The migration requires removing the DNS forwarders in the UCR configuration and disabling the DNS fake root zone:
# ucr unset dns/forwarder1 dns/forwarder2 dns/forwarder3
# ucr set dns/fakeroot=no
# service bind9 restart
However, you should be careful before or during the conversion: a recursive resolver can be used for amplifying attacks, since DNS queries can be made via a small UDP packet and the senders of UDP packets can easily be faked. The attacker then sends many small DNS UDP packets with faked sender IP address and asks for DNS entries that are very extensive and therefore require many response packets. The large number of response packets is not sent to the attacker, but to the victim, who has the same IP address as the fake sender IP address of the DNS request. Therefore, you should always restrict the DNS server query and check this regularly. Which IP addresses and IP subnets can make a (recursive) DNS query with the UCS DNS server can be defined via the UCR variable dns/allow/query/cache:
# ucr set dns/allow/query/cache="localhost"
# service bind9 restart
To further reduce the number of queries, the file /etc/spamassassin/local.cf can be extended by a list of DNS domains for which no DNS blacklist query should be made. Domains can/should be included in this list which are never blocked by the DNS blacklist operator. In addition, queries for your own domains (e.g. univention.de) can also be omitted:
# skip DNS lookups for domains that will never get blocked via DNS BL
uridnsbl_skip_domain googleapis.com goo.gl googlegroups.com docs.google.com
uridnsbl_skip_domain youtu.be linkedin.com fbcdn.net licdn.com twimg.com redbox.com
uridnsbl_skip_domain amazon.ca amazonses.com amazonaws.com ssl-images-amazon.com images-amazon.com media-amazon.com
uridnsbl_skip_domain instagram.com pinterest.com pinimg.com facebookmail.com yahoodns.net tumblr.com
uridnsbl_skip_domain groupon.com grouponcdn.com office365.com booking.com
# skip DNS lookups of our own domains (examples!)
uridnsbl_skip_domain univention.com univention.de your-company.example.com