Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Keith Moore <moore@network-heretics.com> Sat, 08 November 2008 19:38 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 6E6463A689B; Sat, 8 Nov 2008 11:38:09 -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 6CCAC3A689B for <ietf@core3.amsl.com>; Sat, 8 Nov 2008 11:38:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level:
X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, 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 AQaDphd1ZjJT for <ietf@core3.amsl.com>; Sat, 8 Nov 2008 11:38:07 -0800 (PST)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 604EF3A67D0 for <ietf@ietf.org>; Sat, 8 Nov 2008 11:38:07 -0800 (PST)
Received: from lust.indecency.org (adsl-155-115-114.tys.bellsouth.net [72.155.115.114]) by m1.imap-partners.net (MOS 3.10.3-GA) with ESMTP id BED16610 (AUTH admin@network-heretics.com) for ietf@ietf.org; Sat, 8 Nov 2008 11:37:58 -0800 (PST)
Message-ID: <4915EA94.6020706@network-heretics.com>
Date: Sat, 08 Nov 2008 14:37:56 -0500
From: Keith Moore <moore@network-heretics.com>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Chris Lewis <clewis@nortel.com>
Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
References: <4915DE02.2010803@nortel.com>
In-Reply-To: <4915DE02.2010803@nortel.com>
Cc: john-ietf@jck.com, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>, 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
I think you're missing the point. Better "interoperation" of a facility that degrades the reliability of email, by encouraging an increased reliance on dubious filtering criteria and rumors, is not a desirable goal. Even assuming that there's some benefit in having third-party reputation services (which IMHO is not well-established), use of DNS to communicate such reputation, and basing such reputation on IP addresses, is itself very dubious. The problem isn't just the rumor passing mechanism, but the mechanism is indeed part of the problem. It's not as if we're arguing about whether to standardize a facility that is widely believed to work well. We're arguing about whether to standardize a facility that causes problems for everyone. Back when I started working with email, getting a message reliably delivered was something of a black art, because you had to know how to thread your message through the hodgepodge of Internet, uucp, BITNET, DECnet, fidonet, and whatnot. That was in some sense understandable because Internet access was not widely available, and there wasn't really any common network that everybody could tap into. Today, getting a message reliably delivered is once again a black art. But today, it's not for lack of standards or network connectivity. It's because so many messages are filtered for dubious reasons, or on the basis of what are essentially unsubstantiated rumors, or because of over-reliance on IP source addresses as identifiers. Keith Chris Lewis wrote: > As the architect of a large email infrastructure, a senior technical > advisor to the Mail Anti-Abuse Working Group, and ASRG member, I find > myself disagreeing with the points made by John and Keith that I > included at the end. > > As a consumer (and producer) of DNSBLs, I need technical standards that > define DNSBL protocol so I can spec/build/acquire/use software that > interoperates correctly and maintains/improves the reliability of our > email and email in general. > > I also want policy predictability in the DNSBLs I use or am likely to > encounter when our users send email, but that does not belong in a DNSBL > technical standard on protocols. It belongs in a different document. > More below. > > Yes, the very existence of DNSBLs is unfortunate, but they have become > an outright necessity for many mail systems. Our (and many other, > including all of very largest) mail infrastructures heavily rely on > DNSBLs for the majority of their filtering. No other filtering > technique deals as effectively with the massive floods of spam and other > malicious content that we receive (in some cases well in excess of 90% > of all email). > > Yes, some people honestly believe that the use of DNSBLs for blocking is > a bad idea. But those objections fall away when they're used in > aggregate scoring systems like SpamAssassin, where they're just one > minor factor of many. DNSBLs need to be standardized, whether they > block an email, tweak a score a bit like SpamAssassin, or as in some > environments, improve an email's likelihood of getting through (eg: > whitelists). > > There are many advanced non-DNSBL techniques that can and do work well > in place of DNSBLs on small to medium systems. Unfortunately, they are > either considerably less ineffective or are impractical in large to very > large systems trying to withstand the full spectrum of email abuse that > they have to deal with daily. DNSBLs (locally sourced or otherwise) > often make the difference between email remaining useable or becoming > unuseable in environments like ours. > > It is but one tool of many tools. Yet, for many infrastructures, by far > the most effective. Virtually every major email system uses DNSBLs in > one way or another, whether it's visible or not, whether it's used > directly by themselves, or in concert with other mechanisms (eg: scoring). > > Failing to standardize the technical protocols used by them would be a > major mistake. > > More specific points: > > 1) There are no technical omissions in the specification that I am aware > of. It is a technical specification of the bits on the wire (the > protocol), with little else. > > 2) I presume the "technical omissions" comment was intended to mean a > lack of standardization of "how things got on and off DNSBLs". These > are not, and should not, be considered technical issues. Specifying how > something got on and off a DNSBL would be equivalent to insisting that > RFC2822 attempt to standardize how mail readers insert an email address > in the To header. RFC2822 specifies the format of To headers, not how > they got there. > > Yes, there are issues about such things, and consistency in some of > these areas is desired. But, they do not belong in a technical > standard. This is why I, Matt Sergeant, and others have been working on > a DNSBL policy BCP what could be considered a companion document: > http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-04.txt > > I hope to make a few final grammatical changes to the above document in > the next few days and move it on towards last call. > > 3) Making draft-irtf-asrg-dnsbl a standard (and ultimately approving the > BCP) serves to improve the consistency and interoperability of DNSBLs, > and therefore email itself. Not making it a standard only perpetuates > uncertainty on the protocol itself, failure to implement software that > interoperates correctly, unpredictable (and some times capricious) > failure modes, and ultimately impairs the reliability of email. > > Case in point: If a DNSBL domain becomes unregistered, and is picked up > by a reseller, they usually insert DNS A record wildcards causing web > queries to go to a common web page. Or if a DNSBL domain is mispelled > by its users, it may collide with a different domain that wildcards A > records. Such scenarios aren't rare, they happen frequently. Without > this standardization, the implementors of DNSBL clients don't realize > that DNSBL queries that return A records outside of 127/8 is an error > condition not a positive result. Such mail servers usually end up > blocking ALL of their email - concrete examples of where lack of > standardization drastically impairs email interoperability. > > John C Klensin wrote: > >> Sadly, I have to agree with Keith. While these lists are a >> fact of life today, and I would favor an informational document >> or document that simply describes how they work and the issues >> they raise, standardizing them and formally recommending their >> use is not desirable at least without some major changes in our >> email model and standards for what gets addresses onto --and, >> more important, off of-- those lists. >> >> john >> >> >> --On Friday, 07 November, 2008 18:38 -0500 Keith Moore >> <moore@network-heretics.com> wrote: >> >>> DNSBLs work to degrade the interoperability of email, to make >>> its delivery less reliable and system less accountable for >>> failures. They do NOT meet the "no known technical omissions" >>> criterion required of standards-track documents. >>> >>> The fact that they are widely used is sad, not a justification >>> for standardization. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Stephane Bortzmeyer
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John Levine
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Stephane Bortzmeyer
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John L
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Dave CROCKER
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Sam Hartman
- The purpose of a Last Call Dave CROCKER
- RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Livingood, Jason
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Doug Otis
- Re: The purpose of a Last Call Pete Resnick
- Re: The purpose of a Last Call Sam Hartman
- Re: The purpose of a Last Call Leslie Daigle
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John C Klensin
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… ned+ietf
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Dave CROCKER
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Eric Rescorla
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Dave CROCKER
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John Levine
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Steven M. Bellovin
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Eric Rescorla
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John C Klensin
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John C Klensin
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Chris Lewis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John Levine
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Paul Hoffman
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Doug Ewell
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Chris Lewis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Chris Lewis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Chris Lewis
- draft-irtf-asrg-bcp-blacklists John Leslie
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Theodore Tso
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John Levine
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: draft-irtf-asrg-bcp-blacklists SM
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Theodore Tso
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John Levine
- Re: draft-irtf-asrg-bcp-blacklists John Levine
- Re: draft-irtf-asrg-bcp-blacklists Chris Lewis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… David Conrad
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John C Klensin
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John C Klensin
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John C Klensin
- RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Livingood, Jason
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John Levine
- RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Livingood, Jason
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Chris Lewis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Chris Lewis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Matthias Leisi
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… michael.dillon
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Tony Hansen
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Steven M. Bellovin
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Chris Lewis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Matthias Leisi
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John Levine
- RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Livingood, Jason
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Dave CROCKER
- RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Steve Linford
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Tony Finch
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… der Mouse
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Tony Finch
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Tony Finch
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Tony Finch
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Tim Chown
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Theodore Tso
- RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… michael.dillon
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Steve Linford
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Lisa Dusseault
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Joe St Sauver
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Jamie Tomasello
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Tony Finch
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… der Mouse
- Re: draft-irtf-asrg-bcp-blacklists Rich Kulawiec
- IPv6 traffic stats (was: Re: Last Call: draft-irt… David Kessens
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Chris Lewis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Keith Moore
- Re: IPv6 traffic stats Harald Alvestrand
- Re: IPv6 traffic stats Turchanyi Geza
- Re: IPv6 traffic stats Harald Alvestrand
- Re: IPv6 traffic stats Marc Manthey
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… SM
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Andrew Sullivan
- Re: IPv6 traffic stats Pekka Savola
- Re: IPv6 traffic stats Harald Alvestrand
- RE: IPv6 traffic stats Hallam-Baker, Phillip
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Tony Finch
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Andrew Sullivan
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Tony Finch
- Re: IPv6 traffic stats Geoff Huston
- Re: IPv6 traffic stats Peter Sherbin
- Re: IPv6 traffic stats Pekka Savola
- Re: IPv6 traffic stats (was: Re: Last Call: draft… Danny McPherson
- Re: IPv6 traffic stats Danny McPherson
- Re: IPv6 traffic stats Iljitsch van Beijnum
- Re: IPv6 traffic stats Iljitsch van Beijnum
- Re: IPv6 traffic stats (was: Re: Last Call: draft… David Kessens
- RE: IPv6 traffic stats TJ
- Re: IPv6 traffic stats (was: Re: Last Call: draft… Danny McPherson
- Re: IPv6 traffic stats (was: Re: Last Call: draft… David Kessens
- Re: IPv6 traffic stats (was: Re: Last Call: draft… Olivier MJ Crepin-Leblond
- Re: IPv6 traffic stats - limitations of 6to4 Pekka Savola
- Re: IPv6 traffic stats Pekka Savola
- Re: IPv6 traffic stats - limitations of 6to4 Rémi Després
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Doug Otis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Chris Lewis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Florian Weimer
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Florian Weimer
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Mark Andrews
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Florian Weimer
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Chris Lewis
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Florian Weimer
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… John Levine
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Florian Weimer
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Mark Andrews
- Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blackli… Mark Andrews
- Re: Last Call: draft-irtf-asrg-blinds (DNS Blackl… Chris Lewis