[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IMAP extensions needed for SPAM/HAM and WHITE/BLACK listing
Hi Ned,
--On July 7, 2009 7:22:42 AM -0700 Ned Freed <ned.freed@xxxxxxxxxxx> wrote:
> Now suppose I implement this with folder annotations. I'm in business
> immediately. Things just work no matter what client people use.
Actually you need to consider what the user experience is likely to be on
the client side. There are several things to consider: for spam messages
users will typically want to delete them from their regular mailbox. With
ham messages they will typically want to leave the message in place (or
file them away after processing). In each case I certainly would not want
the spam messages or an extra copy of the ham messages to reside on my
server consuming quota or other resources, or being indexed as part of a
server-wide search etc.
With that in mind lets look at how each solution might work client-side:
1) Keywords: for a spam message the user sets the spam keyword, then sets
the deleted flag (and then may explicitly expunge if the client has that as
an option as opposed to hide-deleted-messages with lazy expunge). For a ham
message the user just sets the ham keyword. i.e. two user operations for
spam, one for ham.
2) Mailbox (I am going to assume that the client has both a move and copy
command available - the former implicitly setting the delete flag after the
IMAP COPY command): for a spam message the user moves the message to the
spam mailbox. For a ham message the user copies the message to the ham
mailbox. NB both of these assume that the server does not actually store
the spam/ham messages in the spam/ham mailboxes (or perhaps it garbage
collects them).
Things to note: typically clients don't offer shortcuts "move to mailbox X"
or "copy to mailbox X" so the mailbox operations will involve some drag and
drop or menu list selection operation. The same may be true for setting
arbitrary keywords (though Mail.app and I suspect Thunderbird do have
buttons for this). Frankly the best user experience would be for the client
to have spam/ham buttons and commands that would allow the user to do the
appropriate actions in one click or keyboard shortcut operation - that is
certainly important if the level of spam is moderate to high.
The presence of spam/not-spam buttons in existing clients is an important
factor I hadn't really considered, but I think it has implications that go a
lot further than you let on here.
Simply put, if enough popular clients already have such buttons, and those
buttons do different things in different clients, I think we're pretty much
screwed. Given the presence of such buttons you're not going to be able to get
users to do something different to deal with spam, whether it's adding a
keyword or annotation or performing a folder move.
Our only recourse with such clients in the mix is to write a specification for
what such buttons should do in terms of signalling the server and then hope
that clients actually adopt whatever that specification says. And frankly, if
there's some degree of commonality in what those buttons do in existing clients
and it can be made to work, we probably should adopt that approach no matter
what it happens to be.
So at the end of the day, for the best (and frankly simplest) user
experience clients do have to change for both the keyword and move to
mailbox approaches. Now for keywords that change does have to be immediate
if arbitrary keyword support is not already present in the client, whereas
for move to mailbox, or clients already supporting keywords, that change
can be done over time - though as Ned points out client changes tend to
happen on geological time-scales!
I agree completely that a keyword-based approach has the potential to offer
a better user experience. The question is whether the possibility of offering
a better user experience at some distant point down the road is worth giving
up on a more immediately deployable solution.
But as I indicated above, now that you've brought up the important point of
existing clients having spam classification buttons, that's the real gorilla in
the room we have to deal with.
So other approaches to consider:
1) An extension with commands SPAM and HAM to explicitly tag one or more
messages.
2) A "forward to spam/ham" option that specifies special email addresses
for the user where spam/ham can be forwarded to trigger training.
I believe this is what the buttons I've seen on at least a couple of
clients already do. If that's indeed the case, it's worth considering.
3) An IMAP URL handed off to the SPAM system with URLAUTH to allow that to
pull details of the message for training. (This could be tied to (2) in
that forward-without-download could be used in (2) with URLAUTH etc).
These of course all require new client/server behaviors and thus are
probably non-starters, but they should not be dismissed entirely.
I'm actually not sure (2) does with all clients, but I agree regarding (1) and
(3).
Ned