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

[Ned Freed <ned.freed@xxxxxxxxxxx>]

> >
> >
> > This is why I think folder annotations are a better bet. You mark
> > the spam
> > folder and use that marking to attach meaning to the movement of
> > messages into
> > and out of that folder. It's not perfect, but it has the key
> > advantage that it
> > works with any client (OK, any client that can use folders) once the
> > annotation
> > is in place.
> >
> > 				Ned

> I have two IMAP servers, one google, one not.

That's a problem in and of itself, because last time I looked gmail is rather
limited in its support of IMAP.

> how do I synchronize state between them.

By "state" you appear to be referring to spam filtering state. If so, the short
answer is you can't possibly do it.

> After all, If I (and I do)
> sometimes have to send from one, to reply to mails from the other
> (mail clients are bad at selecting sender account) it would be useful
> to have at least white and blacklist sender synchronization between
> them.

Sorry, that's simply not realistic. The number of different spam filtering
mechanisms in use is much too large, and the lack of semantic equivalents
across them all makes this an intractable problem.

> Or, I could be sharing explicit spam tagging information to
> improve BOTH of their tracking. Do I really have to pass the entire
> messages between imap servers?

If you want to train the server that doesn't have the message that you do,
or don't regard, it as spam, moving the entire message is the only option.

I will note that moving messages from one IMAP server to another without
having to download and upload them would be possible by relaxing the
relative URL restriction in the CATENATE extension defined in RFC 4469.

But sending misclassified messages to multiple servers is not going to get them
synchronized. Again, there are a myriad of approaches to spam filtering with
hugely different semantics. In fact it is entirely possible that you'll cause
their behavior to diverge instead of converging.

> An explicit extension/flag/keyword would be unquestionably more
> efficient use of the network.

This makes no sense at all. Setting a flag associated with a message stored
on one server is not going to be visible to the other in any way. So the
flagging approach offers no solution to the multiple server problem at all.

The folder annotation approach doesn't work any better, of course.

> And, removing the mails from the spam folder in your methodology
> implies saying 'its not spam' -so the server I move them FROM thinks
> they've been un-tagged.

No, not really. Since there's no facility in IMAP to move a message between
servers, the way you have to do it is to FETCH the message from one server and
APPEND it to the other. In constrast moving a message from one folder to
another on a single server is done with a COPY/SETFLAG sequence. Entirely
different.

> Again, I say what I said to Ijllitch: I don't like depending on side-
> effects. I think explicit messaging is better.

I don't especially like depending on side effects either, but when the choice
is between a mechanism that works with the vast array of currently deployed
clients and one that requires deployment of new client software everywhere to
stand even a chance of wortking, I'm strongly inclined to pursue the former.

Again, had we standardized flags for marking messages as spam 10 years ago, I'd
be fully in favor of using them for this additional purpose because there would
be plenty of deployed client support by now. But we didn't, there isn't, and I
don't hold out a lot of hope for _anything_ deploying with reasonable speed in
the IMAP client space right now.

				Ned