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. ---- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
