[Spambayes] using external DNSBL's with Outlook

[Tim Peters]

[Seth Goodman]
> ...
> Before installing SpamBayes, my POP3 email went through the following
> processing hierarchy (as far as I know):
>
> 1) anti-virus filters email coming in on port 110
> 2) POP3 proxy checks header IP addresses against external DNSBL's

The Outlook plug-in doesn't use a proxy.

2') Outlook sucks the email of your POP3 server, and stores it in
    its own internal format.

> 3) Outlook2000 processes message rules
>
> The FAQ talks about a POP3 proxy component, but I don't think this
> applies to the Outlook plug-in.

That's right.

> How does the SpamBayes Outlook plug-in fit in with the above
> processing hierarchy?

Somewhere around #3.  In particular, your POP3 server is history by the time
the plugin sees a message.  Indeed, it's difficult for SpamBayes to try to
reconstruct the bytestream your POP3 server originally delivered (step 2'
turns it into quite a mess).

> When exactly does SpamBayes get to work on a message?

Heh:  nobody knows.  The Outlook rule system isn't strong enough to allow
plugging SpamBayes in as an Outlook rule, so instead SpamBayes hooks Outlook
"folder add" events.  Exactly when and why Outlook triggers one of those
events isn't documented by Microsoft, and appears to vary wildly depending
on Outlook version and system load.  Sometimes SpamBayes appears to see a
message before Outlook rules run, sometimes after they run, sometimes we
don't get notified about a new message at all, and sometimes we get notified
about a new message more than once (e.g., if an Outlook rule moves a message
and SpamBayes is set to watch both the Inbox and the destination folder, we
*might* be told about a message twice).

> There is some mention in the FAQ about "fighting" between SpamBayes
> and the Outlook rule processing, and suggests that the background
> filtering option will fix this.  How does the background filtering
> option affect the processing order?

It slows SpamBayes down a lot, under the empirically verified theory that
Outlook rules will more-than-less reliably run first then.  There's no way
we know of to make SpamBayes reliably run before Outlook rules run.

> What point in time are the processing delays in the control panel for
> background processing referenced to?

Stick the cursor inside one of the "seconds" boxes and hit F1.  A balloon
will pop up explaining what the value in that seconds-box controls.

> There is also mention in the FAQ about an "incremental" training mode
> where all the incoming mail is included in the database.  Is this the
> default processing mode?  If not, do you recommend this and how do I
> enable it?

That's not relevant to the Outlook plugin.