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

["BOBOTEK, ALEX (ATTLABS)" <[e-mail]>]

+1

In the real world, there is so much positive experience with spam
reporting.  Vipul's Razor (report-based spam filter) evolved into a
commercial filter now used by most major US-based ISPs.  Sure there are
problems that need to be dealt with (e.g., unsubscribe, gaming, random
human errors), but rather effective solutions (including but not limited
to those involving reporter reputation, low-pass filters, and a "Not
Spam" button) have been found.  

In OMA (SpamRep abuse-reporting standards activity), the accepted wisdom
is that the reporting protocols should be standardized, but that the
backend processing (interpreting the reports) and report destination
shouldn't (parenthetically, mechanisms for specifying destination and
authorizing forwarding may be within the scope of the OMA standards).  

Is there not enough of a plurality convinced of

* the benefits of reporting and
* the benefit of interoperability resulting from standardizing reporting

to proceed with standardizing abuse reporting?  


Regards,

Alex

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Chris Lewis
Sent: Tuesday, March 02, 2010 8:42 AM
To: [e-mail]
Subject: Re: [Asrg] Summary/outline of why the junk button idea is
pre-failed

On 3/2/2010 8:18 AM, Rich Kulawiec wrote:

I'm going to try to keep this brief, and at the same time avoid 
nitpickery.  I've put a point-by-point non-nitpickery response after 
"----", but, you can avoid reading that entirely and stick directly to:

It's not as if the industry doesn't lack ample experience with TiS 
buttons.  If TiS is as bad as you say, would anybody that matters still 
be using it?

Verizon abandoned SAV.  Did AOL, Gmail, MSN, Yahoo abandon TiS?  Nope.

I'm going to take a huge leap in suggesting that those guys are pretty 
smart, and if they still like them after a few bazillion man-years 
accumulated experience, they're probably right, and it is useful.

Especially when it agrees with my experience ;-)

You can stop reading now if you wish.
------------------------------------------------------------
> 1. User incompetence
>
>          Users have spent the last quarter-century conclusively
proving
>          that they cannot reliably discern spam from non-spam.

This flies directly opposite to my experience, and the experience of 
vastly larger environments than you or I.  They must know something, 
doncha think?

Certainly there are, er, lots of stupidities, but statistically, they 
still are a small fraction, and using statistical methods they can be 
ignored.

> 2. User time

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

You're assuming that this "classification task" is something that the 
end-user isn't doing already.  They already are.  At worst, we're adding

a button press.

This argument is only relevant if the TiS button is to be used _instead_

of filtering/if the TiS button isn't allowed to affect filtering in any 
way.  Nothing could be further from the truth.  It is an adjunct to 
filtering, where the time is only spent on the email the filters 
_missed_, with a goal of _both_ refining the filters yet further (to 
reduce the miss rate) as well as pushing the spam fight back to the 
originators (to stop the spam being sent at all).  Both are necessary, 
and both will _reduce_ the total amount of end-user time spent.

> 3. User exposure

>          It is certain that in the process of trying to perform
classification
>          tasks, they'll click on links "just to see what's there".

They're already doing this now.  A TiS button won't make it any worse.

> 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

Strawman argument:

This presumes that the site administrator allows this to happen, and 
secondly, that filter decisions directly follow _every_ TiS button hit. 
  They don't need to, and I don't know of any filtering environment that

does.

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

First, this reverses the role of "abuse".  Abuse is for abuse 
_originating_ at the site, which is of no help for abuse _received_ at 
the site.  Secondly, existing abuse implementations just about always 
fail in this regard because a humungous chunk of the population doesn't 
have mail readers capable of constructing adequate abuse reports (eg: 
missing headers).  We could, if we wished to, simply piggyback on 
RFC2142 (and email to abuse, losing the ability to triage the reports), 
but the standardization effort is still of value to provide actionable 
reports.  Because most of them aren't now.

>          It's trivially easy for any user to forward
>          questionable mail traffic (with full headers of course)

Aye, there's the rub - it's _not_ trivially easy now.  There's no 
standard of what abuse forwards look like, and in the majority of cases,

there are _no_ full headers.  Forwarding full headers in outlook isn't 
trivial nor easy, and half the time _still_ get mucked up when the user 
tries to do it right thru no fault of their own (thank your favourite 
software manufacturer for that).

The very best of the forwarding mechanisms are inconsistent and 
difficult to process.  The worst of them are totally unuseable, and 
unfortunately the most numerous.  It needs a standard format, at least, 
if it's to be done at all.

> 6. Free useful intelligence for spammers
>
>          It's great when your enemy hands you useful information.

This presumes, of course, that spam reports go to spammers.

Please explain to me how my TiS button leaks information to spammers.

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

This asserts a model of not reporting spam, and thereby limiting 
yourself to JHD at a server (or worse, user) level.

This is a step backwards that we must not take.  We have to move the 
fight back up the chain.

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

Please explain how spammers use SAV as a weapon.  They're not, because 
they can't and/or it doesn't have ROI versus simpler things they already

have at their disposal.

Sure, a spammer could use Verizon SAV to, say, DOS my mail servers.  But

it's is trivially easy to defend against.  Now, instead, the spammer 
gets their botnet to DDOS me directly.  That's a lot harder to stop, and

simpler for them to implement.

Yes, of course there are examples of anti-spam mechanisms repurposed as 
weapons.  Eg: the late unlamented BlueFrog.

But at this stage of the game, presuming that the nebulous spec we're 
talking about is of necessity reusable as a weapon is absurd.  We can't 
say that until we know what "it" is.

All of the big/high value targets have TiS buttons now.  Many spammers 
_only_ spam/care about the big boys.  Please explain how spammers are 
using TiS buttons as a weapon against the big boys.  They aren't.

> 9. The zombie problem

By that argument, the war is lost, all the machines are pwned anyway, 
_nothing_ is useable or trustworthy, and the Internet should turn off 
the lights.

We're not at that state (yet), so the argument doesn't hold.

I should point out, by way of demonstration, that if the argument is 
true, then port 25 blocking doesn't work.  All the bots would be using 
the user's SMTP server, and port 25 blocking wouldn't help.  Right?

Wrong.  Port 25 blocking does work.
_______________________________________________
Asrg mailing list
[e-mail]
http://www.irtf.org/mailman/listinfo/asrg