Re: several messages
"Chris Lewis" <clewis@nortel.com> Wed, 12 November 2008 17:12 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 A11D928B56A; Wed, 12 Nov 2008 09:12:08 -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 0C1723A67FA for <ietf@core3.amsl.com>; Wed, 12 Nov 2008 09:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 7Cipu+Dbps7q for <ietf@core3.amsl.com>; Wed, 12 Nov 2008 09:12:06 -0800 (PST)
Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 76C643A67D6 for <ietf@ietf.org>; Wed, 12 Nov 2008 09:12:06 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mACHC4V09849 for <ietf@ietf.org>; Wed, 12 Nov 2008 17:12:04 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 12:12:04 -0500
Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 12 Nov 2008 12:12:03 -0500
Message-ID: <491B0E5D.3030308@nortel.com>
Date: Wed, 12 Nov 2008 12:11:57 -0500
From: Chris Lewis <clewis@nortel.com>
Organization: Nortel
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: several messages
References: <Pine.LNX.4.44.0811111805020.4831-100000@citation2.av8.net>
In-Reply-To: <Pine.LNX.4.44.0811111805020.4831-100000@citation2.av8.net>
X-OriginalArrivalTime: 12 Nov 2008 17:12:04.0115 (UTC) FILETIME=[C8A5D630:01C944E9]
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
<redundant CC list snipped> I wouldn't ordinarily reply to this, but Dean makes a number of plausible pronouncements which simply aren't borne out in reality. I'm using this as an educational opportunity for those with insufficient experience in the field to make an informed judgement. Dean Anderson wrote: > I suggest people look at this document: > > http://tools.ietf.org/html/draft-church-dnsbl-harmful-01 That expired over two years ago, and rightfully so. It's filled with a great number of inaccuracies, including statistics that don't even remotely resemble effectiveness and false positive rates as seen by sites with typical mail flows. Not to mention assertions that are entirely at odds with virtually all operators of medium to very large environments. For example, the statistics of "BL3" (CBL) showing an effectiveness rate of 45% and a FP rate (against desired email) of over 2% in a very small sample set. If the CBL FP rate was even as high as .01%, we'd not touch it. Our email flow in production does as many emails as his entire test every few minutes, and the traps are peaking to that many emails per second. [I'm picking on the CBL because I've studied it for a long time. I'm studying it because it's doing an amazingly good job on our mail flow, and our experiences with it seem to be closely reflected by most other sites, including some of the very largest email infrastructures that exist.] Our effectiveness rate at catching _all_ spam exceeds 75% from the CBL alone, with a false positive rate in the 5-6 per million range. On the trap, it's above 90%. That is one of the lowest FP rates of any of the techniques (DNSBL or otherwise) in our arsenal, and is far away the highest effectiveness rate. The non-DNSBL heuristics tend to have worse FPs. In our production environment (300,000 valid emails per day), we have perhaps one false positive due to the CBL per day, and in virtually all cases the CBL is correct - we can see the spewage of spam and viruses from that IP in our own quarantine, it just happens to have one or two valid emails mixed in too. Which we fix (assist with eradicating the infection problem, and forward the intercepted valid email) and move on - no harm (no lost email, at worst delayed), and only good (fixed infection, less junk) accrues from our blocks. > Maybe you should do some math to show the response time of a DNSBL > compared to the re-ip time. Maybe I could, but I don't need to, because over the past 5 years our experience with the CBL (as just one example) indicates that any potential for very short re-ip times versus detection->publication time isn't a significant factor nor is likely to be anytime soon, hence the calculations are moot. >> Many ISPs force DHCP IP-affinity significantly, and it's kinda hard >> for most BOTs to force their cable modem/access router/whatever (which >> is the real holder of the DHCP address) to refresh. > > First, > > Second, > > Third, Our experience indicates that none of them are a significant factor in CBL effectiveness over the past 5 years, and there's no indication that they will become much more significant any time soon. > I'm sure some IPs do stay static for much longer, particularly when the > machine infected has a static ip address in a hosting facility. > > But your premise is limited to residential carriers offering cable or > dsl. What goes against your premise is the efforts by residential > carriers to disrupt server activities by keeping customers from having a > static ip address. Rotating the address faster natually disrupts P2P > services like bit-torrent, etc. So, I'm kind of puzzled that you don't > see this. Actually, that won't disrupt them, unless the forced re-ip rate is sufficiently high to interfere with "normal" desired traffic (like web surfing or email). Most of such tools (like bit-torrent) are inherently immune to re-ip'ing, except insofar as a re-ip might break a transfer mid-stream. Which breaks email and web transfers too, and an ISP's customers would get pretty mad about that. Re-ip'ing would only be a real barrier to those protocols that rely on being able to "call into a reasonably fixed IP" of, say, a torrent leaf node instead of "call out to an advertised muster point". We have 100% inbound blocking of all connection attempts on all protocols. Yet, bit-torrent works here. In other words, re-ip wouldn't stop torrent except by breaking connections mid-stream, which causes destructive interference to the very activity the ISP is contracted to supply to their customers. Residential carriers have a strong incentive to keep the same device on the same IP as long as possible, even across reboots/reconnects - allowing BOTs to re-ip very quickly lands their entire pool in DNSBLs like the CBL at best (worse is local mail admin-applied manual whole-range listings that probably never get reviewed), and worse greatly complicates analysis and remediation. In other words, how do you correlate an IP that's changing every few minutes against an external report with a timestamp of unknown accuracy (if there's a useable timestamp at all)? You can "see" a few places where rapid re-ip is likely being used (eg: /24s with CBL detection densities exceeding 50% and sometimes hitting 100%), but they're all listed, no spam is getting through, and there's no legitimate email observable in the stream in any case, because the valid email is going by an ISP-provided relay. The CBL benefits from a very important fact: virtually all IPs it detects were never intended or used to send email directly to the destination in the first place. The holders of those IPs send their valid email through ISP-provided relays. Those who get listed generally don't notice they're listed, because it doesn't affect them at all. > What is this magic that detects the bot type from the contents of an > email message? A broken header perhaps? What do you do if the bot > doesn't send any obvious identifying information in its messages? Other mechanisms, especially the CBL, tend to catch those. _All_ usefully effective anti-spam implementations use multiple techniques. They have to, because no technique is sufficiently effective on its own to get to the effectiveness levels our users/customers demand. > In > general, one has to depend on spam-traps, then updating DNS zones, and > then distributing that information, waiting for ttls to expire on > previous queries. Even if you pick up on a broken header or some such, > it still takes time to distribute the updates. It does all that. But as I have demonstrated, the bad email that gets through because of this delay is a very small percentage (typically a few percent) of what was correctly caught by the DNSBL. > Efforts at text matching are easilly foiled. Who said anything about text matching? For the most part the detection heuristics stay static for far longer than is necessary to achieve reasonable effectiveness. If, say, the CBL misses about an hour's worth of a BOT's first emissions from an infected IP (that seems about right in terms of latencies), it's not missing the next few days that most BOTs appear to emit at a minimum. The realtime heuristics themselves generally stay stable for months at a time. > But unavoidably, spam from bots should go on for > quite a while before the DNSBL system can react. Sometime after the > system reacts, Bot spam should be stopped for a short time, until IP > addresses change, and then resume, repeating the cycle. And the number > of bots generally grows, meaning there is an exponential factor that > works against your effectiveness at blocking. Our experience is entirely counter to that theory, and there's no indication the situation is going to change any time soon. Furthermore, there are DNSBLs that make that theory, even _if_ it was borne out by any level of empirical proof, entirely irrelevant. The PBL is not a reactive DNSBL, and is just about as effective as the CBL on much the same things as the CBL is. I have seen less than 5 false positives in total since the day the PBL was first published (and that's against 300,000 emails per day). And those, as are the CBL's, easily self-remedied. The PBL isn't a replacement for the CBL nor vice-versa. There's some that one catches that the other doesn't, and vice-versa. The CBL even publishes some metrics about that. > Still, all-in-all, 70% > sounds much more reasonable than the 99% others sometimes state. You misunderstand the statistic I think. That 70% is the percentage of CBL hits where our detectors can uniquely identify the specific BOT at fault. CBL's heuristics and cross-section are obviously broader than ours - eg: the remaining 30%. That is only a poor indication of how much of the total of spam is BOTs - probably above 70%, but that's as far as that goes. But, I'll agree, 99% is too high for that number. The real number is likely at the upper end of 80-95%. > But as > DCHP lease times go down, so will your percentage. It will ultimately > reach very low numbers; its just a matter of time. So we've gone from "are very low numbers" (which I've demonstrated they aren't) to "ultimately reach low numbers". What next? The CBL's effectiveness and accuracy has been increasing over the 5 years it's been in operation, not declining. There is no empirical indication that this is changing while exploited machines (including BOTs) remain a significant factor in spam. There are other more likely scenarios than "re-ip" where CBL-like DNSBLs might start losing effectiveness as they are used today. Some that have been seen in the wild over the past year or two. But they as yet aren't a significant percentage either. > Those who are still > blocking a high percentage effectiveness have to know the bots in > advance. Which is why people tend to use the PBL too. _______________________________________________ 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