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

[Michael Thomas <[e-mail]>]

+1. Rich's polemic is *way* off the rails. Manifestly, as Chris points 
out about ISP's with their TiS buttons.

Mike, not to mention OL, Thunderbird...

Chris Lewis wrote:
> 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