Re: uncooperative DNSBLs, IETF misinformation (was: several messages)

Theodore Tso <tytso@mit.edu> Sat, 15 November 2008 00:04 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 2B30B3A6A74; Fri, 14 Nov 2008 16:04:28 -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 D643C3A6A74 for <ietf@core3.amsl.com>; Fri, 14 Nov 2008 16:04:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.784
X-Spam-Level:
X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=1.481, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 4HoYCBxmNhpX for <ietf@core3.amsl.com>; Fri, 14 Nov 2008 16:04:26 -0800 (PST)
Received: from thunker.thunk.org (www.church-of-our-saviour.org [69.25.196.31]) by core3.amsl.com (Postfix) with ESMTP id 13B523A67E1 for <ietf@ietf.org>; Fri, 14 Nov 2008 16:04:25 -0800 (PST)
Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1L18eG-0003cV-K4; Fri, 14 Nov 2008 19:04:24 -0500
Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from <tytso@mit.edu>) id 1L18eE-0008VT-9z; Fri, 14 Nov 2008 19:04:22 -0500
Date: Fri, 14 Nov 2008 19:04:22 -0500
From: Theodore Tso <tytso@mit.edu>
To: Al Iverson <aiverson@spamresource.com>
Subject: Re: uncooperative DNSBLs, IETF misinformation (was: several messages)
Message-ID: <20081115000422.GL25117@mit.edu>
References: <e0c581530811140931t23f85aa9w9629a8aa2bc9f26@mail.gmail.com> <C0F2465B4F386241A58321C884AC7ECC0961B8DB@E03MVZ2-UKDY.domain1.systemhost.net> <e0c581530811141103y1b831a2ag396bd06823db08cf@mail.gmail.com> <491DD91A.5090507@network-heretics.com> <e0c581530811141308g4eba52fj2cab489787fa0f85@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e0c581530811141308g4eba52fj2cab489787fa0f85@mail.gmail.com>
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 Fri, Nov 14, 2008 at 04:08:50PM -0500, Al Iverson wrote:
> >> Is this unique to DNSBLs? If not, then why does it merit deeper
> >> consideration in the context of DNSBLs?
> >
> > what you are arguing is that rather than trying to address the harm done
> > by DNSBLs, IETF should ignore that harm by ruling it out of scope for
> > the current discussion.
> 
> I suggested no such thing. I asked for the opposite -- help somebody
> who doesn't get it understand exactly what the connection is.

I think the issue of the badly-run DNSBL's can be handled handled by
amplifying the first paragraph of the Security Considerations section.
Currently, it merely talks about the most blantent problems caused by
a DNSBL causing all mail to be rejected, or no mail to be rejected.
It doesn't talk about DNSBL's using different criteria than what they
have advertised for their list, or that a potential DNSBL could use
the trust given to mail receivers to explicitly block an IP block in
retaliation for criticism or to pursue some other vendetta.
Mentioning that these things can and have happened I think is simply
acknowledging the obvious, and that a poorly chosen DNSBL can cause
great harm.

I would also encourage the "how to run a DNSBL responsibly" to be
published at the same time, so that draft-irtf-asrg-dnsbl could
reference the "this is how you do it right" (while acknowledging the
only out of band mechanisms can be used to ensure that a DNSBL
operator is truly following the criteria they claim to be using).

This of course ignores the question of whether a document which is
intended for the Standards Track should be abusing DNS 'A' records or
not.  It may be that a much better approach is to put this on
Informational describing the current state of affirs, warts and all,
and then to create a better document which is Standards Track later
on.

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