Subject: [Asrg] New Version Notification for draft-irtf-asrg-bcp-blacklists-07

From: "Chris Lewis" <[email-masked]>
Date: Tue, 4 Jan 2011 07:02:24 -0500

New and I hope final revision of the DNSBL BCP.

https://datatracker.ietf.org/doc/draft-irtf-asrg-bcp-blacklists/

Section 2.2.3: more discussion on response times.
    new  2.2.5: conflict of interest
         3.9: considerations for data corruption et. al.

Subject: New Version Notification for draft-irtf-asrg-bcp-blacklists-07
From: IETF I-D Submission Tool <[email-masked]>
To: "Lewis, Chris (CAR:W669)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 4 Jan 2011 06:37:08 -0500

A new version of I-D, draft-irtf-asrg-bcp-blacklists-07.txt has been successfully submitted by Chris Lewis and posted to the IETF repository.

Filename:	 draft-irtf-asrg-bcp-blacklists
Revision:	 07
Title:		 Overview of Email DNSBL Best Practise
Creation_date:	 2011-01-04
WG ID:		 Independent Submission
Number_of_pages: 21

Abstract:
The rise of spam and other anti-social behavior on the Internet has
led to the creation of shared DNS-based lists ("DNSBLs") of IP
addresses or domain names intended to help guide email filtering.
This memo summarizes guidelines of accepted best practice for the
management of public DNSBLs by their operators as well as for the
proper use of such lists by mail server administrators (DNSBL users),
and it provides useful background for both parties.  It is not
intended to advise on the utility or efficacy of particular DNSBLs or
the DNSBL concept in general, nor to assist end users with questions
about spam.

Comments and discussion of this document should be addressed to the
[email-masked] mailing list.

The IETF Secretariat.

---

From: John Levine <[email-masked]>
Date: 18 Jan 2011 15:46:59 -0000

>https://datatracker.ietf.org/doc/draft-irtf-asrg-bcp-blacklists/

I'd like to publish this as an ASRG document sooner rather than later.
So please take a look at it and say:

a) I agree with what it says, OK for ASRG consensus.

b) I have minor reservations but don't object to publishing it, OK for
   ASRG partial consensus.

c) It's so wrong that you shouldn't publish it unless you change X to
   Y.  (Be sure to fill in X and Y.)

R's,
John, ASRG chair

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 18 Jan 2011 11:23:15 -0500 (EST)

>   Y.  (Be sure to fill in X and Y.)

I believe the syntax for queries should be specified in this document. 
While the syntax for IP address queries is standardized in practice (and 
shown in examples in the text) I am not sure the syntax (especially 
translation of invalid characters) of URIs is fully standardized. I 
haven't used such services yet, so perhaps I am wrong about practice. 
Isn't this the opportunity to do so? Standardization of the query makes it 
simple for clients to switch among servers.

I should add that I am in agreement with policy advice in the document and 
wouldn't actually oppose it if asked.

Daniel Feenberg

>
> R's,
> John, ASRG chair
> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg
>

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Jan 2011 12:13:42 -0500

> I believe the syntax for queries should be specified in this document.

It's in RFC 5782.

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 18 Jan 2011 12:20:21 -0500 (EST)

>> I believe the syntax for queries should be specified in this document.

Then I will withdraw my suggestion. Thanks

Daniel Feenberg

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 18 Jan 2011 17:33:57 +0000

> a) I agree with what it says, OK for ASRG consensus.

a)

Nice piece of work.

Martijn.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

---

From: John Johnson <[email-masked]>
Date: Tue, 18 Jan 2011 11:44:11 -0600

> a) I agree with what it says, OK for ASRG consensus.

I would choose a) for my circumstances.

Thank you John and all involved.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Jan 2011 11:36:30 -0800

>     Y.  (Be sure to fill in X and Y.)
John,

C.  This draft continues the delusion of IP address listings for IPv6.  
An important feature of IPv6 is the ability to rapidly renumber.  Any 
scheme that attempts to apply policy against IPv6 addresses removes this 
important feature.

Suggestions related to IPv6 address listings are almost certainly 
representative of poor advice.  For example how might one determine what 
would be a "reasonable" rescan period for the v6 address space?  What 
would be a reasonable listing duration when a different IP address can 
be used for centuries for every message ever sent?  Frankly, anything 
that suggests IP address listing criteria for IPv6 would represent 
advice not based upon any practical experience, nor supported by 
reasonable justifications.  There is nothing that even suggests reactive 
block-listings of IPv6 addresses can ever be disseminated at a rate 
effective at mitigating abuse.

This draft should caution against assumptions that suggest IPv4 
practices can be extended for use with IPv6!

-Doug

---

From: John Leslie <[email-masked]>
Date: Tue, 18 Jan 2011 15:45:32 -0500

> scheme that attempts to apply policy against IPv6 addresses removes this 

   I'm afraid Doug is a bit in the rough here: most of us seem hell-bent
on _making_ IPv6 DNSBLs work.

   (I do, however, share Doug's doubt that we'll succeed.)

> practices can be extended for use with IPv6!

   +1

   (I didn't stumble upon any exactly contrary statement; but I think we
need an explicit explanation that IPv6 DNSBLs are a work-in-progress at
best, and this documents cannot make recommendations specific to IPv6.)

====

   Other than that, I stumbled upon some of the MUSTard.

   In general, we cannot enforce any behavior on list maintainers.

   Specifically, the "MUST NOT charge" in Section 2.5 is inappropriate.
DNSBLs that do not charge for access will necessarily need to recover
costs for manual actions that exceed de-minimis, or simply not do them.

   A strong "SHOULD NOT charge" is appropriate.

   We could probably even get away with a "MUST NOT use" such DNSBLs
in that paragraph, although personally I'd prefer "SHOULD NOT charge"
and "SHOULD NOT use".

   In Section 2.2.2, the "MUST NOT use..." such that removal requests
would be blocked is a bit strong for my taste. DDoS attacks are very
real, and defensive action _is_ needed from time to time. I think a
strong SHOULD NOT is appropriate, and I'd suggest adding text to the
effect that the website "SHOULD list short-lived alternatives"
whenever the usual removal-request path may be blocked.

   In Section 3.4, the "MUST NOT list the entire Internet" is a bit
strong as well. While I think you have given plenty of suggested
alternatives to this, folks _do_ paint themselves into corners where
such a doomsday-weapon becomes needed. (Listing the entire Internet
_does_ mean they're outside the specification we're writing; but it
comes across as an attempt to control a behavior we can't control.
Perhaps we could suggest alternatives, not use the MUSTard, and say
that listing the entire Internet puts a DNSBL list out of conformance
with this set of practices.)

   Whatever, we should make sure that language about testing for
list-the-entire-Internet SHOULD be done is found within this Section.

====

   Overall, very good work!

--
John Leslie <[email-masked]>

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Jan 2011 16:57:00 -0500

On 1/18/2011 3:45 PM, John Leslie wrote:
> Douglas Otis<[email-masked]>  wrote:

> best, and this documents cannot make recommendations specific to IPv6.)

This is suggestive of a disclaimer to that effect up in the introduction.

I'm, however, hesitant in doing so.  My reasoning is as follows:

a) If IPv6 DNSBLs are impractical as some suggest, no useful ones will 
exist, the issue is moot, and no disclaimers are necessary.

b) If IPv6 DNSBLs are practical, then most of the policies are entirely 
IPvX neutral (and are in fact extensible to non-DNSBLs at that), and a 
disclaimer of that type would unnecessarily deprecate the useful 
policies that _should_ still apply to IPv6.

c) If IPv6 DNSBLs are practical, but some of the policies don't make 
technical sense, again the issue is moot, and no disclaimers are 
necessary.  Eg: rescan intervals: there's nothing that implies that 
rescans are necessary.  Hence, comments about rescanning of IPv6 entries 
being impractical or impossible doesn't invalidate a "minimum rescan 
interval" policy.  If you can't rescan, then, the minimum rescan 
interval policy is moot - by not rescanning at all, you still meet the BCP.

So, I don't see a hard conflict nor a necessity for such a disclaimer - 
at least not a blanket one.  Is there any MUST/SHOULD that _cannot_ be 
met by a plausible IPv6 DNSBL implementation and needs a specific 
disclaimer?

>     In general, we cannot enforce any behavior on list maintainers.

No, but we can encourage, and note/discourage what behaviours cause 
problems in the real world.

> costs for manual actions that exceed de-minimis, or simply not do them.

There are DNSBLs that do not charge for access and do not charge for 
manual actions.  In fact, there's only one DNSBL that I know of that 
still imposes financial costs surrounding delistings.  It ain't SORBS... 
  Michelle _herself_ suggested "MUST NOT".

But charging for removals demonstrably causes problems, such as people 
who refuse to bother with perhaps mistaken DNSBL listings because they 
view it as extortion.  Thus increasing the FP rate and impairing the 
accuracy for everyone else.

Not to mention the harm to the reputation of the mechanism as a whole.

A strong statement that this isn't acceptable behaviour can do nothing 
but good.

> in that paragraph, although personally I'd prefer "SHOULD NOT charge"

The goal of the BCP is to strongly encourage the best practises on the 
DNSBL admin side, but at the same time recognize that receivers can do 
anything they feel like as long as they know what they're doing.

IOW: a receiver can be in compliance even while using a DNSBL that's out 
of compliance.  Splitting between strong prohibition aimed at DNSBL 
admins and mild discouragement aimed at receivers was quite deliberate 
here.

Given that the "MUST NOT" only puts one known DNSBL out of compliance 
that I'm aware of, I'm comfortable with it.

> whenever the usual removal-request path may be blocked.

Remember that DDoS attacks are generally temporary, and there's nothing 
in the BCP that precludes changing the removal request process if/when 
it becomes necessary - see section 3.2.

The section is meant to mean that the DNSBL is privately contactable and 
not subject to the obvious screwup that the listee cannot contact the 
lister due to the listing or other routine spam filtering, not that it 
cannot be changed as circumstances necessitate.

> with this set of practices.)

Isn't that exactly what the section means?  Besides, heretofore, any 
DNSBL utilizing such a doomsday weapon was heralding their own doom - 
compliance becomes moot.

We have to really really _really_ discourage the practise so that 
receivers will know that listing-world is something they should not need 
to worry about.  But in the end, a DNSBL having to resort to it ain't 
going to care about compliance, and some of the provisioning 
recommendations are about making sure that list-the-world scenarios are 
not necessary.

> list-the-entire-Internet SHOULD be done is found within this Section.

It's the next section ... isn't that enough?

>     Overall, very good work!

Thanks!

---

From: David Nicol <[email-masked]>
Date: Tue, 18 Jan 2011 16:16:37 -0600

> b) I have minor reservations but don't object to publishing it, OK for

My minor reservation is  that I would like to see a "why DNS?" section
that describes the characteristics of an information distribution
scenario that make DNS a good choice of technology. This comes up
often here, usually in the form of millennial rants prophesying
eventual replacement by public (or non-public) rsync servers or such,
more or less. The characteristics of the problem domains that DNSxL
technology has been applied to are implicit in the introduction, but
are not enumerated in such a way that one might come away from
https://datatracker.ietf.org/doc/draft-irtf-asrg-bcp-blacklists with
vocabulary allowing the reader to classify information distribution
problems in a way that she might be able to confidently answer the
question "Is a DNSxL the correct distribution technology?" when
selecting.

Towards drafting a section to satisfy this criticism, the
characteristics to enumerate would be the characteristics of DNS that
make DNS appropriate for this application, from which we must go
through the motion of enumerating the (currently implied)
characteristics of the application that make DNS a good fit for it.
These characteristics include, but are not limited to:

   * setting of time-to-live -- variable time to cache, at record grain size
   * data only transmitted on as-requested basis
   * central administration, with possibility to explicitly delegate parts
   * existing well-understood software infrastructure

The inclusion of such a section could elevate the document from the
specific to the general, and set an example as a model for a best
practice in the composition of best practices documents: before
getting down and dirty with details confusing to the newcomer, spend a
paragraph answering the "why?" behind the deer-in-the-headlights
glaze.

Currently all we have in this realm is "Due to the rising amount of
spam and other forms of network abuse on the Internet, many community
members and companies began to create, publish and maintain DNS-based
reputation systems (DNS-Based Lists) of IP addresses or domain names
and make reputation suggestions or assertions about email sourced from
these IP addresses or domain names."

I would like to see that paragraph expanded to explain what it is
about reputation data that makes DNS a good technology for
distributing it, and what it is about DNS that makes it a good
technology for distributing reputation data, or other data (aside
from, of course, name to number mappings and their reverse) that
makes, or might make sense, to distribute by DNS.

In conclusion, start reading a biography of Mark Twain first thing in
the morning and you'll be loquacious all day.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Jan 2011 17:36:38 -0500

> the morning and you'll be loquacious all day.

Heh.

I can see the point.  A subsection of the introduction entitled "But why 
DNS?", and listing out your points plus a few more (like "DNS already 
exists and is ubiquitous", "it distributes in a global manner", "like 
wow, it works well").  A bit of a paeon to Vixie's serendipitous insight 
at a time when few would have thought of it.

But, I'm not sure that the BCP is exactly the place for that much detail 
of the historical justification of _why_ we do it this way.  Especially 
one that could  start up a religious war with the purists who've already 
screamed "but it doesn't return an IP address of a host!" even when it 
wasn't rubbed in their faces.

I dunno.  Other opinions?

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 18 Jan 2011 17:43:18 -0500 (EST)

>> best, and this documents cannot make recommendations specific to IPv6.)

IPv6 is mentioned only once, in Section 3.5, and not in a way that 
suggests DNSBLs for IPv6 are appropriate or practical. The document covers 
whitelists as well as blacklists, and it is not unreasonable to suppose 
that a whitelist could exist for IPv6 mail hosts. While I might prefer a 
vigourous denunciation of IPv6 blacklists, there isn't anything really 
objectionable in the draft on this topic.

Daniel Feenberg

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Jan 2011 16:01:38 -0800

On 1/18/11 2:43 PM, Daniel Feenberg wrote:
> suggests DNSBLs for IPv6 are appropriate or practical. The document 
> covers whitelists as well as blacklists, and it is not unreasonable to 
> suppose that a whitelist could exist for IPv6 mail hosts. While I 
> might prefer a vigourous denunciation of IPv6 blacklists, there isn't 
> anything really objectionable in the draft on this topic.
Daniel,

It is not the number of times that IPv6 has been mentioned in the 
draft.  It is the number of times an example proves wholly unreasonable 
when related to an IPv6 service.

In the rather critical matter, "2.2.1.  Listings SHOULD Be Temporary", 
this makes a questionable assumption that listing/de-listing churn will 
not become damaging whenever expiration is used.   Whether one is 
talking about v6 prefixes, or interface addresses, bad actors have 
access to virtually an endless supply of prefixes and interface 
addresses.  This means an address may never repeat over a bad actor's life.

Even the expectation that white-listing should be fine for v6 fails to 
consider cases where undefined translations may occur using shared 
resources.  Efforts aimed at codifying use of DNSxBLs would normally be 
commendable.  At this time, during the transition to IPv6, this draft 
only distracts from practical and well considered methods necessary to 
properly defend services operating within the v6 address space.  
Implications that DNSxL offers a reasonable service for use with v6 is 
instead counter productive and satisfies no immediate need.  Especially 
when attempts to use DNSxBL's for IPv6 address reputations are likely to 
prove damaging and problematic.

-Doug

---

From: John Leslie <[email-masked]>
Date: Tue, 18 Jan 2011 19:51:44 -0500

> This is suggestive of a disclaimer to that effect up in the introduction.

   It could go in Section 1.4 "Background", for example.

> exist, the issue is moot, and no disclaimers are necessary.

   Not a helpful argument. It supposes this document being read much
later than it's being issued (which could be true, but isn't our main
intent).

> policies that _should_ still apply to IPv6.

   This is false.

> interval policy is moot - by not rescanning at all, you still meet the BCP.

   We don't even know what "rescan" will mean in an IPv6 world -- it's
just too darn premature. I asked for a statement that IPv6 DNSBLs are
"a work in progress" and that this document "cannot make recommendations
specific to IPv6" -- both inarguably true.

   And we see plenty of evidence _within_ this RG that folks are thinking
s/4/6/ is an adequate heuristic -- which is inarguably false.

> met by a plausible IPv6 DNSBL implementation and needs a specific 

   We don't know. We don't even know what a "plausible IPv6 DNSBL
implementation" may turn out to be. (But it is very suggestive that
there is essentially nothing keeping a compromised IPv6 host from using
a different /128 for every connection it makes...)

> problems in the real world.

   MUSTard isn't about "encouraging" and "discouraging".

   Actually, MUSTard is an IETF thing, not an IRTF thing. We incorporate
RFC 2119 by reference, but we can't entirely know what baggage our
readers will bring.

> manual actions.

   For the most part, they don't _do_ manual actions.

> In fact, there's only one DNSBL that I know of that still imposes
> financial costs surrounding delistings.  It ain't SORBS... 

   And I disagree with Michelle -- though that's really not the point.
Chances are, the "offending" DNSBL will abandon that business model
soon, quite regardless of what we write here. The practice is being
abandoned because it's an unprofitable business model.

> view it as extortion.

   That's a business choice on their part. Even in IPv4, renumbering a
SMTP client/server is simple enough -- and I find myself willing to do
this to avoid even a $10 charge. (This is _not_ a particularly rational
tradeoff for my time!)

> Thus increasing the FP rate and impairing the accuracy for everyone else.

   "Everyone" ???

> Not to mention the harm to the reputation of the mechanism as a whole.

   (That sounds like a null set to me...)

> A strong statement that this isn't acceptable behaviour can do nothing 

   I don't mind a strong statement (though I don't expect it to have any
effect) -- I mind MUSTard which makes us look foolish.

   Specifically, consider:
" 
" Therefore, negative-connotation DNSBLs MUST not charge fees or
" require donations for delisting or "faster handling", and it is
" RECOMMENDED that such DNSBLs that do charge fees or require donations
" not be used.

   (Why is there a need to RECOMMEND not using what we declare to be a
null set?)

   You're letting your emotions rule here. There's a perfectly reasonable
business model I call "Vouching Service" where human judgment is needed
to verify that an event or practice which violated the rules has been
sufficiently rectified to again vouch for the offending whatever.

   This sort of service _really_should_not_ be prohibited. But to say
there may be no charge involved comes arbitrarily close to prohibiting
it. :^(
 
> anything they feel like as long as they know what they're doing.

   "MUST" in 2119-speak isn't "strongly encourage". Surely you can find
words (such as "strongly" and "encourage") to say what you mean.

> admins and mild discouragement aimed at receivers was quite deliberate 

   (I wasn't asking for "MUST NOT use"...)

> that I'm aware of, I'm comfortable with it.

   I'm uncomfortable "putting one out of compliance" in order to make a
statment likely to rather-soon reference the null set.

   If we say "MUST NOT charge", we should be talking about future
practices, not past ones. I feel pretty strongly about Vouching Services
being a useful tool.

> Isn't that exactly what the section means?

   To whom ??

   Seriously, it bothers me how often a reviewer notes a point of
confusion, and the response amounts to "What kind of fool could ever
be confused by that?" and not a single word of the document changes.

   Another set of eyeballs looking at a document is a Good Thing (TM).
A good Document Editor welcomes the opportunity to reduce confusion,
even at the expense of adding words to a document.

> Besides, heretofore, any DNSBL utilizing such a doomsday weapon was
> heralding their own doom - compliance becomes moot.

   Quite true -- so why do we need any MUSTard here?

> receivers will know that listing-world is something they should not
> need to worry about.

   Is "Pollyanna" your middle name?

   Face it: this happens. MUSTard won't change that. Receivers will
be better off to understand what happened _when_ they are hit by a
case of this.

> But in the end, a DNSBL having to resort to it ain't going to care
> about compliance,

   Agreed.

> and some of the provisioning recommendations are about making sure
> that list-the-world scenarios are not necessary.

   Howzzat?

> It's the next section ... isn't that enough?

   A forward-reference would be plenty.

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 18 Jan 2011 19:53:48 -0500 (EST)

On Tue, 18 Jan 2011, Douglas Otis wrote:

>> IPv6 is mentioned only once, in Section 3.5, and not in a way that suggests 
>> DNSBLs for IPv6 are appropriate or practical. The document covers 
> It is not the number of times that IPv6 has been mentioned in the draft.  It 
> is the number of times an example proves wholly unreasonable when related to 
> an IPv6 service.
>
> In the rather critical matter, "2.2.1.  Listings SHOULD Be Temporary", this 
> makes a questionable assumption that listing/de-listing churn will not become 
> damaging whenever expiration is used.   Whether one is talking about v6 
> prefixes, or interface addresses, bad actors have access to virtually an 
> endless supply of prefixes and interface addresses.  This means an address 
> may never repeat over a bad actor's life.

I am confused about why 2.2.1 is critical. Whether listings are temporary 
or permanent, an IPv6 DNSBL is totally impractical and probably worthless. 
I believe we agree there.  There are lots of things that can't be 
successfully distributed over DNS, this is only one of them. I might favor 
singling it out on the grounds that there are a few people who want to try 
it, but I wonder why it is so necessary to do so, since circumstances will 
defeat them soon enough.

Is there a special reason an IPv6 DNSBL which listed spam sources would 
interfere with legitimate traffic? Wouldn't it just get very large without 
actually ever blocking much traffic, legitimate or spam?

Daniel Feenberg

---

From: Steve Atkins <[email-masked]>
Date: Tue, 18 Jan 2011 17:05:33 -0800

On Jan 18, 2011, at 4:53 PM, Daniel Feenberg wrote:

>>> IPv6 is mentioned only once, in Section 3.5, and not in a way that suggests DNSBLs for IPv6 are appropriate or practical. The document covers whitelists as well as blacklists, and it is not unreasonable to suppose that a whitelist could exist for IPv6 mail hosts. While I might prefer a vigourous denunciation of IPv6 blacklists, there isn't anything really objectionable in the draft on this topic.
>> Daniel,
>> 
>> It is not the number of times that IPv6 has been mentioned in the draft.  It is the number of times an example proves wholly unreasonable when related to an IPv6 service.
>> 
>> In the rather critical matter, "2.2.1.  Listings SHOULD Be Temporary", this makes a questionable assumption that listing/de-listing churn will not become damaging whenever expiration is used.   Whether one is talking about v6 prefixes, or interface addresses, bad actors have access to virtually an endless supply of prefixes and interface addresses.  This means an address may never repeat over a bad actor's life.
> 
> I am confused about why 2.2.1 is critical. Whether listings are temporary or permanent, an IPv6 DNSBL is totally impractical and probably worthless. I believe we agree there.  

You both seem to assume that an IPv6 based blacklist would only list /128s. If you start from that assumption, you're reaching the right conclusion.

> There are lots of things that can't be successfully distributed over DNS, this is only one of them. I might favor singling it out on the grounds that there are a few people who want to try it, but I wonder why it is so necessary to do so, since circumstances will defeat them soon enough.
> 
> Is there a special reason an IPv6 DNSBL which listed spam sources would interfere with legitimate traffic? Wouldn't it just get very large without actually ever blocking much traffic, legitimate or spam?

No. DNS isn't a good way of  distributing blacklist data, for v4 or v6, but it's not entirely broken. 

As an example, an IPv6 blacklist that was distributed via DNS and typically listed in units of /48 would block quite a lot of traffic[1] - whether that would be primarily spam or primarily legitimate would depend on listing policy.

The blacklist zone itself wouldn't necessarily be any bigger than an equivalent v4 zone. Where you might see some bloat would be in caching resolvers, and you'd only see it there if a significant fraction of sources of email changed their IPv6 address often (where "often" means "several times during the blacklist TTL").

Cheers,
  Steve

[1] Assuming there'll be a lot of IPv6 SMTP traffic.

---

From: John Levine <[email-masked]>
Date: 19 Jan 2011 03:52:18 -0000

FYI, it wasn't Vixie.  He asked me to submit an erratum to 5782:

> Eric Ziegast, who was a system administrator for Vixie Enterprises
> where the RBL was hosted, created a DNS-based distribution scheme
> that quickly became more popular than the original BGP distribution.

I agree that this isn't a great place for a justification of DNS
distribution of BL/WL beyond the obvious fact that we've done it that
way since 1997, and there isn't anything else available off the shelf
that will do a lookup in a single UDP round trip and has widely
deployed caches.

I've been doing some simulations of DNSBL cache behavior, to compare
conventional record-per-IP DNSBLs with other approaches.  That may
evolve into an I-D and an RFC, so the merits or lack thereof of
various publication techniques could go in there.

R's,
John

PS: "paean"

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Jan 2011 20:07:18 -0800

On 1/18/11 4:53 PM, Daniel Feenberg wrote:
>> In the rather critical matter, "2.2.1.  Listings SHOULD Be 
>> Temporary", this makes a questionable assumption that 
>> listing/de-listing churn will not become damaging whenever expiration 
>> is used.   Whether one is talking about v6 prefixes, or interface 
>> addresses, bad actors have access to virtually an endless supply of 
>> prefixes and interface addresses.  This means an address may never 
>> repeat over a bad actor's life.
>
> I am confused about why 2.2.1 is critical. 
Back in October of 2008, it was apparent this group had strong 
expectation that DNSBL listings are to be fully automated with an 
emphasis on listing expiry.  Unfortunately, automated listings make it 
easy for bad actors to determine spam trap locations, where expiry also 
permits routine reuse of an often large and diverse IP address space.  
Some spammers cycle targets into different geographic regions often 
served by different listing services as well.

The Introduction states:

,--
This document is not applicable to some DNSBLs in some areas (mentioned as appropriate) but it is the authors' belief that most of the practices are applicable to almost all DNSBLs.
'--

In addition, this draft describes a requirement to delineate listing 
criteria with auditing to be made available.  It even suggests exclusion 
of information that might reveal the location of a spam trap.  Any audit 
information reveals spam trap locations.  There is now an increase level 
of abuse emitted by bulk senders that "wash" their lists of detected 
spam traps.  :^(

The draft also wants disclosure whether a range of IP addresses might be 
listed that could include undetected addresses, and then describes such 
listings as a "mistake".  It also makes _no_ reference to a boundary of 
such ranges not crossing those controlled by different Autonomous 
Systems (network providers).   It also claims fast listing mechanisms 
benefit from very short expiration intervals.  Once again, this wholly 
ignores problems related to the disclosure of the spam trap infrastructure.

This draft also claims that listings based upon longer time periods have 
higher error rates and states that responses to removal requests SHOULD 
occur within 2 days and MUST occur within 7 days.  This draft also 
suggests that network operators should not be required to resolve abuse 
issues because this requires "impractical amounts of effort" and even 
recommends "no questions asked" removals.  This draft further states 
that removals should be possible in absence of DNSBL Operators.  This 
does not describe policies that are appropriate for IPv4, and certainly 
it would be wrong to suggest these policies might also be applied 
against IPv6.

The only reference to listings methods references rfc5782 which does not 
directly expose CIDRs used to make the listings.
> Whether listings are temporary or permanent, an IPv6 DNSBL is totally 
> impractical and probably worthless. I believe we agree there.  There 
> are lots of things that can't be successfully distributed over DNS, 
> this is only one of them. I might favor singling it out on the grounds 
> that there are a few people who want to try it, but I wonder why it is 
> so necessary to do so, since circumstances will defeat them soon enough.
This nonsense serves as a distraction where valuable time is lost in 
getting ready for the use of IPv6.
> Is there a special reason an IPv6 DNSBL which listed spam sources 
> would interfere with legitimate traffic? Wouldn't it just get very 
> large without actually ever blocking much traffic, legitimate or spam?
Yes.  Standards organizations need to clearly state that IPv6 REQUIRES 
the use of domain name authentication as a basis for acceptance.  
Negative listings represent an impossibility, and positive listings will 
likely be problematic unless based upon cryptographically authenticated 
domain names.

-Doug

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Jan 2011 23:39:13 -0500

On 1/18/2011 7:51 PM, John Leslie wrote:
> Chris Lewis<[email-masked]>  wrote:

> later than it's being issued (which could be true, but isn't our main

I don't see how _when_ the document is being read is relevant.  If they 
read it in the future when IPv6's are known to be impractical, they'll 
know it's moot.  If they read it now, and IPv6 DNSBLs turn out to be 
impractical, they'll run into the reality wall that proves it's moot.

We don't _know_ IPv6 DNSBLs are impossible.  And frankly I don't think 
they are, unless you presuppose that listing /128s are the only way. 
Listing only /32s isn't true in IPv4 land, there is no reason to believe 
that that would change in IPv6.  In fact, the contrary it will almost 
certainly become necessary for any DNSBL to be "profitable".

Let me cut to the chase here:

I can see a relatively easy way to maintain the usefulness of even 
(present) /32-listing style DNSBLs in an IPv6 world (eg: either fixed or 
adjustable granularity to match or roughly match real/likely end-user 
allocation sizes) with only complexity being to deal with the cache 
blow-up problem.  And I don't see any of that which would force IPv6 
DNSBLs implemented that way violating any of the MUSTs or SHOULDs.  Some 
of that may obviously be impacted by IPv6 DNSBL standardization efforts, 
or I may be wrong about some of the MUSTage/SHOULDage, but there's 
nothing to stop the issuance of a new BCP around IPv6 specifically that 
deals with that.

Better to have general guidance in place that will probably work for the 
most part and might need a bit of later tweakage, than to throw up our 
hands and provide no guidance at all.

>     This is false.

You're going to have to explain a bit more than that.

> specific to IPv6" -- both inarguably true.

There aren't any recommendations specific to IPv6, all of the examples 
are specific to IPv4, so is the statement even necessary?  I don't 
object to the statement _except_ for the reason given in (b) above where 
you didn't elaborate beyond "this is false".

[Can I say that I don't like discussion by bare assertion? ;-)]

"rescan" is used within the document in a very specific context - that 
of probing systems for security faults.  It could only be used in the 
same context in IPv6.  If /128 hopping is truly going to be as 
ubiquitous as people may think, the form of probing inferred by the 
context will be impossibly expensive.  Hence, specifying a minimum 
interval is moot.  They'll either know that ahead of time, or find out 
quickly enough.  In terms you use later - "it'll be unprofitable".

> s/4/6/ is an adequate heuristic -- which is inarguably false.

And DNSBLs constructed in that basis would, even I would assume, just 
about useless and probably wouldn't live long enough for the BCP to matter.

We don't have to make policy for the unworkable.

> (But it is very suggestive that

Not really suggestive.  Postulate Doug's scenario.  Every compromised 
host spits out a spam on a different /128 every time.  DNSBLs confounded 
by this will be entirely "unprofitable" and they won't exist for long.

Most of the policy is technology/query format neutral - and those that 
aren't will either be implementable in some sort of IPv6 analogue (which 
is up to a format specification for IPv6 DNSBLs), or not implementable 
at all.

>     For the most part, they don't _do_ manual actions.

I have significant background in this area.  I assure you, except for 
the toy ones, even the free ones do manual action, and some fairly 
extensively.

[Oddly enough, it's the commercial ventures that seem to do the least. 
Many of the commercial ventures make even SORBS look impossibly 
responsive.  Steve might yell about C&C warnings, but I think he'd have 
to admit it's true ;-)]

> abandoned because it's an unprofitable business model.

Actually, that's not why Michelle abandoned it.  She was always 
uncomfortable with it, and said so, but thought it necessary due to 
technical implementation limitations and the avoidance of gaming.  When 
the implementation changed that calculation changed, and the perceived 
necessity went away.

Even so, most disagreed with her necessity calculation including 
virtually all of the DNSBL admin community I know (and I know rather a 
lot of it).

>     "Everyone" ???

Yes, everyone.  A, say, ISP's broad refusal to deal with a DNSBL's false 
positives because of orthogonal perceptions of extortion, blackmail or 
protection racket worsens the false positive rate of that DNSBL.  This 
can only be untrue if you assume that every DNSBL is perfect. 
Unfortunately, they aren't.

>     (That sounds like a null set to me...)

I think it's provably not a null set ;-)

> effect) -- I mind MUSTard which makes us look foolish.

H'mm - beginning of parenthetical comment - see below.

>     (Why is there a need to RECOMMEND not using what we declare to be a

It's demonstrably not a null set.

>     This sort of service _really_should_not_ be prohibited.

You're right, it shouldn't.  And it isn't.

> But to say

I disagree with that through existence proofs ;-)

> words (such as "strongly" and "encourage") to say what you mean.

Parenthetical comment (from "H'mmm"):

Lemme think a bit more/experiment on using non-RFC 2119 language for 
this and I'll get back to y'all.

> practices, not past ones.

Right.

> I feel pretty strongly about Vouching Services being a useful tool.

Me too, but that doesn't necessitate charging for repair of involuntary 
inclusion in negative connotation DNSBLs.

We have to very much keep in mind some of the wording from the BCP 
surrounding negative connotation DNSBLs and the fundamental difference 
between DNSBL and more traditional potentially negative vouching 
services we know of.  Namely, the human factor.

When a restaurant reviewer says someone's restaurant sucks, the 
restaurant goer has to make a conscious choice to accept/reject that 
advice for that restaurant.

In contrast, a DNSBL can literally make the site disappear for all of 
their users, and the user wouldn't necessarily know it then or ever.  If 
the DNSBL does "repair" of that unasked for negative vouch for profit, 
it becomes more an extra-judicial fine with little if any oversight.

Imagine if you will restaurant reviewers charging restaurants for a 
re-review of bad vouches.  Just how well do you think that would be 
received by _anyone_?   Even more so with DNSBLs.

> be confused by that?" and not a single word of the document changes.

I assure you it wasn't intended that way.  The problem is that I don't 
see suggestions that aren't already implemented.

Without a "MUST NOT", how can we say that doing so puts someone out of 
compliance?

Alternatives are given, etc.

Is it intra-document pointers I'm missing?  Is it just unclear?  What?

>     Another set of eyeballs looking at a document is a Good Thing (TM).

Absolutely.

> even at the expense of adding words to a document.

I'm just a bit confused as to which words.

>     Quite true -- so why do we need any MUSTard here?

Unlike most other "standardization" (or whatever) efforts, DNSBLs are 
sometimes a highly charged emotional/political issue.  As such, it is of 
significant value to reduce the FUDage:

- Demonstrating to DNSBL users and others that such behaviour is out of 
bounds.
- Demonstrating that a bit of fore-thought in DNSBL setup from the 
beginning obviates the possibility of being painted into a corner where 
such may become necessary.

[The howzzat is below]

>     Is "Pollyanna" your middle name?

I'm Canadian.  Does that answer your question? ;-)

>     Howzzat?

Virtually all list-the-world scenarios come about because of name server 
blowout/overload due to DNSBL shutdown and an attempt to keep the base 
domain useful for other purposes in future.  Listing the world is an 
attempt to get everybody still using the DNSBL to stop using it and 
thereby shed DNS load.

If the DNSBL is implemented using the recommendations in the BCP, you 
can mitigate load/avoid server blowout _without_ listing the world and 
_still_ communicate (in a non-destructive manner) a fairly obvious 
signal that the users should stop using it.

The other scenario is if the domain simply expires, someone else picks 
it up, and promptly gets blown out by NS queries and fumbles along far 
enough to learn about DNS wildcarding and letting fly.

This too has happened.

At least domain owners can be pointed to this document as a means by 
which they can do the same rather than barging around blowing up random 
mail servers.

[I should point out that this section of previous drafts of this 
document have already proven valuable in real-world occurrences of 
_both_ scenarios.]

>     A forward-reference would be plenty.

Sorry, should have asked that instead.  Okay.

---

From: David Nicol <[email-masked]>
Date: Wed, 19 Jan 2011 09:52:31 -0600

> received by _anyone_?   Even more so with DNSBLs.

Restaurant reviewing is luxury, not infrastructure. Revise to "health
departments" and it seems entirely reasonable.

> I'm Canadian.  Does that answer your question? ;-)

I for one eagerly await the Canadian invasion, with their quaint paper
ballots. I shall throw flowers from my balcony.

-- 
“The aeroplane is fatally defective. It is merely a toy—a sporting
play-thing.  It can never become commercially practical." -- Nikola
Tesla

---

From: David Nicol <[email-masked]>
Date: Wed, 19 Jan 2011 10:17:50 -0600

> that will do a lookup in a single UDP round trip and has widely

Here's a draft extended version of the introduction:

"The rising amount of spam and other forms of network abuse on the
Internet led to sys-admins compiling lists of sources from which
e-mail was usually undesired. As DNS provides quick distribution of
fine-grained updates and performs lookups in a single UDP round trip
and only as needed, many community members and companies began to
share their data through creation, publish and maintainence of
DNS-based reputation systems. These "DNS-Based Lists" of IP addresses
or domain names contain entries with reputation ratings useful as
suggestions or assertions about e-mail originating from these IP
addresses or domain names."

END OF REVISED PARAGRAPH

But wait, there's more!

Furthermore, there apparently exist back-channels for mirroring the
whole database that are currently in use in high-volume situations.
Perhaps that deserves a mention? A new section on sharing one's list
via methods other than DNS?

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 19 Jan 2011 12:05:35 -0500

On 1/19/2011 11:17 AM, David Nicol wrote:
> On Tue, Jan 18, 2011 at 9:52 PM, John Levine<[email-masked]>  wrote:
>

> via methods other than DNS?

I think I like the first part - slipping in more justification of DNS 
without making a big/distinct thing about it.

As for the second: Yes, it could be mentioned, but I think it should be 
in the introduction with a mention that standardizing and/or BCP'ing 
zone transfer is beyond scope.  Would it be appropriate to go as far as 
mentioning "commonly via rsync of a DNS server zone file format"?  Not 
to force everything into that mold, just to indicate the most common way?

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 19 Jan 2011 12:43:10 -0500

On 1/19/2011 10:52 AM, David Nicol wrote:
> On Tue, Jan 18, 2011 at 10:39 PM, Chris Lewis<[email-masked]>  wrote:
>

> departments" and it seems entirely reasonable.

Health inspections are a regulatory/legal requirement - compliance is 
legally mandatory, and if there are fines, that's also part of the 
legislative framework.  Not to mention that there's usually only one you 
have to deal with.  It's part of the implicit (or explicit) societal 
contract that a restaurant undertakes to comply with by existing.

That's a huge qualitative difference between that and some random 
self-selected guy showing up at the cash register who says "your bacon 
was horrible, pay me money or I'll shut you down".  Those guys usually 
carry baseball bats.

> ballots. I shall throw flowers from my balcony.

We aim to please ;-)

---

From: David Nicol <[email-masked]>
Date: Wed, 19 Jan 2011 12:49:46 -0600

On Wed, Jan 19, 2011 at 11:43 AM, Chris Lewis <[email-masked]> wrote:

> self-selected guy showing up at the cash register who says "your bacon was
> horrible, pay me money or I'll shut you down".  Those guys usually carry
> baseball bats.

I will not be silenced by creative use of violent imagery! The
question under discussion is something like "should the BCP document
contain guidance concerning compensation for preferential treatment?"
in specific, should the section now numbered 2.2.5:

2.2.5.  Conflict of Interest

   Some DNSBLs used for blocking/negative reputation have had a
practise of requiring fees or donations to charities from the listee
for delisting.

   It is generally considered entirely appropriate for a DNSBL to
charge for access to it by its users - the definition of a commercial
DNSBL.

   However, the practise of requiring a listee to pay for delisting
from a negative connotation DNSBL steers perilously close to notions
of extortion, blackmail or a "protection racket".  Even if such
accusations are entirely unjustified the practise causes uproar and
damage to the DNSBLs reputation, if not the entire DNSBL mechanism as
a whole.  Colloquially, "it smells bad".

   Therefore, negative-connotation DNSBLs MUST not charge fees or
require donations for delisting or "faster handling", and it is
RECOMMENDED that such DNSBLs that do charge fees or require donations
not be used.

END SEC. 2.2.5 EXTRACT

be changed?  It looks okay to me, as long as we are painfully,
explicitly clear that the "users" are sys-admins and not end-users.

The thing is, the random self-selected guy doesn't have all the power
he says he has. Were he honest, instead of "your bacon was horrible,
pay me money or I'll shut you down" he would be threatening "your
bacon was horrible, pay me money or I'll list you on my list of places
where I didn't like the bacon."

A good example of real-life reputation listing services are lists
that, for instance, enumerate places that were not able to satisfy
requirements of a food intolerance.

Such as this whitelist:
http://www.yelp.com/search?find_desc=gluten+free&find_loc=Chicago,+IL

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 19 Jan 2011 16:00:16 -0500

On 1/19/2011 1:49 PM, David Nicol wrote:

> I will not be silenced by creative use of violent imagery!

Canadians?  Violence?  Michael Moore says there's no crime here, so it 
can't be so ;-)

> [2.2.5] be changed?  It looks okay to me, as long as we are painfully,

I think it is, isn't it?

> where I didn't like the bacon."

In the DNSBL world, a popular blacklist listing can cause more than 50% 
of their email to get blocked in such a way that most recipients don't 
know that it's happening.  They've abruptly disappeared email-wise, for 
a huge chunk of the Internet.  This is far more than midway between an 
end-user advisory that an end-user can choose to ignore or accept, and a 
health-department mandated door shutting.

> http://www.yelp.com/search?find_desc=gluten+free&find_loc=Chicago,+IL

The phraseology I used was for blacklists, not whitelists, these are 
end-user advisories that can be ignored/accepted by the end-user, and do 
they take kickbacks?  ;-)

Do you know of negative advisories that take money for delistings of 
entities that _didn't_ subscribe to the advisory service?  I don't, 
except for the criminal code ;-)

---

From: David Nicol <[email-masked]>
Date: Wed, 19 Jan 2011 15:28:03 -0600

>> explicitly clear that the "users" are sys-admins and not end-users.

I don't know if it is nor not in the draft BCP document, but it's
crazy muddled in this discussion.

> In the DNSBL world, a popular blacklist listing can cause more than 50% of
> their email to get blocked in such a way that most recipients don't know
> that it's happening.  They've abruptly disappeared email-wise, for a huge
> chunk of the Internet.  This is far more than midway between an end-user
> advisory that an end-user can choose to ignore or accept, and a

And is the system working as designed, "protecting" the recipients
from alleged annoyance.  Does the BCP draft have a section advising
the consumers of the lists, as well as the providers of the lists?
Recommending that a list consumer provide per-recipient configuration
WRT protection by the various ones --- some of the people on the
qpsmtpd list discuss their per-recipient configuration database hacks,
I don't know what the general state of the practice is in 2011

> entities that _didn't_ subscribe to the advisory service?  I don't, except
> for the criminal code ;-)

http://yourbiz.msnbc.msn.com/_news/2008/05/13/4355660-staying-off-the-better-business-bureaus-bad-boy-list
suggests "... take the time to sit down with their local BBB and
discuss ..." which is not free.

Of course if it became known that the BBB accepted bribes for
delisting, that would hurt their reputation.  I think attempting to
mandate the mechanics of reputation will be futile, maybe 2.2.5 could
be weakened to be strictly descriptive, yet provide advice for the
reputation-mechanically-impaired?

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jan 2011 14:31:17 -0800

On 1/19/11 1:00 PM, Chris Lewis wrote:
> In the DNSBL world, a popular blacklist listing can cause more than 
> 50% of their email to get blocked in such a way that most recipients 
> don't know that it's happening.  They've abruptly disappeared 
> email-wise, for a huge chunk of the Internet.  This is far more than 
> midway between an end-user advisory that an end-user can choose to 
> ignore or accept, and a health-department mandated door shutting.
Chris,

Networks containing millions of individual sources of abuse are often 
most effectively handled by policies enforced by their network 
providers.  Policies promoted by this draft overlook network provider's 
role.  Only network providers are able to block abuse and determine 
whether abuse has been mitigated by their customer.  Third-parties 
monitoring network traffic see only a tiny fraction of any overall 
abuse.   Listing stratagems that aid list-washing techniques further 
reduce the effectiveness of important third-party monitoring.

It seems this draft has a goal to make third-party monitoring 
ineffective, and to avoid the corrective actions that may need to be 
taken by network providers.  It is not a mistake to list networks 
replete with abuse.  When a network provider is unwilling to stop 
commerce of abuse (tainted bacon), listing their network gets their 
attention.  Their angry customers are free to seek services from other 
responsive providers.  The original abuse listings were distributed as 
BGP filters.  It seems future listings of IP addresses will likely need 
to return to this model in order to scale to the larger IP address space.

Of course, positive reputations by domain name work well with DNS, and 
would be independent of the network provider.  It seems this draft 
misses an opportunity to better lay out how services can be supported in 
the future.  We continually need to counter the erosion caused by 
"automated" abuse listings and mailing-list washing.  IPv6 will make 
obscuring spam traps and selectively reacting to individual IP addresses 
impossible.  :^(

-Doug

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 20 Jan 2011 01:52:55 -0500

On 1/19/2011 4:28 PM, David Nicol wrote:
> On Wed, Jan 19, 2011 at 3:00 PM, Chris Lewis<[email-masked]>  wrote:
>

> crazy muddled in this discussion.

Really?  I don't think end-user came up at all, and the BCP doesn't talk 
about it.  It's quite clear in the BCP that it's talking about 
list-users and list-owners, not end-users.

> the consumers of the lists, as well as the providers of the lists?

Yes.  List-owner vs list-user distinctions are covered in the draft BCP 
quite substantively in a number of areas.

> I don't know what the general state of the practice is in 2011.

Recipient filtering policy, mechanisms and implementation are well out 
of scope for this document _except_ where they directly relate to DNSBLs.

I've been wanting to write a more general BCP on filtering from the 
receiving perspective, but it'd probably be quite hard to achieve 
something reaching consensus without diluting it so far that it doesn't 
mean anything.  There are strong feelings in a number of different 
directions.  It may more end up as a series of scenarios enumerating 
pros and cons of each.

[Aside:

As an educated guess (and knowing that we're not entirely atypical ;-), 
most sites will have the same filtering for everyone.  Many do provide a 
recipient-adjustable whitelist-by-sender knob and either a 
blacklist-by-sender knob or a TiS button, but seldom more than that.

Commercial offerings (esp. 3rd party MX-handlers) tend to not have much 
per-user configurability beyond sender whitelisting.  Not because it's 
hard (it isn't), but because few are asking for it, hence it's not worth 
implementing.

There are some practitioners who wax quite extreme on substantive 
per-recipient configurability (eg: some of those on the qpsmtpd list 
;-), but the reality is that the number of people who'd actually _use_ 
such knobs would be extremely small, and still fewer who could adjust it 
effectively.  If they had such knobs, after the bombardment, experience 
suggests that they'd usually turn it right back on again (pushing the 
knobs too far ;-) and/or scream we should be filtering _that_ crap.  Or 
sue.  Or the admins get arrested[+].  Sigh. :-(

Corporates, and GOV sites generally do not have end-user configurability 
at all except for perhaps individual sender partial whitelisting. 
Audit/CorpSec tend not to like people potentially turning off A-V or 
policy-imposed "not on our equipment!" filtering (which may or may not 
fit the definition of spam).

Our filtering is across the board.  We have the ability to whitelist 
senders (in any of a variety of ways) or bypass filtering for specific 
recipients.  End-users can ask for such, but they can't set it 
themselves.  Each request is checked.  Things causing false positives 
with business operation are dealt with routinely - it's part of the 
filtering process _itself_ - our filtering is good enough that these are 
rare.  Similarly with most non-business related stuff (we have a pretty 
liberal policy about reasonable personal use - many corps don't).  Full 
blown bypass every filter sender whitelisting is almost never done (I 
can count the number of instances on one hand, most of them are on 
anti-spam/anti-virus mailing lists that either I or the virus team lead 
are on).  There's only two recipients that don't get filtering - our 
filter FP handling contact address and our registration contact address.

In 13 years of filtering, we've only had three people (peak user 
population: 120,000) ask to get out from behind filtering.  We said no. 
  It's not that big an issue if you do sender-signalling on rejects 
and/or provide methods for receivers to find out what was blocked and 
how to deal with it.

As I understand it, govs (particularly LE) often don't have any 
whitelisting/filter bypass capabilities whatsoever and/or refuse to use 
them by policy.  It's awesomely annoying sometimes when you can't get 
them a sample of what they asked for, even if via a mailing list 
intended for the purpose.

end of aside]

> reputation-mechanically-impaired?

This is the same argument as saying "we don't need a law against X, 
because it won't stop people from doing X".  Well of course.  So what? 
Without it, you don't know that X is bad, and you have no way to deal 
with people who did X anyway.  A BCP does the former.  Obviously, a BCP 
can at most wave a "bad boy!" wand (is that non-violent enough? ;-) over 
the latter.  But that's important too.

[+] Read your sexual harassment in the workplace legislation sometime. 
If it's anything like what we have, the admins can go to jail, there is 
no "corporate shield" on that bit.

---

From: John Levine <[email-masked]>
Date: 20 Jan 2011 17:13:04 -0000

>;-), but the reality is that the number of people who'd actually
>_use_ such knobs would be extremely small, and still fewer who could
>adjust it effectively.

Some years ago I was talking to abuse people at a large cable ISP.
They said their old filters didn't work very well, and their users
were constantly demanding configurable whitelists and special cases.
Then they switched to a new filter that worked a lot better, and the
requests just stopped.

It shouldn't come as a big surprise that users' mental models are not
the same as ours, and frequently don't match what's really going on.
It generally doesn't occur to them that the problem is that their
filters just don't work very well, so they assume that whatever
they've got is the state of the art, and the only way to make them
work better is to add special cases to fix the mistakes.  But in fact,
a well tuned filter makes very few mistakes.

I suppose that if you are the only researcher at your institution
working on erectile dysfunction, you might need special exceptions,
but other than that, special cases tell us that the filters are
broken.

R's,
John