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). 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.
[...]
With more tweaking, such an implementation would be a bit more
user-friendly, and can stand as a guide as to how you might spec out
what the junk/unjunk button "means", and leave actions to the
implementation.
I cannot help distinguishing between IMAP and POP3 here. For IMAP,
synchronization of Bayesian data among several servers and clients may
be viewed as a generic distributed database problem, possibly
complicated by an amount of fuzziness. It is possible to send an abuse
report as a consequence of particular user's actions; it is just
similar to "move marked junk to junk folder".
It's an implementation _convenience_ (for IMAP). Nothing more.
There is nothing preventing you sending your Bayesian data out-of-band
to the server, nor, keeping it local for client-based filtering (as in
Thunderbird).
Heck, SpamAssassin even manages to tune Bayesian without having any
end-user feedback at all.
For POP3, there are no folders.
Perhaps no server-visible folders, but there are folders none the less
in most (if not all) POP3 reader implementations.
That's what makes that definition
difficult. Users can look for X-Spam-* headers only after they've
already downloaded the message.
This is moot. Most filters these days don't bother making "clearly
spam" visible at all to the end user or mail reader, and the X-Spam-
headers (as in the SpamAssassin sense) don't exist. It's only in
marginal cases where the user has to see the email to decide whether an
email is spam or not that the X-Spam headers will be worth while.
Which, in the case of POP3, means they have to download the message
anyway to make that determination.
In case servers maintain _per-user_
Bayesian data --as they should-- the whole idea of filtering on the
servers seems rather pointless.
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.
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg