RE: uncooperative DNSBLs, IETF misinformation (was: several messages)
<michael.dillon@bt.com> Fri, 14 November 2008 08:19 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 5D11A3A6A4B; Fri, 14 Nov 2008 00:19:17 -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 392113A6A4B for <ietf@core3.amsl.com>; Fri, 14 Nov 2008 00:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.466
X-Spam-Level:
X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 kQI031X58Ir0 for <ietf@core3.amsl.com>; Fri, 14 Nov 2008 00:19:14 -0800 (PST)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 783A93A6A40 for <ietf@ietf.org>; Fri, 14 Nov 2008 00:19:14 -0800 (PST)
Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Nov 2008 08:19:11 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: uncooperative DNSBLs, IETF misinformation (was: several messages)
Date: Fri, 14 Nov 2008 08:19:04 -0000
Message-ID: <C0F2465B4F386241A58321C884AC7ECC09597929@E03MVZ2-UKDY.domain1.systemhost.net>
In-Reply-To: <A.1L0jlO-000MSh-Ku@smtp-ext-layer.spamhaus.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: uncooperative DNSBLs, IETF misinformation (was: several messages)
Thread-Index: AclF1zCF+UhM+9g1RwqLcpnTOLw5DwAV9jSg
From: michael.dillon@bt.com
To: ietf@ietf.org
X-OriginalArrivalTime: 14 Nov 2008 08:19:11.0438 (UTC) FILETIME=[AC45FEE0:01C94631]
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
> - DNSBLs are temporary fad, they'll never last. > (we've been serving DNSBLs for 10 years) Longevity is no guarantee of future survival. > - DNSBLs are bad for email. > (we alone flag some 80 billion spam emails *per day*, spam which > would otherwise clog servers and render email completely useless) Interesting point. If you did not run those DNSBLs then the flood of spam would have rendered email completely useless which would have reduced the sell-rate from one in 12.5 million, to zero. At which point there is no financial incentive for spam. Or, more likely, spam would have been maintained at a much lower level to maximize their profit. > - DNSBLs have huge False Positives. > (at 80 billion spams stopped per day, if we had even a miniscule > FP level there would be a worldwide outcry and everyone would stop > using us. Do the maths. Our FP level is many times lower than any > other spam filter method by a very, very long way) Hmmm. No data provided, so no maths is possible. Note that a huge FP rate does not imply a huge quantity of false positives, if you allow for an importance factor. > - DNSBLs break email deliverability. > (DNSBL technology in fact ensures that the email sender is notified > if an email is rejected, unlike Bayesian filters/content filters > which place spam in the user's trash without notifying the senders) This still breaks deliverability. > - DNSBLs "sit in the middle of an end-to-end email transaction" > (see: http://www.spamhaus.org/dnsbl_function.html for > enlightenment) There is a diagram under Rights of a Sender vs Rights of a Receiver which shows that the DNSBL modifies the behavior of the Receiving mail server. This is what I mean by "sitting in the middle of an end-to-end (sender to recipient) email transaction. > - Someone from BT said "DNSBLs should not be standardised" > (BT has a contract with Spamhaus to use our DNSBLs on its network, > we're not sure why BT would prefer the DNSBLs it uses to not be > standardised but we'll ask them at contract renewal time ;) This is the IETF. Nobody here speaks for any company or any other organisation. Many people have stated that THIS DRAFT should not be accepted as a STANDARDS TRACK RFC because it does not meet the IETF requirements for an IETF STANDARD. That is very different from saying that DNSBLs should not be standardised. > - DNSBLs are all bad because someone had a bad experience with SORBS. > (well, we're not SORBS. Nor are Trend Micro, Ironport, or the other > responsible DNSBL operators) DNSBLs are risky because of the many cases put forward here. This implies that there are security considerations that should be discussed in the RFC, but which the authors neglected to mention. > DNSBLs using 127.0.0.2 cause absolutely no 'damage' whatsoever) You must not have read the draft. People are concerned with stuff like this from section 2.3: To minimize the number of DNS lookups, multiple sublists can also be encoded as bit masks or multiple A records. With bit masks, the A record entry for each IP is the logical OR of the bit masks for all of the lists on which the IP appears. For example, the bit masks for the two sublists might be 127.0.0.2 and 127.0.0.4, in which case an entry for an IP on both lists would be 127.0.0.6: In any case, your diatribe will not change the fact that this draft will not be standardised. In order to become a standard, a draft has to have consensus, and you can't build consensus by misstating the arguments against standardisation, and then saying that it is all farcical. --Michael Dillon _______________________________________________ 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