Subject: Re: [Asrg] Adding a spam button to MUAs

From: Rich Kulawiec <[email-masked]>
Date: Thu, 4 Feb 2010 14:47:43 -0500

On Wed, Dec 16, 2009 at 01:59:04PM -0500, Seth wrote:
> Rich Kulawiec <[email-masked]> 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.html

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 05 Feb 2010 10:51:30 +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 <[email-masked]> wrote:

> _______________________________________________
> Asrg mailing list
> [email-masked]
> 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/

---

From: "Andrew Richards" <[email-masked]>
Date: 5 Feb 2010 12:04:37 +0000

I'd like to add a new angle to this thread:

We've been debating how it will work, but it could also be an opportunity 
to consider what to report - in particular by classification. So far we've 
been focused on having a method of saying:

 - This is spam/unwanted

but it may be more useful to expand this to further categories (more than 
one might be specified):

 - This is spam
 - This is unwanted
 - Unsubscribe from mailing list etc.
 - This is a virus
 - This is a phishing mail

Clearly if there's just one button you'd probably have to go for "This is 
spam" or "This is unwanted", but some MUAs might choose to provide a richer 
feature set for how unwanted mail is reported.

These categories clearly overlap with those of ARF - the base values 
abuse/fraud/other/virus cover most of the above and more categories can be 
added / already exist; is there an issue with (as I understand ARF) only 
being able to specify a single category for a message? Does ARF handle a 
generic 'unwanted' adequately with its 'other' category?

Whether ARF or IMAP, POP extensions etc are used to communicate the 
unwanted-ness of the message, the ARF categories clearly look to be useful 
for the reporting and could form part of the IMAP, POP etc. mechanisms if 
that's the route taken.

cheers,

Andrew.

---

From: David Wilson <[email-masked]>
Date: Fri, 05 Feb 2010 12:25:05 +0000

>  - Unsubscribe from mailing list etc.

Would the expectation be that the mail server performs this operation on
the user's behalf?

If so, my recent experience is relevant. I was getting quite a few
regular messages from some sites. These were not spam within any normal
definition because they were targeted and also almost vaguely relevant
to my business. However, I didn't want them. So I looked at the
unsubscribe options available. They varied.

Some messages had List-unsubscribe headers. However, some were mailto:
URLs, which is probably the best. Others were http: URLs. Most of these
took you to a page where you had to enter information in order to
unsubscribe.

Those with no List-unsubscribe generally had a link like the latter
named.

In some cases the subscription removal request resulted in a message
with a http link which, when followed, resulting in the removal.

So, in many cases automatic processing of the subscription removal was
not possible. So, I don't this this is something which should be
demanded of the mail service provider.

I would suggest that subscription removal is really a job for the UA
itself. Perhaps, if there is a List-unsubscribe header, an option to
follow that could be enabled through a button or menu option.

Related to this is the common folklore that you should not attempt to
unsubscribe from a spam, as this could tell the spammer that the email
address is 'live', thus exposing you to more spam. Is there actually any
evidence that this is true? It certainly does not seem to be the case
that spammers remove from their lists unresponsive email addresses.

(BTW the requests for subscription removal which I made seem to have
worked!)

regards

David Wilson

---

From: John Levine <[email-masked]>
Date: 5 Feb 2010 15:27:02 -0000

>but it may be more useful to expand this to further categories (more than 

Hi, Andrew.  Please don't take this personally, but

GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHH.

We've been through this in other contexts, and from all the evidence
I've seen, one button to make stuff go away is all that people are
going to use.  Web mail systems have a lot of experience with spam
buttons and the people who run them tell me the same thing.

The only multi-option spam button I've seen that seems at all workable
is Gmail's. If the message has a List-Unsubscribe: header and some
other stuff (I forget the details) that make it look like a legit
mailing list message, it asks if you want to unsubscribe instead, and
if you agree, uses the URL in the header.

We've tentatively agreed to remove all the options but spam and virus
from ARF going forward since they're the only ones that anyone says
they use.

R's,
John

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 9 Feb 2010 07:36:39 -0500

> took you to a page where you had to enter information in order to

They should all have email addresses of the form

	[email-masked]

which support this function per RFC 2142.  Other addresses, as well
as web-based mechanisms, are fine too, but this is something that
every mailing list should support.  (As an aside, it's quite remarkable
how many supposedly-professional mailing list operations fail to
pass this rudimentary test of their baseline expertise.)

> that spammers remove from their lists unresponsive email addresses.

Yes, there is conclusive evidence that this is true *of some spammers*.
Carefully-constructed experiments have repeatedly demonstrated that while
in some cases the result of such will be an unsubscribe, in other cases
it's led to (a) more spam from the same spammer, same domain (b) more
spam from the same spammer, different domain, (c) more spam from a different
spammer (d) various combinations and variations of (a)-(c).  This is
entirely sensible on their part of course: anyone so helpful as to
respond to spam is not only providing this information to the
enemy, but is signalling that they make a suitable victim.  And while
there are of course many clueless spammers out there who won't
recognize the opportunity thus presented, there are some who will.

But the more general principle that this falls under is that it's a
strategic error to provide spammers with any usable intelligence, as
they've long since displayed both the inclination and the ability to
aggregate it and process it.  And of course it's laughable to even
suggest to that they will do so in any way that benefits us.

---Rsk