Re: [Asrg] Summary of junk button discussion

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

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.