Re: [Asrg] Adding a spam button to MUAs

On 1/29/10 8:42 PM, Chris Lewis wrote:
> Rich Kulawiec wrote:
> > I don't think this is elitist, I think it's a matter of recognizing that
> > the spam/not-spam classification process requires expertise *vastly* in
> > excess of that possessed by almost all users.  This is not their "fault"
> > per se because it's not a fault: it's simply a lack of area-specific
> > experience and knowledge.
> You seem to be seeing it only as "a single ordinary user making 
> site-wide decisions on what to block" versus "totally ignoring what 
> the users say" choice.
> If that binary choice was the only choice, I'd agree with you.  I have 
> enough horror stories of goofs in that regard.  Hell, I have enough 
> horror stories when the alleged expert (me) screws up good.
> But that is _not_ the choice.  Acting as if it is is at least 
> mistaken.  TiS buttons aren't implemented that way.
> _Nobody_ is talking about individual ordinary users making site-wide 
> decisions of what to block.  That requires very high levels of 
> expertise as you say.  But there is absolutely nothing whatsoever 
> wrong with taking note of what those individual users are saying, and 
> using it in a statistical fashion to guide your filtering.  That is 
> how TiS buttons are used in infrastructures large enough to bother 
> with them.  It is, after all, how Spamcop was originally implemented, 
> and it's still part of their decisioning process albeit less than it 
> used to be.
> There are non-user-driven DNSBLs less useful than Spamcop ;-)
>
> If we were to specify/standardize/or even (gasp) implement a common 
> TiS strategy/implementation that actually drives filters, the crucial 
> part is coming up with a "filter decisioning" strategy that the admins 
> can tune, and has reasonable defaults.
One trend making eradication of spam fairly difficult is when large ISPs 
have customer's accounts compromised by the tens of thousands.  This 
problem can elude statistical analysis, as you suggest.  Often less than 
a dozen emails that appear to be fairly real are sent from any 
particular account.   These compromised accounts might be used to commit 
other nefarious acts beyond spamming,  such as deceiving friends in the 
address book that the holder of the account is stuck in a third-world 
airport with their credit-cards and tickets stolen, and is requesting a 
wire-transfer.
Being able to employ end user feedback indicating unwanted input might 
be of greater benefit as a warning for compromised account holders, than 
as a method of eradicating spam or for tuning filters, due to a 
potential for creating false positives.  False positive filtering 
trained by user's feedback can happen when someone forwards email from 
one account to another.  While this type of feedback can help identify 
spam missed by content filters, spammers have become better at creating 
content nearly indistinguishable from normal chatter.
Developing practices better at securing customer accounts are needed, in 
addition to offering account holders warnings that their email account 
appears compromised, which might mean imposing some type of security 
hold on the account.  While this could be costly from the aspect of 
customer support, providers need to accept a fiduciary obligation at 
keeping accounts secure, which is to monitor and report evidence of 
abusive activity.  This monitoring should include tracking end-user 
feedback, as well as finding methods to block break in attempts.
-Doug




_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg