Next message: John J Lee: "Re: Recently-APPENDed messages not showing up as RECENT responses after NOOP"
Hi
I'm trying to figure out why a Python spam-filtering program, SpamBayes,
crashes for me when running in IMAP client spam-classification mode
against a Cyrus IMAP server, version "Cyrus v2.3.7-fmsvn9188" (the server
is one of the mail.messagingengine.com ones from fastmail.fm).
I should say upfront that I imagine it may well be that the fault is with
SpamBayes. TBH, the reason I'm posting here is that a). it's clear the
SpamBayes issue will only get fixed if I do it myself, and b). I've little
doubt that any fix I come up with without the help of an IMAP guru would
be a pure hack, a server resource hog and not work for other people.
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).
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. 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 :-/
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? If not, might it
be a useful extension of Cyrus IMAP to support this kind of usage?
Thanks in advance for any help
John
----
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
