You may want to look again at the subject line.
I'll make it more clear:
*Right now* I'm running XP32.
*Soon* I'll run XP64 with the 64-bit version of Outlook Express... UNLESS
you are telling me the XP64 Outlook Express is 32-bit?

More clarification: I don't care if the spam-catcher is 32-bit or 64-bit. I
just assumed that it would need to be 64-bit or at least compatible with
whatever Outlook Express runs on XP64.

Finally, I think you are splitting hairs with the whole "integration" or
"plug in" thing.
More clarification: I'm currently using Cloudmark and I want something that
works like it does.
The way Cloudmark plugs in (or whatever you want to call it) to Outlook
Express is the way I want the next spam-filter to work. Since you have
yourself used Cloudmark, I'm sure you can now understand what I'm looking
for.

Regarding webmail and my provider, I'm the provider. I run the mail server
and I don't want (for reasons I'd rather not waste time explaining) to run
spam filtering software on that box.
--
Scotter
Tyan Thunder K8WE
Dual Opteron 252s (2.6ghz)
4 gig Corsair XMS DDR400 RAM
XFX 7800 GTX 256 w/VGAsilencerV3
500 gig Hitachi SATA 300
160 gig Seagate SATA 150
Dual Dell 24" wide aspect LCDs
550W Antec power supply
X-Fi Platinum Soundblaster
-
"Vanguard" wrote in message
...

So why won't a 32-bit app work for you? I highly doubt that any extra
speed would be afforded by a 64-bit app that has to interrogate the
packets going to your e-mail client (which is probably also still a 32-bit
app, especially since you mention Outlook Express). Since you are running
Windows XP Pro, which is 32-bit, you can't run 64-bit software on it,
anyway.

Please explain how any program can report a mail that it didn't catch was
spam (i.e., a false negative). If the program didn't know it was spam,
how would it then know it was spam to report that it missed it? If it
knows it is spam, it would catch it and not have to report a miss to you.

Outlook Express doesn't support plug-ins as does Outlook. Of those
programs that "integrate" with OE, they look to run as "wrappers". That
is not an effective method of detecting spam and makes the spam filter a
one-product solution which would have a severely restricted number of
users for that product. I use SpamPal which runs as a local proxy which
interrogates your e-mail traffic. It commits no action against the spam.
All it does is tag the spam and then you create whatever rules in your
e-mail program that you want for however you want to handle the spam.
SpamPal's main method of detecting spam are DNSBLs (DNS blacklists = IPs
of known spam sources). However, you can add the Bayesian plug-in to help
guess which mails are spam that may not get detected by DNSBLs (and the
SpamPal Bayesian filter can also learn from other spam detection methods
to help update its database). So the Bayesian filter would find the spam
that the DNSBLs missed. It also has a UserLogfile plug-in that keeps a
plain-text version of spam-tagged mails so you can recover in case of a
false positive (a good mail marked as spam).

For SpamPal, I have my rules first look for SpamPal tagging them using the
Bayesian filter (which means the spam wasn't in the blacklists). Those I
move (marked as read so the folder doesn't get bolded to show new mails
are there) into the Junk folder which is configured with auto-archive
enabled to permanently delete them after 2 days. Bayes is a guessing
scheme and it will have false positives. The next rule checks if
SpamPal's HTLM-Modify filter detected spam. It scores the HTML-formatted
mails on their spamminess and if they use any tricks plus it can remove
some HTML tricks. Those also go into the Junk folder, too. The 3rd rule
just check if SpamPal tagged the mail as spam and, if so, permanently
deletes it (and why I use the UserLogfile plug-in to keep a plain-text
copy in case of false positives - which do occur). Be careful as to which
blacklists you enable in SpamPal. Some are aggressive, and some are
totally inappropriate for personal e-mails (they rank the spamminess of a
domain and do NOT actually identify specific spam sources).

Have you checked using the webmail interface to your e-mail account if
your e-mail provider includes a spam filtering option? If so, enable it.
Even if they are "loose" (lots of spam leaks past), it is still better to
have some server-side spam filtering than none at all. If their spam
filtering is too tight (causes too many false positives) then you might
consider disabling it so you can use a customizable client-side solution,
like SpamPal. You can use server-side spam filtering and SpamPal
(client-side) together, too.

I did use (now called just Desktop) SpamNet from Cloudmark when it was
free, or so Cloudmark professed it was free. When Cloudmark had gained
enough experience, enlarged their spam ID database, and tweaked their
system enough, all of sudden all of the free accounts got reclassified as
beta test accounts when Cloudmark pulled the rug out and went commercial
with their service. They never divulged to the users of the "free"
accounts that they were actually beta testers and that Cloudmark had its
eye on generating revenue from the spam problem. I wasn't interested in
paying Cloudmark and I didn't like the way they lied to their users about
their intent for their service. I liked the concept of a voting scheme
but, in practice, it turned out it wouldn't catch a lot of the spanking
brand new spam (because not enough users got it yet to vote on it, so your
voting was to help someone other than yourself).

--
__________________________________________________
Post replies to the newsgroup. Share with others.
For e-mail: Remove "NIX" and add "#VN" to Subject.
__________________________________________________