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

From: John J Lee (no email)
Date: Mon Sep 04 2006 - 10:42:37 EDT

  • Next message: (no email): "Cyrus server problem"

    On Mon, 4 Sep 2006, Kjetil Torgrim Homme wrote:

    > 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.)

    Aha! Thanks. If anybody has any pointers to sample client code, I'd be
    grateful.

    Still, the old-style SpamBayes code should also be fixed for
    non-flags-capable servers -- see below re Courier (and it'll take me a
    while to get around to attempting to implement the flags-based version).

    >> 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.

    OK, I was mistaken about the reason is does this loop. The loop is there
    not to find the UID (the code does indeed do a SEARCH for that), but
    rather to wait until the new message is available, prior to SEARCHing for
    the UID.

    Does that make more sense, or is there still a better way to do it?

    >> 2. Does this reveal a bug in the Cyrus implementation?
    >
    > hard to tell. is it the only client?

    I don't understand your question. Is SpamBayes the only client of Cyrus?
    No. Did you mean "is Cyrus the only server that fails with this client
    code"? Seems not: somebody reported Courier failing intermittently too.

    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
    

  • Next message: (no email): "Cyrus server problem"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD