Re: [Asrg] Getting group consensus on draft-irtf-asrg-bcp-blacklists

On 3/1/2011 6:46 PM, Jason Bertoch wrote:
> On 2011/03/01 3:28 PM, John R. Levine wrote:
> > Now that the kerfuffle seems to have died down, I'd like to see if we
> > have group rough consensus (which does not mean perfect unanimity) on
> > the BL best practices overview. Please read through it and say whether
> > you think it's OK, or if not, what specific language to change.
> I still find myself stuck on 2.2.5.  It needs to be removed or changed to not 
> pick on negative-reputation lists.
>
> As this BCP already describes, many (most?) DNSBL's are used as part of an 
> overall scoring system, rather than just at the MTA level.  As such, removal 
> from a negative-reputation list generally has the same net effect as addition 
> to a positive-reputation list.  (Actually, ReturnPath is considered quite 
> favorably in SpamAssassin.)  Any arguments against paid removal from a neg-rep 
> list can be equally applied to paid addition to a pos-rep list.
The BCP describes that they _can_ be used in an overall scoring system. 
 Everything I've seen seems to indicate that the majority of use isn't 
scoring.  The very largest environments don't, for example.
One of the crux arguments here is why negative-reputation lists are 
being "picked on".
After all, isn't blacklist removal the same as whitelist addition?

Mathmatically, at least in scoring, of course, they are the same.

But, that's where the similarity ends.  They are worlds apart ethically, 
legally and practically.  Just as Steve Atkins said.
We need to see the big picture here.

I don't want to dwell too long on the ethical/legal issues too much, 
other than to point out that charging a fee for not saying/stop saying 
something bad about someone meets at least a general definition of 
extortion or blackmail.
Whereas charging someone to say something good is just ordinary advertising.

The former is paying to undo the reputational damage someone did without 
invitation (and perhaps without justification), the latter is to improve 
the reputation voluntarily.
Of course, there are many reasons where payment for delisting generally 
won't meet legal definitions of extortion or blackmail, not to mention 
the CDA's protections, but (a) those are largely jurisdictionally 
dependent and (b) it really doesn't matter for practical reasons.  Those 
same practical reasons apply in edge-case.
Practical reasons?  They abound.  Throughout my involvement in many 
portions of the industry, it's clear:
1) Providers of all types & stripes simply won't deal with DNSBLs they 
believe to be unethical.  I see comments like that from very large 
providers almost every day.  Many others on this list frequent the same 
places I do, and see them as well.  Good responsive providers who 
remediate other DNSBL listings quickly and effectively simply refuse to 
have anything to do with the perceived "unethical" ones.  They don't fix 
problems, they don't educate users, they encourage people to ignore them.
2) Many organizations simply won't use DNSBLs they believe to be unethical.

3) Paying for delist, while it might not make a great deal of difference 
in overall effectiveness if the DNSBL is good enough to redetect and 
relist quickly, many DNSBLs are not, and can massively impair accuracy. 
 Not to mention legal problems if you're not really careful about what 
the payment actually buys the listee.
4) (1) and (2) are very significant factors, and they in turn lead to:
   a) Real spamming problems don't get resolved, and they continue
      unabated.
   b) False positives don't get resolved, and they continue unabated.
   c) Uptake of a DNSBL is reduced, their usefuless declines.
   d) The bad reputation of an individual DNSBL inevitably leaks to the
      mechanism as a whole (just see IETF diatribes for example).
   e) providers don't educate their users what they're doing wrong
   f) DNSBLs get screamed at for unethical behaviour...
   g) DNSBLs scream back...
   h) everybody acts like children...

These are all bad for the receivers of email and the industry as a whole.

5) For the most part, a blacklist hit is more likely to have a negative 
effect on delivery than a whitelist hit having a positive one.
I'm sure you're scratching your head with this one.  The reality is that 
application of whitelisting in an overall receiver-advantageous  way is 
far more difficult than applying blacklisting, and the results of 
getting it wrong can be far more obvious.  huh? (again ;-).  _Few_ 
people apply whitelists (or at least 3rd party ones) as "allow 
everything through", because it's too dangerous - you allow 
viruses/malware or contra-policy material in for example.  Application 
of whitelisting properly is a delicate operation.  In scoring systems, 
they tend to have small positive scores, whereas many individual 
blacklists have large negative ones.  Or they don't score at all, and 
DNSWLs only apply to _parts_ of the filters.  Etc.
Example: in our system, our local DNSWL can get you past any DNSBL 
listings - but not the ancilliary string filters, SpamAssassin or 
ClamAV.  3rd party DNSWLs have _slight_ positive scores in our DNSBL 
engine.  They can get you past one DNSBL listing, but not two.
6) Hankypanky/sloppiness with whitelisting is usually much easier to 
spot - complaints jump, and if they correlate with a whitelist...  Yes, 
receivers watch these things closely and take action.
{RSK: you asked for an example.  I've got a good one.  Email me and I'll 
tell you.  But it's not for public consumption.]
7) "Express" and "charity" - in the end, the distinction doesn't matter 
for (1) or (2).  Proof?  They don't in real life.
Missing the distinction is, of course, probably wrong, but distinction 
or not, the results are the same.
They haven't mattered with UCEProtect or SORBS.  Consider: UCEProtect 
has been around for a while.  Some of their lists are relatively useful. 
 Claus just said they "protect" 2.5M users.  That isn't a lot. In fact, 
it's tiny.  Other DNSBLs without these problems have _individual_ users 
that are 2 orders of magnitude larger.  It's not the only reason of 
course, but it's one of them.  The effect isn't so severe with SORBS, 
but I do think it's fair to suggest that they would have evolved further 
without it.
Personally, I don't think "express delist for a fee" or "donation" are 
all that bad.  But in the end, that subtlety is lost, and all the 
practical harm acrues anyway.
In the end: other DNSBLs have thought long and hard about this for 
years.  Consider, for example, the universal condemnation of this 
practise from every DNSBL (with the obvious exception of UCEProtect) 
that's said something here.  Notice that SORBS agreed with the BCP. 
Consider for example, the lengths to which the CBL distances itself from 
this practice in its FAQ.  Witness what deliverability experts say about 
them.  ISPs.  Etc.
All of my experience indicates that the consequences of this are so 
severe that it's best for _everyone_ to stay as far clear of it as 
possible.  This is one of those cases where an "appearance of 
impropriety" is just as bad as just plain "impropriety".
Perhaps something will come along to change that.  I doubt it.  But it 
ain't all that hard to draft a successor document and change it.  Better 
to get the stake driven in (thanks Rich for the imagery ;-)



_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg