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

[Ian Eiloart <[e-mail]>]

--On 2 March 2010 08:18:10 -0500 Rich Kulawiec <[e-mail]> 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. ;-)
>
> 1. User incompetence

Crowd sourcing should be used to gather confidence in reports when they're 
many. Admin inspection can be used when they're few.

> 2. User time

Nobody is asking them to classify every message. This is tool that they can 
choose to use, or not. Indeed, the mechanisms that we're discussing are 
about how the user system can communicate classification to the 
administrator. This could be done by the user client filter. Remember, the 
user is already trusting the filter to hide email.

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

That depends on where the reports go. On my system, they'll be coming to 
me.

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

Ah, so that's not an argument against providing a junk button at all, 
merely a caution. Noted.

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

Right, but most don't know that the address exists, and don't know what 
full headers are. A junk button *could*  (A) expose the reporting mechanism 
to the user, and (B) ensure that the reports are useful by ensuring that 
they include full headers.

In fact, I think that you've just given a convincing argument FOR a junk 
mail button.

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

My reports won't be going to spammers. Have you really been reading this 
thread?

> 7. Creating more Internet mail traffic is a bad move

Agreed. That's why I'm advocating IMAP flags or annotations as a better 
solution.

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

Again, the mechanism should only generate reports to the administrator, and 
the administrator needs to have quality assurance mechanisms in place. 
You've suggested some. Others are available.



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