[Spambayes] repeatable condition where SpamBayes misses new message

[Seth Goodman]

I have background processing set to wait 10 seconds before starting and 1
second between messages.  I use the preview pane on the Inbox and things are
set to change a message from Unread to Read after it is displayed in the
preview pane for two seconds.  When a new message hits the inbox, if the
cursor was previously at the top of the Inbox (most recent message), the
cursor will move to the new message (who told it to do that?).  After 2
seconds in the preview pane, the new message will change from Unread to Read
before the 10 second SpamBayes timer delay runs out.  When this occurs,
SpamBayes neither scores nor moves the new message:  it obviously no longer
sees it as new.  This appears to be repeatable.

This explains at least one condition where SpamBayes does not get triggered
on a new message.  Since there appears to be a general problem triggering
SpamBayes exactly one time for every new message, and there is some conflict
with the Outlook rule processor, it would be *nice* if something could be
done to fix this.  Here are a few admittedly naive suggestions.  Perhaps one
of them may be useful to you.

Scenario I) When you get your "folder add event" or the start timer delay
times out, check the watched folders for messages with no spam score that
are not already on the list of messages to be processed.  This would also be
a good time to check the list for duplicate message ID's, if you still get
those.  Then process messages as usual.

Scenario II) Do the initial scoring in a POP3 proxy and put the score in one
X- header line and the classification in another X- header line.  This
insures that every message is scored exactly once.  Use an Outlook rule to
move the message into either the Unsure or Spam folders, if appropriate.
Process all other Outlook rules after this one.  Disable the incremental
training option so folder moves do not cause training and don't trigger on
"folder add events".  Use only the toolbar buttons for reclassification and
retraining.  Delete the background processing option.

Scenario III) Instead of triggering on "folder add events", run your process
as a "custom action" in an Outlook rule that runs whenever a new message
appears.  The internal mechanism for triggering rules when new messages show
up seems to be reliable.  Microsoft has provided a prototype "custom action"
called Launcher.dll that calls a designated external program with a new
message ID.  Process all other Outlook rules after this one.  Disable the
incremental training option so folder moves do not cause training and don't
trigger on "folder add events".  Use only the toolbar buttons for
reclassification and retraining.  Delete the background processing option.

The code for Launcher.dll is at

ftp://ftp.microsoft.com/services/TechNet/samples/BOES/BO/MAILEXCH/exchange/a
ppfarm/

as the file "Printex.exe".  This is a self-extractor that will expand to the
proper directory structure when invoked with "Printex.exe -d".  The
Readme.txt file explains how to get Launcher.dll to call whatever external
program you want and pass it the message ID of the new message.  It includes
a printing application (Exprint) that prints out a message for testing
purposes.


Seth Goodman