I agree with most of your responses/changes/fixes/updates; most of the
ones that I don't, I'm going to sit back and think for a while before
revisiting them, because you raise some good points that really deserve
some serious offline thought. Thanks for the detailed response, it's
most illuminating. But I'm going to respond to one item in particular.
On Tue, Apr 01, 2008 at 10:17:04PM -0400, Chris Lewis wrote:
I'm not going to go thru that one today, other than to say that whatever
we call it, including "escalation beyond the entities strictly speaking
responsible for the original listing and likely includes non-abusing
third parties", something MUST to be said about making sure that the
DNSBL user has the best possible understanding of the DNSBL policy. A
DNSBL user _has_ to know how aggressive the list is relative to the
range of "stopping the spam only ... putting the cleats to the provider".
I agree with this sentiment, and with most of the way you've expressed it.
(And with the following paragraph that I've elided.)
A DNSBL operator can weasel out of calling it "collateral damage" by
defining the DNSBL policies properly, but it is a very real and very
important consideration in DNSBL choice. "collateral damage" just
happens to be the term the industry has settled on for this characteristic.
Let me see if I can explain why I think this is a fairly big deal.
I'm going to advance three slightly different -- but overlapping --
reasons why, one of which is a repeat.
I'm going to begin by (shockingly) agreeing with you in part. ;-)
People *do* use this terminology. Heck, I've probably been one of them.
But it's bad terminology, because it doesn't describe the situation
accurately. One of the many good things this BCP could do is to
clarify that this term's a misnomer. (Or, failing that, it could at
least not propagate it further and/or lend it some measure of credibility.
I'll get to that below.)
1. I've read all the followups here, and nobody has yet shown how
a DNSBL listing (or use of it) damages anyone or anything. To be sure,
they've shown how people might damage themselves by relying on faulty
assumptions, but that's hardly the responsibility of a DNSBL operator
or DNSBL user.
( If you rely on my well for free water every day, you're not
damaged by my decision that you don't get free water any more.
This is true even if your bread-making business is no longer
viable due to lack of my water.
You may in fact be damaged, but not by me: you did it to yourself
by virtue of your flawed business model. )
I think the reason this can be difficult to wrap one's head around
is that we pretty much take for granted the idea that all offered 'net
services are available to everyone all the time...so much so, that
eventually we begin to consider them an entitlement, not a privilege.
But as lots of people have pointed out elsewhere, one's "entitlements"
only extend to the border of one's ISP (or business network or campus
network or whatever). Everything beyond that is furnished either
(a) by contractual agreement (like a paid web site membership) or
(b) at the pleasure of its keepers. And if it pleases those keepers
in (b) to revoke those privileges, that's not damage: it's just
exercise of the rights of ownership.
2. Above I said that I don't want to see this BCP lend credibility
to what I consider to be a serious misnomer. Here's another
reason why: I can easily see a BCP with that term being waved around in
court by some spammer's attorney as supporting evidence for the claim that
...defendant deliberately damaged my client's business because
defendant knowingly carried out a procedure *documented and
designed to cause damage*...
Arguments in this direction have already been trotted out; they don't
need to be furnished with additional ammunition, especially if it carries
any kind of imprimatur.
3. There are so many possible motives for all the myriad DNSBL listings
and the myriad ways they're used, that absent explicit statements on
a per-listing and per-usage basis by those responsible for both, it's
impossible to say what anybody's motive is. So I don't think this BCP
should get into that -- I don't think it's necessary or desirable to try to
get inside the heads of people running DNSBLs or using them. Especially
since that's bound to be incredibly error-prone: one DNSBL operator's
default procedure might be another one's escalation and both might be
employed by a user -- perhaps contrary to the designs of both operators --
to assign message scores, that is, neither for acceptance nor rejection.
To say that in a broader way: I think this BCP should concern itself
with operational issues, not indirect consequences of usage for third
parties -- and "collateral damage", in addition to being a misnomer,
falls into that category.
---Rsk
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg