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.
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".
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.)
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.
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.)
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.
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.
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.
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.
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".
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.
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.)
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?
servers. Popular DNSBLs are in use by 10s of thousands of sites, are
'tens", not "10s" ;-)
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.
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.
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.
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.
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.
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.
---Rsk
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg