[Spambayes] Re: Outlook plug-in - when *exactly* does the message get changed?

David Bolen db3l at fitlinxx.com
Fri Jul 11 19:02:56 EDT 2003


"Jon Skeet" <jon.skeet at peramon.com> writes:

(...)
> We had expected that SpamBayes would mark the message as soon as it
> came in, which would mean the window where the notification server
> could see it before it had been marked by SpamBayes would be very
> short - but it seems this doesn't happen. It's almost as if a
> message is marked when the *next* message arrives, or something
> similar. Given that various things (like poking the IMAP server or
> refreshing Outlook) could trigger SpamBayes, we're in a sort of
> quantum situation - we can't diagnose what's going on without
> possibly screwing up the results. Some more definitive information
> would be very much appreciated!

It's just a guess, but this could related to an Exchange server
interaction problem that causes many of us to see a message show up
again as unread even though we've read it.  There's an open bug on it
at SourceForge, but I don't have the number handy (it's probably
searchable by using "unread" since the problem was messages reverting
to an unread status).

What seems to happen is that even though SpamBayes is telling Outlook
to update the message status, that action gets delayed for some reason
within Outlook itself.  Typically the update then occurs when the user
performs the next operation in Outlook or some other Outlook event
occurs (such as a message arriving).

So for example, a new message may come in and you open it up to read
right away.  You can be watching your summary pane and the message,
and the summary pane will never show the Spam field update.  But once
you close your message it'll suddenly update.  I'm just guessing but
perhaps that's the same delay you are seeing on the server side, and
the gap is how long a particular user takes to have a new event in the
client, thus flushing the request back to the server.

The confusing part is that SpamBayes is already trying to tell the
server to make the change (not queue it up).  The bug report on
SourceForge has a patch (hack) that I did to the filter module
(effectively making a change twice) that works for almost all of my
users (except for one with a slow laptop, so its probably a timing
thing in Outlook).  Mark tried something else I think in the 03
version of the binary but it didn't work as well for me.  The change
is crude but if you were willing to run from source you might try it
just to see if it impats the behavior you're seeing.

This seems limited going against an Exchange server, which at least in
the past has been a minority of Windows SpamBayes users.

-- David




More information about the Spambayes mailing list