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
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
to put a couple of paragraphs at the end of the intro expanding
as "DNS-Based List" for the purpose of the document, noting the
alternate expansions in use, briefly describe DNSB[lack]L, RHSBL,
DNSWL as in-scope (have I missed something?), and other more
"informational, not good/bad indicator" things like ISIPP and
as generally out of scope, but who MAY consider some of the items in
BCP as best practise anyway (eg: test, shutdown). Also some wording
about users can use them as an absolute (or one factor) block/
or a scoring contribution.
[meta: Is it going to be a problem that the IETF document file name
"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
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
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
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
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.
Asrg mailing list