John Levine wrote:
A DNSBL MUST specify the scope of the listing and disclose whether
it may include an IP address which has not been identified as the
source of abusive email.
That's not quite it. Most of the addresses in the Spamhaus PBL have
never sent spam, after all.
Or listings of fastflux NSes. They're not emitting email either, but
they are abusive/related to email spam.
So it's more like "related to email abuse, or highly probable".
I mostly like the tone of SM's suggested wording, I'll try it with some
modifications.
Personally, I think that collateral damage is a reasonable term, and
all of the dnsbls don't block mail weasel wording is counterproductive,
since we're talking about policy, not code.
Collateral damage is a loaded term, and carries a lot of baggage from
outside of the Internet. I think we have to both mention it (so that
some people know what we're talking about), but at the same time try to
partially neutralize the extraneous knee-jerk reaction.
Remember the purpose: we're trying to get the DNSBL operator to provide
an indicator of aggressiveness (or rabidity if you prefer...).
Not just about adding IPs that aren't abusive in and of themselves, but
also to what degree they will list IPs that are mixed abuse/non-abuse.
So, not only do we try to get DNSBL users to know about, for example,
blanket listings of ranges with snowshoing bad bits and some hostages,
we also want them to have an idea of whether they'd block gmail/yahoo
etc, because they're mixed sources.
I have two pieces to do before reissuing the BCP. One is the above, the
other is domain oriented DNSBL testing.
I rather like dnsbl.test. What's the reason for including a dot?
Leaving the dot out reduces the probability (for the most part) with
colliding with a innocuous link.
Doug's suggestion (inserting underscores) is both good and bad for the
same reason. Underscores are illegal in DNS names, hence a good idea.
But, if they're illegal, the test wouldn't work either.
Theoretically.
Yes, I know that most resolvers/DNS servers handle them just fine, but
it's probably a bad idea to explicitly mandate a practise in violation
of existing RFC.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg