Recently-APPENDed messages not showing up as RECENT responses after NOOP

[Kjetil Torgrim Homme]

On Sat, 2006-09-02 at 15:48 +0000, John J Lee wrote:
> The problem occurs when SpamBayes (specifically, sb_imapfilter.py) tries 
> to add an X-Spambayes-Classification header to emails it has classified, 
> in order to record whether it thought the mail was spam or not.  It does 
> that by creating a new message with the added header, then deleting the 
> old message (if there's a better way, I'd be grateful to learn about it). 

oh yes, please use flags!  Cyrus supports arbitrarily chosen flags by
clients, see PERMANENTFLAGS.  (of course, other IMAP servers aren't as
advanced, so you may want to keep this wasteful APPEND/STORE/EXPUNGE
hack around for those.)

> As soon as SpamBayes creates the new message, it tries to find the new 
> message's UID.  To do that, it first looks for a RECENT response.  If it 
> doesn't have one it its buffer, it sends a NOOP command.

you can't trust RECENT, if a different client is connected, your
SpamBayes client may not be told about the message, since only one
client will be notified.

> If that doesn't 
> result in a RECENT response, it keeps polling, issuing NOOP commands up to 
> 100 times (it doesn't sleep() between each poll).  If that fails, it dies 
> horribly :-/

this is really unnecessary.  when the APPEND is done, SpamBayes can
simply do a SEARCH to find the message with the Message-ID and fetch its
UID.

> So, two questions:
> 
> 1. Is the algorithm above a sane one?  Maybe I should ask instead "is
>     there a better one"?
> 
> 2. Does this reveal a bug in the Cyrus implementation?

hard to tell.  is it the only client?

>     If not, might it
>     be a useful extension of Cyrus IMAP to support this kind of usage?

in my opinion, no.  RECENT will never be a good basis for this kind of
stuff, it's mostly useful for a quick peek at what's new on a limited
device, e.g. a mobile phone.
-- 
Kjetil T.