Re: [Asrg] Summary/outline of why the junk button idea is pre-failed
"Chris Lewis" <clewis@nortel.com> Tue, 02 March 2010 16:42 UTC
Return-Path: <CLEWIS@nortel.com>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9077628C1A2 for <asrg@core3.amsl.com>; Tue, 2 Mar 2010 08:42:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.443
X-Spam-Level:
X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
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 liAYeO2qEXq9 for <asrg@core3.amsl.com>; Tue, 2 Mar 2010 08:42:15 -0800 (PST)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 393683A8B4B for <asrg@irtf.org>; Tue, 2 Mar 2010 08:42:15 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o22GgB220187 for <asrg@irtf.org>; Tue, 2 Mar 2010 16:42:12 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 11:41:56 -0500
Received: from [47.130.64.139] (47.130.64.139) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 2 Mar 2010 11:41:56 -0500
Message-ID: <4B8D3FD1.8090403@nortel.com>
Date: Tue, 02 Mar 2010 11:41:53 -0500
From: Chris Lewis <clewis@nortel.com>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: asrg@irtf.org
References: <20100302131810.GA22938@gsp.org>
In-Reply-To: <20100302131810.GA22938@gsp.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Mar 2010 16:41:56.0723 (UTC) FILETIME=[4592F430:01CABA27]
Subject: Re: [Asrg] Summary/outline of why the junk button idea is pre-failed
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2010 16:42:16 -0000
On 3/2/2010 8:18 AM, Rich Kulawiec wrote: I'm going to try to keep this brief, and at the same time avoid nitpickery. I've put a point-by-point non-nitpickery response after "----", but, you can avoid reading that entirely and stick directly to: It's not as if the industry doesn't lack ample experience with TiS buttons. If TiS is as bad as you say, would anybody that matters still be using it? Verizon abandoned SAV. Did AOL, Gmail, MSN, Yahoo abandon TiS? Nope. I'm going to take a huge leap in suggesting that those guys are pretty smart, and if they still like them after a few bazillion man-years accumulated experience, they're probably right, and it is useful. Especially when it agrees with my experience ;-) You can stop reading now if you wish. ------------------------------------------------------------ > 1. User incompetence > > Users have spent the last quarter-century conclusively proving > that they cannot reliably discern spam from non-spam. This flies directly opposite to my experience, and the experience of vastly larger environments than you or I. They must know something, doncha think? Certainly there are, er, lots of stupidities, but statistically, they still are a small fraction, and using statistical methods they can be ignored. > 2. User time > Based on both these incredibly over-optimistic assumptions, we can > then calculate how much end-user time will be spent performing > this classification task and hitting the button. You're assuming that this "classification task" is something that the end-user isn't doing already. They already are. At worst, we're adding a button press. This argument is only relevant if the TiS button is to be used _instead_ of filtering/if the TiS button isn't allowed to affect filtering in any way. Nothing could be further from the truth. It is an adjunct to filtering, where the time is only spent on the email the filters _missed_, with a goal of _both_ refining the filters yet further (to reduce the miss rate) as well as pushing the spam fight back to the originators (to stop the spam being sent at all). Both are necessary, and both will _reduce_ the total amount of end-user time spent. > 3. User exposure > It is certain that in the process of trying to perform classification > tasks, they'll click on links "just to see what's there". They're already doing this now. A TiS button won't make it any worse. > 4. User influence on security policy > > Anti-spam defenses are similar to firewall rules: they control > site security. End-users should not be permitted to override > or otherwise modify firewall settings Strawman argument: This presumes that the site administrator allows this to happen, and secondly, that filter decisions directly follow _every_ TiS button hit. They don't need to, and I don't know of any filtering environment that does. > 5. Duplicates existing functionality > > All competently-run sites support the RFC 2142-stipulated > "abuse" role address and have appropriately experienced, > trained, qualified and diligent staff reading every message > sent there. First, this reverses the role of "abuse". Abuse is for abuse _originating_ at the site, which is of no help for abuse _received_ at the site. Secondly, existing abuse implementations just about always fail in this regard because a humungous chunk of the population doesn't have mail readers capable of constructing adequate abuse reports (eg: missing headers). We could, if we wished to, simply piggyback on RFC2142 (and email to abuse, losing the ability to triage the reports), but the standardization effort is still of value to provide actionable reports. Because most of them aren't now. > It's trivially easy for any user to forward > questionable mail traffic (with full headers of course) Aye, there's the rub - it's _not_ trivially easy now. There's no standard of what abuse forwards look like, and in the majority of cases, there are _no_ full headers. Forwarding full headers in outlook isn't trivial nor easy, and half the time _still_ get mucked up when the user tries to do it right thru no fault of their own (thank your favourite software manufacturer for that). The very best of the forwarding mechanisms are inconsistent and difficult to process. The worst of them are totally unuseable, and unfortunately the most numerous. It needs a standard format, at least, if it's to be done at all. > 6. Free useful intelligence for spammers > > It's great when your enemy hands you useful information. This presumes, of course, that spam reports go to spammers. Please explain to me how my TiS button leaks information to spammers. > 7. Creating more Internet mail traffic is a bad move This asserts a model of not reporting spam, and thereby limiting yourself to JHD at a server (or worse, user) level. This is a step backwards that we must not take. We have to move the fight back up the chain. > 8. Report-as-spam button repurposed as weapon > > We've already seen how spammers have repurposed any number of > ill-conceived anti-spam concepts (e.g., SAV) as weapons. Please explain how spammers use SAV as a weapon. They're not, because they can't and/or it doesn't have ROI versus simpler things they already have at their disposal. Sure, a spammer could use Verizon SAV to, say, DOS my mail servers. But it's is trivially easy to defend against. Now, instead, the spammer gets their botnet to DDOS me directly. That's a lot harder to stop, and simpler for them to implement. Yes, of course there are examples of anti-spam mechanisms repurposed as weapons. Eg: the late unlamented BlueFrog. But at this stage of the game, presuming that the nebulous spec we're talking about is of necessity reusable as a weapon is absurd. We can't say that until we know what "it" is. All of the big/high value targets have TiS buttons now. Many spammers _only_ spam/care about the big boys. Please explain how spammers are using TiS buttons as a weapon against the big boys. They aren't. > 9. The zombie problem By that argument, the war is lost, all the machines are pwned anyway, _nothing_ is useable or trustworthy, and the Internet should turn off the lights. We're not at that state (yet), so the argument doesn't hold. I should point out, by way of demonstration, that if the argument is true, then port 25 blocking doesn't work. All the bots would be using the user's SMTP server, and port 25 blocking wouldn't help. Right? Wrong. Port 25 blocking does work.
- [Asrg] Summary/outline of why the junk button ide… Rich Kulawiec
- Re: [Asrg] Summary/outline of why the junk button… Daniel Feenberg
- Re: [Asrg] Summary/outline of why the junk button… Jose-Marcio Martins da Cruz
- Re: [Asrg] Summary/outline of why the junk button… Alessandro Vesely
- Re: [Asrg] Summary/outline of why the junk button… Rich Kulawiec
- Re: [Asrg] Summary/outline of why the junk button… Alessandro Vesely
- Re: [Asrg] Summary/outline of why the junk button… Rich Kulawiec
- Re: [Asrg] Summary/outline of why the junk button… Martijn Grooten
- Re: [Asrg] Summary/outline of why the junk button… der Mouse
- Re: [Asrg] Summary/outline of why the junk button… Chris Lewis
- Re: [Asrg] Summary/outline of why the junk button… Daniel Feenberg
- Re: [Asrg] Summary/outline of why the junk button… Michael Thomas
- Re: [Asrg] Summary/outline of why the junk button… Steve Atkins
- Re: [Asrg] Summary/outline of why the junk button… Barry Shein
- Re: [Asrg] Summary/outline of why the junk button… Chris Lewis
- Re: [Asrg] Summary/outline of why the junk button… Chris Lewis
- Re: [Asrg] Summary/outline of why the junk button… Steve Atkins
- Re: [Asrg] Summary/outline of why the junk button… Daniel Feenberg
- Re: [Asrg] Summary/outline of why the junk button… BOBOTEK, ALEX (ATTLABS)
- Re: [Asrg] Summary/outline of why the junk button… Jose-Marcio Martins da Cruz
- Re: [Asrg] Summary/outline of why the junk button… John Levine
- Re: [Asrg] Summary/outline of why the junk button… Barry Shein
- Re: [Asrg] Summary/outline of why the junk button… Ian Eiloart
- Re: [Asrg] Summary/outline of why the junk button… Ian Eiloart
- Re: [Asrg] Summary/outline of why the junk button… Ian Eiloart
- Re: [Asrg] Summary/outline of why the junk button… Ian Eiloart
- Re: [Asrg] Summary/outline of why the junk button… Dennis Dayman
- Re: [Asrg] Summary/outline of why the junk button… Paul Russell
- Re: [Asrg] Summary/outline of why the junk button… Chris Lewis
- Re: [Asrg] Summary/outline of why the junk button… Ian Eiloart
- Re: [Asrg] Summary/outline of why the junk button… Barry Shein
- Re: [Asrg] Summary/outline of why the junk button… Steve Atkins
- Re: [Asrg] Summary/outline of why the junk button… Barry Shein
- Re: [Asrg] Summary/outline of why the junk button… Chris Lewis