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