Re: [Asrg] Adding a spam button to MUAs

I've thought much the same thing for years. To throw something else out, I think
that this is tied up with what I call "the alerting problem". That is, we are 
fed
many different streams of information these days (email, im, voice, news...) 
each of which
has their own filtering and prioritization -- if you're lucky. By alerting, I 
mean
the means that you become aware (or not) of a piece of communication vying for 
your
attention.

What I really want is to have the streams classified as is relevant to me, where
the alerting mechanism is tied to its *importance* to me, rather than the 
communication
channel. That is, there is nothing inherent with voice that should give it
preference to wake me from my sleep to hear an ad for the latest in garbage pail
liners. I want something to make sense of all of these things and raises things
to my conscious as makes sense for *me*.

Give me that, Nigerian scams and penis enhancement all pretty much take care
of themselves -- my classifier already knows that I could give a flying-f about 
those.

Mike

On 12/16/2009 03:20 PM, Nathaniel Borenstein wrote:
> I've tried hard to resist chiming in on this, but can't help myself.
>
> I suggest that the issue of defining or identifying spam is a red herring and a huge distraction 
> from actual progress.  The real issue is identifying mail that a specific user does not want.  When 
> defined this way, it subsumes the spam problem, but it also maps more directly onto the user's 
> action with a spam/junk button.  In this view, if a user clicks the spam/junk button for messages 
> that we email gurus don't consider "spam," that's just fine -- each user is the expert in 
> defining "junk" for their own mailbox.
>
> As volumes continue to increase, I believe email streams need to be viewed more 
> like intelligent news feeds -- we need to use sophisticated per-user 
> information to choose which items to pass on to the user and which to block.  
> The spam/junk button can be very useful input to that process.  But there's 
> more to it than that -- once we start doing our spam filtering with individual 
> recipients in mind, we can do a lot of things right that we can't now.  For 
> example, after twenty years of using spam filters, I still get spam in Chinese 
> or Russian, languages I don't understand at all, because the spam filters know 
> nothing about me as an individual.  Similarly, I'm sure that plenty of people 
> in China get spam in English that seems obviously irrelevant to them.  This 
> drives me nuts, because it would be so easy to fix if our filtering was done 
> with even a minimal knowledge about the individual recipient.
>
> In short, the real need is for user-focused email filtering to subsume our 
> current notion of spam filtering.  Viewed that way, I think a spam/junk button 
> would be an obvious win.   But it should be part of a broader interface (yes, 
> an authenticated one, most likely) by which individuals could interact with 
> their email filters, e.g. to say which languages they do and don't understand, 
> or even which topics they were and weren't interested in receiving unsolicited 
> messages about.  (Who knows, maybe there's even someone out there who doesn't 
> want most spam but is desperate to enlarge the size of their private body 
> parts; shouldn't they be able to communicate that fact to their filters?)  -- 
> Nathaniel
>
>
> On Dec 16, 2009, at 5:51 PM, Douglas Otis wrote:
>
> > On 12/16/09 10:59 AM, Seth wrote:
> >
> > > > There's the zombie problem.  There is no way for anyone or anything
> > > > external to an end-user's system to know whether the button click
> > > > (or equivalent event) was generated by a user or by software working
> > > > at the behest of the new owner of the user's former system.  Given
> > > > that the zombie problem is epidemic and presently unstoppable,
> > > > widescale deployment of any such mechanism will lead to its use by
> > > > zombie-resident malware as soon as it's advantageous for abusers to
> > > > do so. Thus, anyone proposing such a "report as spam" mechanism on a
> > > > large scale must also include in their proposal a workable plan for
> > > > solving the zombie problem.
> > > How would it be advantageous for a zombie to report as spam?  Report
> > > as non-spam, sure, to game the filters.  But with the data being noisy
> > > to begin with, zombies adding noise don't have much effect; they might
> > > require tuning of the filters.
> > Users without 0wned systems might still attempt to unsubscribe from spoofed subscriptions 
> > and be asked for passwords they never set, and then attempt to guess it anyway. There are 
> > also risks related to browser vulnerabilities that would be avoided by offering a 
> > "this is junk" button that invokes an unsubscribe service, even for user who 
> > have initially confirmed the subscription.
> >
> > To avoid complaints, a web page associated with an email account could allow users a means to confirm their 
> > desire to unsubscribe, or just have user authentication included in the "this is junk" transaction, 
> > which might simply mean placement into the "junk" folder.  As such, it would be in the interest of 
> > list administrators to unsubscribe "unwanted" email based upon this feedback.
> >
> > This feedback should not be confused with "spam" email feedback. Recently, new developers within 
> > our company confused these two categories and caused a number of complaints.  It is important to understand 
> > the difference between "unwanted" and "spam-trap" as determined by the source of the 
> > feedback.
> >
> > Spammers will surely abuse any control mechanism in an effort to cause user 
> > complaints.  User complaints will cause the mechanism to be abandoned as being 
> > too expensive.  Users that are 0wned will likely be detected with spam-trap 
> > feedback, as well as through other mal activity.
> >
> > Any effort to utilize email feedback MUST understand the difference between a general category of 
> > "unwanted" and feedback from "spam-traps" that are able to differentiate between 
> > "auto-responses" and DSNs.
> >
> > -Doug
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg