Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

"Chris Lewis" <clewis@nortel.com> Mon, 10 November 2008 05:59 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322203A6A17; Sun, 9 Nov 2008 21:59:47 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2B73A6A17 for <ietf@core3.amsl.com>; Sun, 9 Nov 2008 21:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.904
X-Spam-Level:
X-Spam-Status: No, score=-4.904 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF84fAieW7Ct for <ietf@core3.amsl.com>; Sun, 9 Nov 2008 21:59:44 -0800 (PST)
Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 592D53A69E9 for <ietf@ietf.org>; Sun, 9 Nov 2008 21:59:44 -0800 (PST)
Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAA5xaI01738 for <ietf@ietf.org>; Mon, 10 Nov 2008 05:59:36 GMT
Received: from [47.130.80.59] ([47.130.80.59] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Nov 2008 00:59:36 -0500
Message-ID: <4917CDC5.1010408@nortel.com>
Date: Mon, 10 Nov 2008 00:59:33 -0500
From: Chris Lewis <clewis@nortel.com>
Organization: Nortel
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
CC: ietf@ietf.org
Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
References: <20081107111744.GA31018@nic.fr> <20081107141821.79303.qmail@simone.iecc.com> <45AEC6EF95942140888406588E1A660206A5D881@PACDCEXCMB04.cable.comcast.com> <4914D181.9090605@network-heretics.com> <278E245FD800CC334CA5100F@klensin-asus.icannmeeting.org> <4917BB4B.8000802@att.com> <20081109235116.3ef7e2f2@cs.columbia.edu>
In-Reply-To: <20081109235116.3ef7e2f2@cs.columbia.edu>
X-OriginalArrivalTime: 10 Nov 2008 05:59:36.0617 (UTC) FILETIME=[82D6B990:01C942F9]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Steven M. Bellovin wrote:
> On Sun, 09 Nov 2008 23:40:43 -0500
> Tony Hansen <tony@att.com> wrote:

> In some sense, I have more trouble with white lists than black lists.  
> 
> My concern is centralization of power.  If used properly, white lists
> are fine.  If used improperly, they're a way to form an email cartel,
> forcing organizations to buy email transit from a member of the inner
> circle.

Hi Steven, long time...

Sort of a protection racket.

This only works insofar as the mail receivers (the ones who choose to
deploy a whitelist) is willing to let them.  Receivers are driven, first
and foremost, by their users's complaint rates.

Receivers will notice increased complaint rates from a whitelist like
this, and begin to discount their input.  As they also do with FP rates
on the blacklists they use.  We see that now in take-up rates of various
DNSBL/DNSWLs.

Much as, say, people realized that TrustE logos didn't mean very much.

There's a much larger potential with proprietary reputation systems -
the buy-in costs are high, so it eventually becomes impossible for new
reputation vendors to get into the act, and receivers are reluctant to
switch vendors because they have to put yet another proprietary thingie
in their MTAs.

[A few years ago, at a MAAWG session, I caused a bit of slack-jawed
consternation when I strongly put forth the idea that reputation vendors
had to move to open protocols if they wanted acceptance at more than a
few of the very largest ISPs that could afford it.  I'm glad to report
that at least one or two have since seen the light.]

In an standard protocol environment, startup costs are minimal,
receivers find it very easy to switch or mix-and-match.

Same goes with negative reputation.

A standardized open protocol greatly reduces the likelyhood of cartelish
behaviour.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf