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

+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
> Asrg(_at_)irtf(_dot_)org
> http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg