Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing

[Ned Freed <ned.freed@xxxxxxxxxxx>]

> On 6 jul 2009, at 19:53, Lyndon Nerenberg wrote:

> > A message's 'state of spamminess' is an attribute of the
> > message, properly denoted by keywords that stick to (and with) the
> > message.

> That's nice in the abstract, but why do we have servers classify
> messages as spam to begin with? In order to not have to look at them,
> or to be able to look at them when it suits us to clean out the spam
> rather than in between mail that we actually wanted to receive.

Actually, the primary reason servers classify messages as spam is so they
can avoid having to deal with them. If the overhead could be ignored no
server operator would bother - spam filteringh is expensive and difficult.
The reason it's done is the alternate of receiving and dealing with the
those spam messages, with all the ramificaations, is even more expensive
and difficult.

This more than anything is why a score and not a yes/no verdict is important. A
score lets you do stuff like reject messages clearly found to be spam at the
SMTP level, while letting likely but less certain to be spam messages through
to specially designated spam folders or whatever.

> So moving spam to a separate folder is not something that happens
> because of lack of a better mechanism, but the thing that we want to
> happen 98% of the time anyway.

Sometimes yes, sometimes no.

> > $spam and $nospam

> There are more states than that:

> 1. automatically flagged as spam
> 2. automatically flagged as non-spam
> 3. manually flagged as spam
> 4. manually flagged as non-spam

> Where 1 and 2 / 3 and 4 are mutually exclusive but 1 + 4 and 2 + 3
> should trigger retraining of baysian filters etc.

It's not the flag state of the message that triggers retraining,  it's
the change of flag state (or folder locaation). Your proposal is unnecessatily
complicated.

				Ned