[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing
> On Sun, 2009-07-05 at 17:40 -0700, Ned Freed wrote:
> > The obvious way to make this work in IMAP is with a standardized
> > folder
> > annotation saying "messages put in this folder were flagged as spam".
> > Then
> > moves of messages to the folder with this annotation provide the
> > server with
> > the necessary information that this message is considered to be spam
> > by the
> > user. And by the same token, moving a message from this folder can be
> > construed
> > as the message not being considered spam after all.
> This is just trying to turn a folder into a keyword, but without full
> keyword semantics.
Actually, it's a hack t work around the lack of client support, which is why
I didn't propose a keyword-based mechanism.
> The most obvious flaw is that it constrains the
> client to storing all the spam in one bucket.
If there's a reason multiple folders can't be marked this way I sure don't
know what it is.
> It doesn't allow for (say)
> sorting junk by type into different folders (perhaps on different
> servers). A message's 'state of spamminess' is an attribute of the
> message, properly denoted by keywords that stick to (and with) the
> message.
I see no reason why this couldn't be done, if you really want to.
> If you want this functionality (and I think it's a useful service for
> servers to provide) you need to implement two keywords: $spam and
> $nospam (these are just example names). Setting $spam on a message would
> instruct the server to pass the message off to the filtering component
> as spam; setting $nospam would instruct the server to pass the message
> off to the filtering component as valid (non-spam). The two keywords are
> exclusive, and it would be up to the server to decide what action to
> take if the client tries to light up both at once (e.g. unset the other
> flag and take the corresponding action, reject the command, or silently
> ignore the request).
Again, the problem with using keywords is now you have to get a significant
fraction of clients on board before it's useful. I'd be willing to go along
with a keyword-based approach if I could convinced that's going to happen, but
everything recentlts has supported exactly the opposite conclusion.
Ned