Re: [Asrg] Adding a spam button to MUAs

Ian Eiloart <iane@sussex.ac.uk> Fri, 05 February 2010 10:50 UTC

Return-Path: <iane@sussex.ac.uk>
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 B78463A6A93 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 02:50:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.453
X-Spam-Level:
X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, 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 sSKc8RErHUU7 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 02:50:41 -0800 (PST)
Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 31C443A6ADF for <asrg@irtf.org>; Fri, 5 Feb 2010 02:50:41 -0800 (PST)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:59188) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KXD7I9-0004TY-O7 for asrg@irtf.org; Fri, 05 Feb 2010 10:51:46 +0000
Date: Fri, 05 Feb 2010 10:51:30 +0000
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <3935EA9F45984B28172B806D@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <20100204194743.GA16492@gsp.org>
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan> <20091216014800.GA29103@gsp.org> <DBF77720-200E-4846-949F-924388F9CC15@blighty.com> <20091216120742.GA28622@gsp.org> <20091216185904.3B9032421D@panix5.panix.com> <20100204194743.GA16492@gsp.org>
Originator-Info: login-token=Mulberry:01xCTAMS2FLpYFkRSTMEo3mTOkKpzhiydKOY8=; token_authority=support@its.sussex.ac.uk
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
Subject: Re: [Asrg] Adding a spam button to MUAs
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: Fri, 05 Feb 2010 10:50:42 -0000

So, Rich,

Is it your position that users should not have any mechanism to report 
spam? Or that standardisation of a reporting procedure would be harmful 
because that makes it easier for spammers to finesse the system? Or 
something else?

--On 4 February 2010 14:47:43 -0500 Rich Kulawiec <rsk@gsp.org> wrote:

> On Wed, Dec 16, 2009 at 01:59:04PM -0500, Seth wrote:
>> Rich Kulawiec <rsk@gsp.org> wrote:
>> > There's the zombie problem.  There is no way for anyone or anything
>> > external to an end-user's system to know whether the button click
>> > (or equivalent event) was generated by a user or by software working
>> > at the behest of the new owner of the user's former system.  Given
>> > that the zombie problem is epidemic and presently unstoppable,
>> > widescale deployment of any such mechanism will lead to its use by
>> > zombie-resident malware as soon as it's advantageous for abusers to
>> > do so. Thus, anyone proposing such a "report as spam" mechanism on a
>> > large scale must also include in their proposal a workable plan for
>> > solving the zombie problem.
>>
>> How would it be advantageous for a zombie to report as spam?  Report
>> as non-spam, sure, to game the filters.  But with the data being noisy
>> to begin with, zombies adding noise don't have much effect; they might
>> require tuning of the filters.
>
> Well, the zombie problem is massive enough that *if* spammers found it
> useful to do so, they could, on a whim, generate enough noise to swamp
> the signal.  After all, they now own every email credential present on,
> or used on, all those zombie systems.  If we take very conservative
> estimates for (a) zombie population and (b) email credentials/zombie,
> which I'll put at 100M and 5, that's half a billion accounts that can be
> used for starters.  I think much more realistic estimates are probably
> 200M and 10, BTW, but I we're still talking an order of magnitude around
> "billion".  That's not only a large number, but it's much larger than the
> number of users who would use such buttons, and *many* orders of magnitude
> larger than the number of clueful users, whose fraction of the population
> I would place at no more than 1 in 10e5-10e6.
>
> There's also nothing stopping those same spammers from creating an
> essentially-unlimited number of email accounts anywhere that those zombies
> (or the access/credentials on them) permit them to.  That starts with ~10K
> freemail providers and extends to any ISP or email provider that allows
> its users to create multiple accounts.  (For example, my DSL provider
> allows me to create up to 7.  I've only got 1 in service, but anyone who
> hijacked my desktop system would be able to create the other 6 and --
> if careful enough -- prevent me from noticing.)  This is fairly common
> with major consumer ISPs, which allow users to create email accounts
> for additional family members.
>
> All of this combined means that spammers could easily overwhelm any such
> reporting system the moment it went live.  They've already beaten it.
>
> Now as to why they might bother:
>
> They stand to gain considerably by (a) creating FP reports (b) creating
> FN reports (c) suppressing TP reports (d) suppressing TN reports.  And
> they can use the same zombies (or other systems) to generate traffic
> which can then be processed (a) through (d).
>
> For example, they could go after their competition with (a).  They could
> try to avoid classification of their own spam with (c).  They could
> generate targeted traffic -- e.g., a spam run to known-owned accounts --
> and use (b) to mark it as not-spam.  There are all kinds of combinations
> available to them -- it's just a matter of what goal(s) they might have
> and what it's worth to them to pursue those goals.  (And I think I'll
> stop outlining scenarios here as I'm sure they're listening.)
>
> Now, certainly some heavy-handed manipulation might be detected, and
> I'm sure it would/will be.  But [some] spammers are very crafty, and
> are easily smart enough to figure out how to game the system.  And
> if/when the system poses an inconvenience to them: they will.  They've
> done it repeatedly in the past.  (See "zombies, creation of in order
> to evade contemporary DNSBLs")  It would be a major strategic error
> to underestimate either their willingness or their ability to turn
> this to their advantage.
>
> So I see this entire approach as pre-failed.  Even in an imaginary
> world where users could function as reliable classifiers (and in
> this real world, they are absolutely miserable classifiers: we all
> know this because we know that if they *weren't*, we would not be
> here discussing how to address the spam problem [1]) spammers have
> the capability of generating far more inputs to the aggregate system
> than all humans combined, and thus dominating the results by a huge
> margin -- for whatever purpose suits them.
>
> ---Rsk
>
> [1] For example, as Juha-Matti Laurio noted on "funsec" just yesterday:
>
> 	"Internet scammers had a bumper year in 2009 with people around
> 	the world continue to be duped by so-called 419 frauds, with one
> 	Dutch private investigation company estimating the highest ever
> 	annual losses occurred in 2009.
>
> 	Victims lost at least US$9.3 billion last year, up from $6.3
> 	billion in 2008, said Frank Engelsman of Ultrascan, a Dutch
> 	company that investigates 419 scams - also known as advance-fee
> 	frauds (AFFs) - and other types of crime. Ultrascan will release
> 	a complete report on Friday on its website.
>
> 	AFF scams originating in Nigeria were so pervasive that the
> 	country's Economic and Financial Crimes Commission stepped up law
> 	enforcement efforts in recent years to crack down on scammers."
> 	--clip--
>
> 	More at
> 	http://www.computerworlduk.com/management/security/cybercrime/news/index
> .cfm?newsid=18581
>
> 	It appears that the report is here:
> 	http://www.ultrascan-agi.com/public_html/html/public_research_reports.ht
> ml
>
> _______________________________________________
> Asrg mailing list
> Asrg@irtf.org
> http://www.irtf.org/mailman/listinfo/asrg



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/