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

Theodore Tso <tytso@mit.edu> Tue, 11 November 2008 14:39 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 5EDE428B797; Tue, 11 Nov 2008 06:39:16 -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 D5DD928C0FD for <ietf@core3.amsl.com>; Tue, 11 Nov 2008 06:39:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.696
X-Spam-Level:
X-Spam-Status: No, score=0.696 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, 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 TTfOW0-ESD5h for <ietf@core3.amsl.com>; Tue, 11 Nov 2008 06:39:14 -0800 (PST)
Received: from thunker.thunk.org (unknown [69.25.196.31]) by core3.amsl.com (Postfix) with ESMTP id E8E433A6B15 for <ietf@ietf.org>; Tue, 11 Nov 2008 06:39:13 -0800 (PST)
Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1KzuOK-0007iX-Qo; Tue, 11 Nov 2008 09:38:53 -0500
Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from <tytso@mit.edu>) id 1KzuOH-0003y3-Qn; Tue, 11 Nov 2008 09:38:49 -0500
Date: Tue, 11 Nov 2008 09:38:49 -0500
From: Theodore Tso <tytso@mit.edu>
To: Steve Linford <linford@spamhaus.org>
Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Message-ID: <20081111143849.GA13960@mit.edu>
References: <A.1KzaJs-0008yI-GB@smtp-ext-layer.spamhaus.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A.1KzaJs-0008yI-GB@smtp-ext-layer.spamhaus.org>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@mit.edu
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
Cc: ietf@ietf.org
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

On Mon, Nov 10, 2008 at 05:12:56PM +0000, Steve Linford wrote:
> I certainly agree that there are hundreds of small DNSBLs run from kid's 
> bedrooms which list on incomprehensible wildly over-broad policies and 
> that such DNSBLs are both antagonistic and useless and as a result are 
> used by almost nobody - that's 'market force'. But to pretend that the 
> dozen major DNSBLs make listings based on "unauthenticated rumor" or 
> "because the IP did not have 'mail.' or 'mx.'" is just silly mud-slinging 
> itself based on equally "unauthenticated rumor" and is especially odd if 
> it's coming from within IETF itself.

Let me get this straight.  It's OK to block e-mail messages on the
basis of unauthenticated rumors, but now you are complaining that it's
somehow dirty pool to block a standard based on the same thing?  After
all, it's the same argument; there's a lot of evil e-mail messages out
there; the cost of letting even one of those messages through is
unacceptable, so false positives are OK.  Similarly, there are a lot
of bad ideas out there, many of which have folks clamoring to have
them be standardized, just as spammers hope to get people to visit
their spamvertised web sites.  And in both cases, it's "just
business"....

I have no problem with the IETF documenting the world as it exists.
That's what an informational track RFC does.  There's a process by
which a specification gets annointed to become a standard, and others
more eloquent than I have already pointed out the dangers of trying to
skip steps in the standardization process.

Questions like, "so how does this work in the face of the expanded
IPv6 address space", ideally should be addressed earlier during the
standardization process, and not in last call (where, "oh well, we'll
just block the whole /48 or /32" might have unfortunate side effects
not forseen yet) --- but which don't make sense if the goal is to
document existing practice.

> The fact some DNSBLs are in widespread use (I can speak only for  
> Spamhaus, our DNSBLs are today used by something in the region of 2/3 of 
> internet networks) is good reason why it's important to publish a  
> standard and format for the technology.

There's a big difference between "use" and "Use".  If a spamassassin
configuration (by default) uses a DNSBL to add a point or a fraction
of a point to a spam score, where it might take a spam score of 10-15
before spam is dropped, that's a very different usage model than
someone who, on the unsubstatiated word of SORBS or APEWS, drops the
e-mail on the floor where it is never seen again.

And for those who would argue that it's not their problem how the
DNSBL is used, since after all that's the responsibility of the folks
using the DNSBL, I'm reminded of the line from the Tom Lehrer song:

	"Vonce the rockets go up, 
	 who cares vhere
	 they come down?
	 It's not my department,
	 says Verner von Brown."


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