[Asrg] Round 2 of the DNSBL BCP - "collateral damage"

[Steve Atkins]

On Apr 2, 2008, at 10:12 PM, Chris Lewis wrote:
> David Cawley wrote:
>
>> Just my 2c and I'd like to thank all of you working on the document.
>
> I'd like to thank everybody here to making this a rather more  
> productive
> process than I had feared <grin>.
>
> We seem to be converging reasonably well to something that most people
> can at least tolerate.  Can't ask for much more than that.
>
> There seem to be three specific issues under discussion at this point:
>
> - using the right terminology to make the document inclusive of RHSBL,
> URIBL, DNSWL etc, but not necessarily things like routeviews.  I'm  
> going
> to put a couple of paragraphs at the end of the intro expanding  
> "DNSBL"
> as "DNS-Based List" for the purpose of the document, noting the
> alternate expansions in use, briefly describe DNSB[lack]L, RHSBL,  
> URIBL,
> DNSWL as in-scope (have I missed something?), and other more
> "informational, not good/bad indicator" things like ISIPP and  
> Routeviews
> as generally out of scope, but who MAY consider some of the items in  
> the
> BCP as best practise anyway (eg: test, shutdown).  Also some wording
> about users can use them as an absolute (or one factor) block/ 
> whitelist
> or a scoring contribution.
>
> [meta: Is it going to be a problem that the IETF document file name  
> has
> "blacklist" and not "dnsbl"?  Leave it alone or change?  If I were to
> change it, I assume that means that it's effectively a brand-new
> document and the revision number reverts to 01.
>
> - "functional signaling" procedures for domain-based DNSBLs.  I could
> either suggest example.com, suggest 127.0.0.2, or punt ("no common
> mechanism is apparent, make one up and document it so that users can
> automate testing if they wish").  I'm inclined to 127.0.0.2 because
> domain-based lists can do it just as easily as IP-based ones.  Are  
> there
> strenuous reasoned objections to that?

No preference, as long as something is documented in the BCP. Punting
would be Bad, as this point is (IMO) the best reason for the BCP to  
exist
as an RFC-style document ("MUST").

> - Material about collateral damage - terminology used, etc. It seems
> clear that most think that something has to be said.  I'm going to
> reread the list comments and take another run at that section.  So, it
> may be worth stopping the current threads on it and wait for my new  
> attempt.
>

I'm not convinced "collateral damage" is a great term, but something
needs to be said about the subject. A distinction between unavoidable
collateral damage ("We list IP addresses that emit a lot of spam, even
if they emit real email too."), accidental collateral damage ("We don't
intend to ever block legitimate email, but we may sometimes  
accidentally")
and intentional collateral damage ("We list IP addresses that emit only
legitimate email, in order to punish the owners of those addresses")
might be needed, despite the complexity that adds.

Cheers,
   Steve