Re: [Asrg] Summary of junk button discussion

["Chris Lewis" <[e-mail]>]

On 2/26/2010 7:22 AM, Alessandro Vesely wrote:
> On 25/Feb/10 21:28, Chris Lewis wrote:
>> On 2/25/2010 12:04 PM, Alessandro Vesely wrote:
>>> On 25/Feb/10 07:22, Chris Lewis wrote:
>>>> On 2/25/2010 12:45 AM, John Levine wrote:
>>>>
>>>>> The only think other than a junk button that appears useful is a
>>>>> not-junk button to display when looking at stuff in a junk folder. I
>>>>> suppose we could do that, but then we'd have to define what a junk
>>>>> folder is.
>>
>>> I don't think John meant a "general" definition here... :-/
>>
>> John seemed to be implying you can't have a "non-junk" button without a junk folder (eg: in an IMAP sense).
>
> That seems reasonable...
>
>> I was just pointing out Thunderbird's "not junk" implementation, which is functional independent of the existence of any kind of foldering mechanism, IMAP or otherwise.
>
> Yup. The JunQuilla extension makes that even more manageable. It is an
> interactive tool running on the end-user's box, though.

It doesn't have to be.

>> Heck, SpamAssassin even manages to tune Bayesian without having any end-user feedback at all.

> I never adventured into such esoteric settings. Are there howtos or
> any docs about it?

I think it's called "Autolearn".  I think it works by treating SA scores 
 > <threshold> as "spam", and scores < <possibly a different threshold> 
as "ham", and tunes Bayesian from that.  IOW: the existing SA rules 
refine Bayesian, and in the long term this allows Bayesian to 
cross-correlate across individual emails, and Bayesian score stuff that 
the SA rules don't necessarily even see.

>>> To recap, junk buttons can be embedded within a more sophisticated
>>> architecture (as for IMAP). But not the other way around: anti-spam
>>> filter training cannot (in general) be based upon junk buttons and
>>> abuse reporting.
>>
>> Of course you can train spam filters based on abuse reports. We've been
>> doing precisely that for 13 years in several different incarnations.
>
> Hm... I've been tinkering with my server's settings based on users'
> reports as well, but not automatically.

I've been doing it for years.

> There are various mechanisms,
> e.g. Vipul's Razor, that allow users to share their verdicts about the
> spamminess of a given message. However, in order to attach to junk
> buttons a meaning of "filter messages /like/ this" we would need to
> define what that means in rather unambiguous terms.

No, you don't.  That's up to the implementer of the report handler what 
it does.

Just as it is with Bayes.

Why are you treating this any different than spam/ham training in Bayes? 
  It's no different.

>> It may well make sense to include an "tickle IMAP" server as part of a
>> spec, but, also having an abuse reporting mechanism makes sure that you
>> have just about all implementations covered, IMAP or otherwise.

>> We could spec both, and leave it up to an installation or user to decide
>> which (or both) to use in any particular instance.

> I'd lean toward specifying just how to deliver abuse reports. Neither
> junk buttons nor their color should be mandated.

Who is trying to specify buttons or their color?

I'm aiming for a specification that permits a single <user action> to 
communicate upstream for _both_ filtering and reporting purposes, where 
whether it's used for filtering or reporting or both in any given 
instance is up to the site admin and/or end-user.