On 10 Jun 2015, at 10:55, Alex Regan wrote:
Hi,
Not everyone is running a dedicated mail server. My server is an
everything-server running on a hosted VPS that only has a few
"users"
that get significant amounts of email. I'm not sure I want another
daemon that can break or take up clock cycles and memory on a system
processing 10 spams / hour (of which the DNSBL service might catch
2?). At least not yet, but I suppose I could change my mind. At the
moment not that many spams are getting through.
Mike
You asked for help, we provided it. It's fine if you ignore the
advice,
but it's good advice if you want to take your mail filtering to the
next
level in the future.
And it's not just for mail filtering. Unless you have the smallest of
systems, it's good general practice to implement a caching name server
for authentication, the email system itself, and general queries from
other services as well.
Right. A modern MTA using very simple internal spam exclusion tactics
(validity of sender domains, existence of valid PTR for the client IP,
etc) does multiple DNS queries per message. A local cache entry is
always an order of magnitude faster to get than one on the other side of
some router, so unless you're using an OS with a system name cache (e.g
Solaris' nscd, MacOS' Directory Services, etc.) that can handle many
records, your MTA mostly waits for DNS. Adding in DNSBLs used by the MTA
and variations like URIBLs used in SA, and you can end up doing the same
queries because of the same message far enough apart between the MTA and
the filtering that both go off to the net for resolution because the
system cache is anemic or absent.
But there's an even better reason: trustworthiness. ISPs and others
providing 'free access' resolvers have a history of shaping their
replies in their own interest. Sometimes this is also well-intentioned
(e.g. redirecting "bad" domain names) but while such tactics can be
protective for web browsing users, it can cripple mail servers trying to
block spam.
