ietf-asrg
[Top] [All Lists]

Re: [Asrg] Comments on draft-church-dnsbl-harmful-01.txt

2006-03-30 13:29:30

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

<Prev in Thread] Current Thread [Next in Thread>