[TAG] Using DNS blacklists to reject mail.
rick at linuxmafia.com
Mon Sep 22 01:24:14 MSD 2008
Quoting Joey Prestia (joey at linuxamd.com):
> I am wanting to gather some information about using DNSBL on mail
> servers. I have been reading the information on most of the more popular
> used blacklists like Spamcop and Spamhaus. Now I have come up with all
> kinds of questions on the subject.
> I would like to hear from any mail server administrators of their
> experiences with these methods of rejecting spam at the "gate".
Your question seems to presuppose that DNSBLs are a "method". They're
not. They're a source of information that can be used in a variety of
Information has value to the extent that you have confidence in its
accuracy and relevance -- which includes deciding whether or not you
(as MTA admin) think their listing policies are reasonable. Experience
suggests that that's a question one must assess individually for each
DNSBL. Further, DNSBLs have been known to be good for a while, then not
so good, then eventually may become counterproductive, e.g., because
they've ceased to be maintained.
It might seem counterintuitive, but one of the best things that some
past DNSBLs have done for the public was to -- after reaching a decision
to no longer maintain the database -- configure their DNSBL nameservers
to return a blacklist recommendation on _every_ IP queried. Why?
Because that's really the only effective way to notify MTA admins around
the world that they need to cease consulting the (now-obsolete) DNSBL.
Anyway, as I said, DNSBLs are not a "method" but rather a source of
information. Many of us MTA admins find it most fruitful to feed that
information through a spamicity-rating service locally, e.g., raising or
lowering the SpamAssassin score with weighting set for each DNSBL
according to the degree to which we think each one should be, on
average, taken seriously.
> It seems apparent that one must gage what type of spam and what type
> of lists to use very carefully because of the possibility of refusing
> valid mail?
Of course. This survey might be one good starting point:
> Is the implementation of using a DNSBL definitely something mail
> server administrators should consider?
Yes -- for appropriate values of "implementation".
> Is it common practice to use spamassassin and DNSBL together to reduce
> bombardment of spam?
> Although I have been using spamassassin for some time and see that it
> does a very good job of filtering and correctly labeling mail.
SpamAssassin is a ruleset _and_ a clearinghouse infrastructure for
receiving and processing information from arbitrary sources about a mail
stream's estimated spamicity.
> One thing I have heard is that it is not a good practice to put into
> effect something like this because many bigger institutions can and
> periodically do get put on blacklists, through no fault of their own.
Foregoing sounds like some combination of
1. non-sequitur reasoning, and
2. special pleading (http://en.wikipedia.org/wiki/Special_pleading)
Early in the spam wars, special pleading was even more common than it is
today. E.g., you as MTA admin would mention that you were likely to
join the rest of the sysadmin world in refusing mail from all known
open-relay SMTP sites, because there was simply no excuse for operating
such a site in the cutting-edge early-1990s world you then inhabited --
and _immediately_ some nitwit from a local university would be on your
"But, but, but... we _have_ to operate open relays because our
users insist on being able to relay outbound mail on port 25 from
arbitrary IPs, and we university sysadmins lack the political power
to order them not to, and it's simply _unfair_ to hold the entire
university responsible for what a few bad apples do."
(I swear I heard exactly that sort of thing, back in the day, many
What I'm driving at is: Some bigger institutions get put on blacklists
because, by and large, they got caught behaving like anti-social
screwups, i.e., for very good reason. They can get off those blacklists
by following the delisting policies, which by and large loosely
approximate "Stop screwing up".
Of course, there are DNSBLs with bad/ineffective/arbitrary/onerous
delisting policies -- but far fewer than asserted by critics who
include... surprise... habitual screwups who are following the _other_
bit of logic that accompanies special pleading: blame everyone and
anyone but one's self.
> One example I have seen:
> http://www.stanford.edu/services/email/antispam/blacklist.html is this
> an accurate representation of some of the possible effects of this
> being put into practice?
The page doesn't give enough technical information about the "forwarding
to AOL" example to assess it. I'm not certain offhand how the
hypothetically forwarded spam received at Stanford and then forwarded
manually, or via a .forward file, could be expected to look (the SMTP
headers) as received at aol.com. Therefore, I'm not certain whether
SpamCom can be rationally expected to be able to distinguish between
Stanford being a genuine spam-source on the one hand, and it being an
innocent recipient of spam that one of its _users_ then forwarded to
his/her AOL account, on the other. My _guess_, having not seen the
headers of such a forward, is that the Stanford page makes a good point,
and that SpamCop is vulnerable to submission of bad information.
As it happens, I don't personally use SpamCop's DNSBL information,
because I don't particularly trust it.
> Any recommendations as to suggested best practices in using these
Yes. Read DNSBL listing and delisting policies carefully. Use the
resulting DNSBL information with weighting according to your confidence
and agreement with their policies and according to your understanding of
their competence and good faith. Take critics' bitching cum granum
salis, but also be aware that sometimes they're right even though
they're complaining. ;->
More information about the TAG