On Mar 30, 2006, at 10:31 AM, Chris Lewis wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steve Atkins wrote:
On Mar 30, 2006, at 8:48 AM, Tony Finch wrote:
Steve Atkins <steve(_at_)blighty(_dot_)com> wrote:
Usage of them is not standardised enough to actually be useful.
Not true! DNSBLs are not only useful, they are crucial.
I think you misread what I wrote.
I wouldn't say he misread what you wrote, I'd suggest you meant
something highly different than what you actually wrote.
Usage of DNSBLs is anything but standardised. That lack of
standards causes significant problems.
What do you mean by "standard usage"?
The common access protocols are well standardized in a defacto sense,
and will soon be formally.
Well, some issues related to common usage include:
1. There is no graceful way to shut down a DNSBL.
2. When end users query a blacklist that has been shut down or has
never existed there is no easy way to communicate that error to
them. The main technical approach to that that has been tried has
been to list the entire internet, but that doesn't work when
the list
is being used for scoring, rather than blocking.
3. Dynamic blacklists are often distributed via batch updates,
meaning
that there can be multiple hour delays in propagating changes,
both
additions and removals.
4. There's no way for an end user to tell whether the list they're
using
is stale or not. Both the aforementioned distribution problems and
failed local mirroring processes can cause the data to become
stale.
5. The data returned by blacklists in response to an A record query
varies wildly. Pretty much all return an NXDOMAIN for "not
listed",
but the responses for "listed" vary significantly. Some return
a fixed
A record. Some return an A record chosen from several values, for
different listing criteria - including in at least one case one
of several
A records for "blacklisted", and a different A record for
"whitelisted -
do not block". Others don't return an A record at all, rather they
return a CNAME, which in turn points to an A record (or sometimes,
doesn't point to an A record).
Some of these could be resolved if all DNSBLs had something like
a standard address that was always listed (as 127.0.0.2 often, but
not always, is) and end users software monitored that. But, due to
using DNS as the underlying distribution method, there's no way
to ensure that end users do that.
That DNS as used by DNSBLs is primarily a pull protocol, rather than
a push protocol, causes some of these (as well as the scaling issues
that the publicly available blacklists have to deal with). Something
closer
to BGP would be a much more appropriate way to schlep this data
around. (Or, for the DNSheads in the crowd, Notify+IXFR - but notify
doesn't scale at all well to large numbers of users, unlike BGP which
can be distributed efficiently via a tree).
6. There is no particular standard for what response to return to a
sender when you're rejecting their mail at receipt time due to a
DNSBL listing. The SMTP response code used varies wildly, and
is often indistinguishable from a no-such-user or a local failure.
(This can, and often does, cause users to get dropped from the
mailing lists they've subscribed to due to a temporary or
transient
DNSBL listing - and there are some DNSBLs out there that will,
by their design, block legitimate sources of email for short
periods).
7. There's no widely used standard for what to return in the human
readable part of the rejection message. Many (but not all) DNSBLs
provide a TXT record to return as part of that message, sometimes
including a web URL for more information. That's a nice feature,
despite the significant overhead it adds to the DNS queries,
but it's
not used anything like universally. It's not unusual for mail
to be
rejected as "550 Listed in SpamHaus.org" for mail that patently
isn't.
These points are arguably an SMTP / mail filtering standard issue
rather than a DNSBL-related issue, but they're closely related, and
certainly they are some of the things that cause DNSBL usage to
cause inadvertent damage.
There are some other issues that spring to mind too, but this is a
mailing
list post, not an article, so I'm just touching on some of the
simpler points.
Standardizing anything else about them seems to me to be about as
useful
as standardizing ice cream flavours. Perhaps useful to define exactly
what "vanilla" means taste- and smell-wise so consumers know what
they're getting, but delineating which flavours are permissible in a
standard is just plain wrong.
I'm not going to eat carrion-flavoured ice cream, but, I'm not
going to
stop anyone making it or choosing to buy it - but I might run away
screaming if anyone near me tears the wrapper off one.
[Which is the same reaction I'd have to a MTA responsible for my email
using certain DNSBLs.]
The real problem is that people responsible for choosing DNSBLs aren't
necessarily exercising due diligence and knowing what they're getting.
That's certainly true too, and a whole other can of worms, but I
was trying to stick to the technical problems that are common
across some significant fraction of the users of it, rather than the
policy related issues.
But like carrion-flavoured ice cream, they have the right to choose
it,
no matter how idiotic it may turn out to be given what they're
_supposed_ to be accomplishing.
Cheers,
Steve
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg