Re: [Asrg] Summary/outline of why the junk button idea is pre-failed
Daniel Feenberg <feenberg@nber.org> Tue, 02 March 2010 13:42 UTC
Return-Path: <feenberg@nber.org>
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 020353A8973 for <asrg@core3.amsl.com>; Tue, 2 Mar 2010 05:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.461
X-Spam-Level:
X-Spam-Status: No, score=-4.461 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PROFILE2=1.981, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, UNPARSEABLE_RELAY=0.001]
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 pDQYvjT6fPFs for <asrg@core3.amsl.com>; Tue, 2 Mar 2010 05:42:30 -0800 (PST)
Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id 19D4C3A8923 for <asrg@irtf.org>; Tue, 2 Mar 2010 05:42:29 -0800 (PST)
Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.3/8.13.8) with ESMTP id o22DgRH8071158 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 2 Mar 2010 08:42:28 -0500 (EST) (envelope-from feenberg@nber.org)
Received: from nber6.nber.org (localhost [127.0.0.1]) by nber6.nber.org (8.13.8+Sun/8.12.10) with ESMTP id o22DeXEQ019427; Tue, 2 Mar 2010 08:40:33 -0500 (EST)
Received: from localhost (Unknown UID 1079@localhost) by nber6.nber.org (8.13.8+Sun/8.13.8/Submit) with ESMTP id o22DeX8h019424; Tue, 2 Mar 2010 08:40:33 -0500 (EST)
X-Authentication-Warning: nber6.nber.org: Unknown UID 1079 owned process doing -bs
Date: Tue, 02 Mar 2010 08:40:33 -0500
From: Daniel Feenberg <feenberg@nber.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <20100302131810.GA22938@gsp.org>
Message-ID: <Pine.GSO.4.64.1003020824500.16639@nber6.nber.org>
References: <20100302131810.GA22938@gsp.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20100301 #3679174, check: 20100302 clean
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 13:42:32 -0000
On Tue, 2 Mar 2010, Rich Kulawiec wrote: > I'm going to try to summarize and enumerate some of the arguments against > the general idea of a report-as-spam button. My position is that several > of these points (individually) make the case that it's a truly bad idea > and should be abandoned immediately and permanently, and that collectively, > they're an overwhelming rationale. Others differ, of course. > > This is a *summary* and not an attempt to provide every nuance > of every argument, so nitpicking is discouraged. You may rest > assured that I read the traffic on this list and have been paying > close attention to the spam problem for the past several decades. ;-) This message ignores the existence of TIS buttons on existing MUAs for webmail operators, and the actual experience that those operators have. > > 1. User incompetence > > Users have spent the last quarter-century conclusively proving > that they cannot reliably discern spam from non-spam. They stack > the pile of evidence higher every day, by misclassifying spam > as non-spam and vice versa, by replying to spam, by trying to > unsubscribe from spam, by falling for phishes, by handing over > valuable information to spammers, etc. How many "unsubscribe" > requests do we see sent to entire mailing lists, even by > supposedly-mail-literate technical personnel? How many people > on public mailing lists cannot distinguish between on-list and > off-list replies? It's not reasonable to expect that anyone who > has failed to master these rudimentary email tasks will be able > to distinguish spam from non-spam, especially when some spam is > more competently composed and delivered than some non-spam. > > This is, I'm sorry to say, not a solvable problem. And it will > steadily get worse as more (less-experienced) people get online, > and as spammers get craftier: evolutionary pressure on spammers > is clearly selecting for the smarter ones. > > This can't be avoided by educating users: "educating users" > is one of Marcus Ranum's six dumbest ideas in security for very > good reason. In the case of spam, we KNOW it has failed because > we wouldn't have much of a spam problem to worry about if it > had worked even modestly well. > Users are incompetent, that is why the existing systems use a single hit on the TIS button only to affect mail to the user hitting the button, and only affect mail to other users if a large number of users hit the button. > 2. User time > > Let's assume that #1 is completely wrong: let's assume that > most/all users are competent spam/non-spam classifying engines. > Let's further assume that they're so proficient at it that they > can do so in 5 seconds per message. > > 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. 6.3 million > decisions/pushes equates to about a man-year, which means that even > a single small spam run (say 300 million attempts, 3% delivery rate, > thus 9 million deliveries) can easily chew up well over a man-year > of time. Do the math. > > Part of the reason we try to stop spam/spammers is to prevent > them from using up end-user time. We should not be tasking > users with this, as it neatly undercuts part of what we're > trying to do. I can do spam at 1 second per message or less, and with the TIS button I will get less spam, saving even that second. > > 3. User exposure > > Many clueless users, unfortunately, use web browsers or otherwise > HTML-enabled mail clients to read their mail. (Of course we can > safely presume that competent professional postmasters or abuse > desk personnel don't do this, but the report-as-spam button is > intended for the masses, and they, sadly, do.) > > It is certain that in the process of trying to perform classification > tasks, they'll click on links "just to see what's there". This > not only provides very useful information to spammers, but it will > assist phishers, trojan downloaders and others whose goal isn't > really spamming per se, but using spamming to penetrate > systems/networks or perform reconnaissance on them. > It is mere speculation that the existence of the button will cause more clicks on malware - I don't see why it should, and in any case if the MTA acts on the TIS reports, there will be fewer opportunities for users to make this mistake. > 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: neither should they > be permitted to override or otherwise modify anti-spam settings. > First, because it's not their job, second, because they're > not responsible for the consequences, third, because they > lack expertise in this area. > > (This is not to say that they shouldn't have input. But all such > input should be manually, carefully reviewed by qualified and very > skeptical personnel before any decisions are made about using it.) > Please see Hanna Arendt "The Authoritarian Personality" for an explanation of this claim. Really, if you reject all user influence you will not have happy users. > 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. It's trivially easy for any user to forward > questionable mail traffic (with full headers of course) to > the abuse address of their own mail provider, who can then > decide what to do about it. These personnel are far better > situated to decipher headers, correlate against logs, > assess threat severity, etc. They're also much less likely -- > presuming that they're competent -- to hand over useful > information to the enemy. See next point as well. > I have never gotten a usefull spam complaint from a user, but it isn't because the messages weren't spam. It was always because the user didn't include the headers. All users find it difficult to include headers with forwarded messages, and will always drop the issue when asked to resend with headers. The TIS button solves this problem. > 6. Free useful intelligence for spammers > > It's great when your enemy hands you useful information. > > It's even better when they expend considerable time and effort to > do so. Spammers can quite easily rig this methodology to provide them > with a wealth of actionable intelligence -- and some of them will. > We should not be building mechanisms that directly support the enemy. > Really, this is all supposition and there is no evidence that any spammer cares. There are many claims that spammers must care, but no examples of cases where they actually did care. > 7. Creating more Internet mail traffic is a bad move > > We're drowning in (as a more generic term than "spam") junk > SMTP traffic. The last thing we should do is create more of it. > Every possible thing we do to fight spam should dampen the response, > not amplify it. > > This (sending outbound traffic) also violates a fundamental > principle of abuse control: do not allow attackers to generate > outbound traffic from *your* site to destinations of > *their* choosing. This never ends well. > If even a small proportion of the TIS hits result in action, the total traffic will decrease. If the proportion of hits resulting in action is too small, then users will stop hitting the button and there will be little traffic increase. > 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. > They'll do that with this too, should it profit them to do so. > I trust at least a few methods are obvious on inspection; > there's also a few non-obvious ones that I will not be discussing > on a public mailing list, some of which relate to the next point. > Has this happened on any of the services that currently offer TIS buttons? How have they handled that? > 9. The zombie problem > > There are, at bare minimum, 100 million fully-0wned systems > out there. I've seen estimates as high as 250M (Cerf) and more > moderately, 140M (Kletnieks). My back-of-the-envelope > estimate is currently 200M. And climbing. > >... As long as there are zombies, no anti-spam or indeed and security related protocol is hopeless. But such protocols are necessary if not sufficient and we shouldn't refuse to take action merely because MS refuses to do its part. Indeed, their excuse for not taking any action is the same - as long as the rest of the internet is insecure why should they be any different? >... Daniel Feenberg
- [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