[Asrg] Summary/outline of why the junk button idea is pre-failed

[Rich Kulawiec <[e-mail]>]

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. ;-)

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.

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.

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.

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.)

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.

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.

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.

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.

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.

	It doesn't really matter.  Whatever the number is, it's enormous,
	and growing steadily.  And abusers who now own those systems *also*
	own every report-as-spam button that those users have access to,
	e.g., if they have a work email account, home email account,
	freemail account, then they fully control all three.  They can
	suppress pushes; they can create pushes.  They can generate
	ersatz traffic in order to suppress or create pushes related
	to it.  They can manipulate this any way, every way, they wish.

	They can create additional email accounts -- at their own ISP
	(many consumer ISPs offer 5 per household and similar) or at
	freemail providers just to have more buttons to push more often.
	Or *not* to push, which is just as important.

	Moreover, they can do this easily and cheaply, and far faster
	than real live users can.  And they can do it in much greater
	numbers -- surely it is extremely unrealistic to expect all
	users, or a majority of users, to use such a button,
	even if furnished to them.

	Which means that spammers can easily dominate the statistics by
	as much as they wish.  They could, on a whim, account for 10% or 50%
	or 90% or 99% of them.  Of course, *today* there is little reason
	for them to bother.  But if we (again, very over-optimistically)
	presume that a report-as-spam mechanism is deployed tomorrow
	without any of the *other* issues listed above, THEN they will
	have a reason to.  Spammers have long since proven that they can
	and will innovate when they need to -- and quickly.

Summary of the summary:

I think any of 1, 6, 7, 8, and 9 alone are sufficient to kill the
idea outright.  9 kills a lot of ideas outright: it's the elephant
in the room that lots of people like to ignore or wishful-think away
because it neatly undercuts what they're proposing.  6 is often
badly under-estimated by those who haven't put in the time required
to study the enemy.

I think 2 and 3 are strong points but not sufficient to kill it.

I think 4 is arguable, but sites which allow users to override system
and network administrators tend to show up on the dataloss mailing
list and similar.  It's a very bad move to allow users to make any
decision related to security: they will invariably choose poorly.
(e.g., Knight-in-cave-after-bad-guy-dies-horribly: "He chose...poorly".
Yeah.  Like that.)

We've had 5 for years; what we unfortunately don't have are sites
that operate their abuse desks properly.  A button is not a substitute
for diligent staff who are willing to individually investigate every
single abuse report. This is called "baseline competence" and it's quite
reasonable to expect it of every operation, regardless of size.

Could *some* of these be mitigated?  Yes.  Rate-limiting, DNS bogusing,
firewalling, and other mechanisms might be able to at least slow down some
of the resulting attacks and abuse.  (For example, DNS bogusing can be
used to prevent users on intranets from resolving the hostnames of
known-phishing sites, thus probably preventing them from accessing their
web sites.  Of course this won't work for users who are reading their
work email from home and using their ISP's resolvers.)  But there's no
fixing 1, 2, 6, 8 or 9.

Bottom line: widescale deployment of this builds a mechanism that spammers
will own the moment they choose to do so.  I can't say for certain what
they'll choose to do with it, but it would be silly to think that whatever
they do with their brand-new toy will be for *our* benefit.

---Rsk