Rich Kulawiec wrote:
When choosing to adopt a DNSBL, a DNSBL user SHOULD keep the
following questions in mind:
[...]
2. Does the list have a web site?
3. Are the list's policies stated on the web site?
[...]
5. Does the web site function properly, e.g., hyperlinks?
6. Are web pages for removal requirements accessible and working
properly?
I'd like to see this changed to include other mechanisms that can be
used to communicate policy or handle removals. For example, a number
of DNSBLs have -announce lists which are used to communicate information
about outages (planned and unplanned), policy changes,
zone additions/removals, and so on.
Another angle: I think a web site may well be the best currently available
option for general information, but for at least some DNSBL users (like me),
subscribing to the -announce list is a much better way to keep apprised
of important news.
Done - added:
<t>Does the DNSBL have a mailing list for announcing
changes, outages etc?</t>
9. Are comparative evaluations of the list available?
It's not clear to me -- after having done a number of these -- that they
have as much value as we might hope they have. Without getting into
a long digression on that, the nut of the problem is that everyone's
mail mix is different, as are everyone's mail policies, so while one
evaluation might characterize a DNSBL as "excessive FPs", another
evaluation might characterize it as "excessive FNs". I'm not saying
this point should be removed; I'm saying that perhaps a caveat to
the effect that "all such evaluations depends on the mail mix used
as well as local policy" should be added. And, maybe, "if you can't
perform your own evaluation, then evaluations done by organizations
known to have a similar mail mix to yours and a similar set of policies
to yours may be the most applicable".
Added to the item:
Note: all such evaluations depend on mail mix used as well
as local policy. DNSBL users SHOULD consider trial
periods and/or ongoing local monitoring of DNSBL suitability.
10. What do your peers or members of the Internet community say
about the list?
Perhaps this is over-reaching, but spammers and their employees are
known to hold and express opinions about DNSBLs. I'm not sure how
to change the wording to express the idea that readers should be
careful to seek out the opinions of people whose goals align with theirs.
(That is, if they wish to receive spam, then get the opinions of
spammers. If not, then get the opinions of anti-spammers.)
H'm. Added:
DNSBLs can sometimes be quite controversial and sometimes
considerable misinformation is spread. Ensure that the opinions are
knowledgeable, and reflect similar goals to yours.
It is the responsibility of the system administrators who adopt one
or more DNSBLs to evaluate, understand, and make a determination of
which DNSBLs are appropriate for the sites they administer. If you
are going to allow a third party to make blocking decisions for you,
I suggest changing this to reflect [some] usage of [some] DNSBLs
for scoring, not blocking. Perhaps:
"If you are going to use a third party's data
in your decision-making process..."
or something like that? But I very much agree with the gist of this.
Adopted (slightly modified).
A DNSBL without DNSBL users does not prevent anyone from receiving
email or any other Internet service. A DNSBL with no users has no
effect. A DNSBL user prevents service by means of a DNSBL, and the
Again, I suggest wording that covers the usage of DNSBLs for scoring
(which may not result in prevention of service, but may result in
delayed service, or different service, or full service but with some
different internal disposition). (I'm going to stop pointing this
out each time it comes up to keep this short.)
Yeah, I need to say something about scoring. In the intro.
"A DNSBL user voluntarily uses DNSBL data to guide their filtering
decisions, and the...."
That should fix that.
DNSBL operators are merely expressing an opinion through the
publication of a DNSBL, and it is their absolute right to do so free
of legal encumbrance, even in violation of this BCP. However, it is
through abiding by the guidelines set forth in this BCP that the
operators of a DNSBL may gain the trust of their users.
I think this can be removed. It may or may not be their right to express
that opinion -- I think it is, but I'm not an attorney even in *this*
country. I think it's overbroad to state a global legal opinion.
Perhaps it should be toned down, but I think it still needs to be said
somehow. You don't have to be a lawyer to express an opinion about the law.
I also think it's overbroad to say that this BCP is the only path
to trust. It's *a* path, but it's too much to claim it's the only one.
I don't see it as reading "only".
A DNSBL SHOULD carefully describe the criteria which are the cause
for adding, and the criteria for removing an IP address or domain
name on the list.
I suggest introducing the term RHSBL to refer to domain names, subdomain
names, and host names.
The document uses "DNSBL" thruout to handle DNS-query-based lists, and
explicitly calls out both domains/IPs, and is inclusive of SURBLs too.
I think adding RHSBL/SURBL/URIBL etc will only make the document way
more opaque than it needs to be and is unnecessary.
Furthermore, the DNSBL documentation SHOULD be clear on the intended
use of the DNSBL - whether it be intended for peer addresses of
email, IRC, etc.
Suggest adding: "DNSBL providers SHOULD NOT be held accountable in any
way for the consequences of use of a DNSBL in a non-intended application",
or something along those lines.
I like it. Taken verbatim.
2.2.1. Listings SHOULD Be Temporary
I very strongly disagree with this statement in the case of domains.
Once a domain is known to operated by a spammer, there's no reason to
ever de-list it if the list's policy equates to "we list spammer domains".
Notice that the section gives plenty of "outs" on the general notion of
listings, domains or otherwise, and if your listing policy says "domains
are listed until the heat death of the universe" it's okay. So I think
it's fine as is.
And yes, some spamming domains _do_ reform.
I would agree with
Listings MAY be temporary or permanent
followed by discussion of why some (let's say, temporarily open relays
that are repaired) should be temporarily and why some (again, spammer-owned
domain) may be permanent, if that's the policy of the RHSBL maintainer.
In many cases, listings can exist for long periods of time past the
conditions leading to the listing's creation, and/or the listed
entity has changed ownership.
I would change this to:
entity has putatively changed ownership.
There have been cases where network allocations have "changed ownership"
under dubious circumstances, and I'm aware of several instance where
"domains were sold to new owners" who turned out to be the old owners
using a different business name.
Either the ownership changed or it didn't. It would be silly to get
into a discourse on how spammers lie. The DNSBL operators know that and
can make their own judgments. Tho, um, er, in this case, "putatively"
;-) done.
I've also made domain listings a bit more explicit as potentially having
long expiration:
<t>DNSBLs based on geographic region, block assignment or
domains of demonstrably bad actors MAY have
very long expiration intervals ..
[including no expiration - request and manual verification only.]
I think it's probably beyond the scope of this BCP to get into that
mess, but I do think it would be good to use wording that acknowledges
its existence and does not rule out a certain amount of skepticism
in the face of claims of "changed ownership".
Such a policy also can be an effective deterrent to legal problems.
I'd strike this, as it expresses a legal opinion. (I happen to
agree with that opinion, but IANAL either.)
Youse guys are altogether too afraid of lawyers. I think
downplayed/informal legal suggestions are useful. But let's try this:
Such a policy may be an effective measure to prevent small
issues blowing up into big problems.
If the DNSBL offers zone transfers (in addition to or instead of
standard DNSBL query mechanisms), it SHOULD be sufficiently
provisioned to handle the expected loading.
Would it be appropriate to mention rsync in this context?
Does this require me to add too many references? "Rsync zone transfers
are becoming a defacto standard for DNSBL zone transfers instead of DNS
protocol operations due to its efficiency".
[Not added, waiting for comment. Perhaps too much detail. Maybe John's
has it.]
servers. Popular DNSBLs are in use by 10s of thousands of sites, are
'tens", not "10s" ;-)
Okay ;-)
The shutdown procedure should have the following properties:
1. MUST NOT list the entire Internet
I somewhat disagree. As we're seeing again with ORDB, this is often
the only way for DNSBL operators to reclaim resources. I don't like it,
it shouldn't be necessary, it has negative consequences, it's bad,
but sadly, it appears to be the only way to reach people who have
done their best to ignore all the communication methods listed in
the prior section. I don't think DNSBL operators -- having done
their best to shut down services gracefully -- should be perpetually
saddled with a burden they no longer want.
Note that a DNSBL should only have to do this once. So, stern advice to
NOT do it and how to do it right is useful for existing and future
DNSBLs. If a DNSBL does do it, it's rather late to get too concerned
about compliance, ain't it? ;-)
The 0/0 phenomena is the media football, it's one of the things that can
make responsible DNSBL users stay awake at night. Something needs to be
said here.
3. SHOULD, perhaps through increased delays, indicate to the Mail
administrator that the DNSBL is no longer functional.
I agree with this in spirit: it should work. But it doesn't seem to.
ORDB didn't try it, nor Monkeys, nor OSIRUS. (At least ORDB and Monkeys
warned, OSIRUS didn't). NJABL dynablock (I think that's the right one -
decommissioned in favour of PBL) and Vixie's old BL are. Seems to be
doing the job. ORDB has been contacted and maybe they'll give it a shot.
5. The base domain name SHOULD be registered indefinately, so as to
ensure that the domain name doesn't represent a "booby trap" for
future owners, and/or provide a means by which a new owner could
list the entire Internet.
I agree with this, but suggest that wording be added to indicate that
DNSBL operators SHOULD attempt to notify the community if they lose
control of the domain or domain's DNS due to registrar, ISP, or
hosting issues.
May be a good idea. Other comments?
3.6. Use of Collateral Damage MUST Be Disclosed
There's no such thing as collateral damage. I'm going to write
a separate message about that because it's too long to include here.
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".
Someone may think that everybody who ever sent them any spam should be
blocked at the ASN level until the heat death of the universe to rub
their nose in it, but it is NOT the business of the BCP to mandate such
policies, instead, the BCP aims towards making it as easy as possible
for a DNSBL user to make an informed choice amongst a broad spectrum of
options.
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.
3.7.1. MUST NOT scan without provocation
I'd make it "SHOULD NOT". The legal climate is very unclear and there
is frequent vocal disagreement on both sides of this issue in the
security community. I think there's also plenty of argument over
what "provocation" is and what an appropriate scope of response is.
I think the section already weasels enough on that. Totally unprovoked
(straight and simple scanning of ranges "just because") is pretty
universally considered a very bad idea. But since AOL used to "scan if
you send me email", and I trust their lawyers, that seems to be where
the divide (for many, but not all obviously) is.
If we get called on it from something with very strong informed opinions
and the clout to back it up, we can back off. But until then I want to
leave it like that.
The general idea is fine, but I would avoid being overly prescriptive
while the community continues to debates this issue and (presumably)
litigation takes place to settle some of surrounding questions in some
jurisdictions.
In the absence of significant debate, I don't see a problem of putting a
stake in the sand and seeing who salutes to blenderize some metaphors.
Thanks for your valuable comments!
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg