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
- Re: several messages der Mouse
- Re: several messages David Morris
- Re: several messages Dean Anderson
- Re: several messages Randy Presuhn
- Re: several messages David Morris
- Re: several messages Matthias Leisi
- Re: several messages Steve Linford
- Re: several messages Peter Dambier
- Re: several messages Steve Linford
- Re: several messages Keith Moore
- Re: several messages der Mouse
- Re: several messages Chris Lewis
- Re: several messages Mark Andrews
- Re: several messages der Mouse
- Re: several messages Chris Lewis
- Re: several messages David Romerstein
- Re: several messages Randy Presuhn
- Re: several messages Chris Lewis
- Re: several messages David Romerstein
- Re: several messages David Romerstein
- Re: several messages Keith Moore
- Re: several messages Chris Lewis
- Re: several messages Al Iverson
- More anti-spam (was: Re: several messages) John C Klensin
- RE: several messages michael.dillon
- Re: several messages Matthias Leisi
- Re: several messages Mark Andrews
- Re: several messages David Morris
- Re: several messages Al Iverson
- Re: uncooperative DNSBLs, was several messages John Levine
- Re: uncooperative DNSBLs, was several messages Jim Hill
- Re: several messages John C Klensin
- Re: several messages Al Iverson
- RE: several messages Hallam-Baker, Phillip
- Re: uncooperative DNSBLs, was several messages Matthias Leisi
- Re: uncooperative DNSBLs, was several messages Al Iverson
- RE: several messages Anthony Purcell
- Re: uncooperative DNSBLs, was several messages Dave CROCKER
- Re: several messages der Mouse
- Re: uncooperative DNSBLs, was several messages Andrew Sullivan
- Re: uncooperative DNSBLs, was several messages David Romerstein
- Re: uncooperative DNSBLs, was several messages Jim Hill
- Re: several messages Chris Lewis
- Re: uncooperative DNSBLs, was several messages Chris Lewis
- Re: uncooperative DNSBLs, was several messages John C Klensin
- Re: uncooperative DNSBLs, was several messages Dave CROCKER
- Re: uncooperative DNSBLs, was several messages Tony Finch
- Re: uncooperative DNSBLs, was several messages Andrew Sullivan
- Re: uncooperative DNSBLs, was several messages John C Klensin
- Re: uncooperative DNSBLs, was several messages Matthias Leisi
- Re: uncooperative DNSBLs, was several messages Al Iverson
- Re: uncooperative DNSBLs, was several messages Andrew Sullivan
- Re: uncooperative DNSBLs, was several messages John C Klensin
- Re: uncooperative DNSBLs, was several messages Ted Hardie
- Re: uncooperative DNSBLs, was several messages Matthias Leisi
- Re: uncooperative DNSBLs, was several messages Ted Hardie
- Re: uncooperative DNSBLs, was several messages Tony Finch
- Context specific semantics was Re: uncooperative … Ted Hardie
- Clarifying harm to DNS (was: uncooperative DNSBLs… Andrew Sullivan
- Re: Context specific semantics was Re: uncooperat… Ted Hardie
- Re: uncooperative DNSBLs, IETF misinformation (wa… Steve Linford
- RE: Context specific semantics was Re: uncooperat… Hallam-Baker, Phillip
- Re: uncooperative DNSBLs, was several messages Peter Dambier
- Re: uncooperative DNSBLs, was several messages David Romerstein
- Re: uncooperative DNSBLs, was several messages Peter Dambier
- Re: uncooperative DNSBLs, was several messages Keith Moore
- Re: uncooperative DNSBLs, was several messages Chris Lewis
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: uncooperative DNSBLs, IETF misinformation (wa… Steve Linford
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: Context specific semantics was Re: uncooperat… Tony Finch
- Re: Context specific semantics was Re: uncooperat… John Levine
- RE: Context specific semantics was Re: uncooperat… Hardie, Ted
- RE: Context specific semantics was Re: uncooperat… Tony Finch
- Re: several messages Rich Kulawiec
- Re: uncooperative DNSBLs, was several messages Rich Kulawiec
- Re: uncooperative DNSBLs, IETF misinformation (wa… Al Iverson
- Re: Context specific semantics was Re: uncooperat… Ted Hardie
- RE: Context specific semantics was Re: uncooperat… Ted Hardie
- Re: several messages John C Klensin
- Re: several messages Al Iverson
- Re: Context specific semantics was Re: uncooperat… John L
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: uncooperative DNSBLs, IETF misinformation (wa… Al Iverson
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: several messages John C Klensin
- Re: several messages Chris Lewis
- Re: uncooperative DNSBLs, IETF misinformation (wa… Keith Moore
- Re: several messages Al Iverson
- RE: several messages michael.dillon
- Re: uncooperative DNSBLs, IETF misinformation (wa… Al Iverson
- Re: Context specific semantics was Re: uncooperat… Ted Hardie
- Re: Context specific semantics was Re: uncooperat… Douglas Otis
- Re: uncooperative DNSBLs, IETF misinformation (wa… Theodore Tso
- Re: Context specific semantics was Re: uncooperat… Theodore Tso
- Re: uncooperative DNSBLs, IETF misinformation (wa… Chris Lewis
- Re: more bad ideas, was uncooperative DNSBLs, was… John Levine
- Re: more bad ideas, was uncooperative DNSBLs, was… Chris Lewis
- Re: Context specific semantics was Re: uncooperat… John L
- Detecting and disabling bad DNSBLs Peter Dambier
- Re: Detecting and disabling bad DNSBLs Steve Linford
- Re: several messages Pekka Savola
- Re: more bad ideas, was uncooperative DNSBLs, was… Keith Moore
- Re: several messages Rich Kulawiec
- Is USA qualified for 2.3 of draft-palet-ietf-meet… YAO
- RE: [73attendees] Is USA qualified for 2.3 ofdraf… Song Haibin
- Re: several messages Tom.Petch
- Re: [73attendees] Is USA qualified for 2.3 of dra… Phillip Hallam-Baker
- Re: [73attendees] Is USA qualified for 2.3 of dra… james woodyatt
- Re: several messages John C Klensin