mwos said:
Can the spam filter with Outlook 20003 operate with Spam Inspector,
now a Microsoft product? I ran Spam Inspector for a number of years
with Outlook 20002 not using Outlook's spam definitions. I just
upgraded to Outlook 2003, and so far like its spam filtering based on
Outlook's 2003 definitions. I still have on the computer Spam
Inspector 4.0, and I am curious if both spam programs will act in
harmony or will I have a conflict in the spam removal programs
possible causing one or both to cancel out?
Outlook 2003's spam filter is a Bayesian filter. That's it. You get
one method to detect spam which has to learn over time what is good and
bad e-mails. A fixed list is included to pre-train their Bayesian
filter which is based on common spam that Microsoft includes in their
list, but this list is not based on YOUR experience with spam, so the
database weighting does not reflect the spam that you got but the
pre-training list that Microsoft included. Does OL2003 even let you
switch an e-mail from bad to good, and visa versa, to enforce learning?
Since it is the only anti-spam method, it cannot learn from other
methods since there are no other methods (and it won't learn from your
rules).
Spam Inspector is a semantic anti-spam filter, and not that good at
detecting spam. Atop of other filters it will further reduce some spam
but also at an increase in risk of false positives. If you are looking
to increase the effectiveness of spam filtering, and rather than paying
to get Outlook 2003 (just for its Bayesian filtering) or using Spam
Inspector, you can get SpamPal and its plug-ins for free and which are
as, or more, effective than what you have now. SpamPal is freeware, not
bannerware, adware, trialware, demoware, or any of that crap. It's
developed by altruistic authors bent on eliminating spam. You can
donate if you want but it's not required. While Microsoft will be
developing and improving the AntiSpyware product (they got from Giant),
I'm not sure about the survivability of Spam Inspector, especially when
there are other much better solutions available. A search on "Spam
Inspector", exact phrase, at search.microsoft.com turns up no matches.
I never did find the GiantCompany products to be that potent, anyway. I
do use MS AntiSpyware but Prevx is better (the Home version is free)
except it isn't for newbies or lazy users, but neither are anti-virus,
anti-spyware, firewall, or other anti-intrusion/malware products.
Although Microsoft bought out GiantCompany, their web site still exists.
So head on over to giantcompany.com and check their support pages. For
example, and with just a few mouse clicks, I found
http://www.giantcompany.com/commonQuestions.htm#si_emailClients where
OL2003 is listed as supported. As to how long Microsoft will continue
providing updates, there's no info on that. I don't expect Microsoft to
waste their time on the popup blocker product, and I also expect Spam
Inspector will die as soon as all the 1-year subscriptions expire from
when Microsoft bought GiantCompany (so figure it might die around
December 2005, which is only about 4 months away).
SpamPal runs as a local proxy that is usable by *any* POP3/SMTP
complaint e-mail client. It has a Bayesian filter plug-in. It can be
pre-trained using good and bad lists of e-mails (to reduce training time
and reflects the history or e-mails that YOU have received, not the
presets included by Microsoft). You can change an e-mail from good or
bad in case it guessed wrong (there are ALWAYS false positives and false
negatives with Bayesian filters). It can learn from other anti-spam
methods: if a spam is detected using the public blocklists, MX plug-in,
RegEx plug-in, country blocklists, or other methods, then the Bayesian
filter will also learn what is spam from them, too. Fact is, the other
methods are more accurate so only when a spanking new spam appears might
the Bayesian filter catch it; i.e., the Bayesian filter provides a
catch-all filter should a new spam leak by the other methods. Unlike
the Bayesian filter in OL2003, you can adjust the "floor" or noise level
in the SpamPal Bayes plug-in which eliminates rarely-used words based on
an expiry that you can configure. Remember seeing all those e-mails
with lots of prattling at the end (and where the spam was contained
within a GIF image that the Bayesian filter would never see, anyway)?
They are trying to poison Outlook's Bayesian filter. Those have no
effect on the SpamPal Bayes filter unless you set the expiry to some
ridiculously long interval. I think the default expiry in SpamPal's
Bayes plug-in was around 10 or 14 days, but I set mine higher to 30 days
since my volume of e-mail is not that great (the higher your volume the
shorter the expiry should be set to prevent poisoning). I can also
configure how many keywords are extracted from the message, which words
to ignore (beyond the preset list that can still be edited), mininum
word length (default is 3 characters), and other options which simply
don't exist for the Outlook 2003 Bayesian filter; i.e., you can tweak
the Bayes filter based on your volume of e-mails, degree of spam, and
other factors regarding YOUR personal experience and history rather than
presets defined by Microsoft (but some of the aforementioned functions
aren't even alluded to in Microsoft's obtuse description of their spam
filter which attempts, in vain, to avoid identifying itself as a
Bayesian filter).
The MX Blocking (Direct to MX Blocker) plug-in will detect e-mails that
originate from sender's with dynamic IP addresses, which would be
dial-up and cable/DSL users that are infected with a trojan mailer
daemon. Some users runs their own mail servers (which might violate
their ISP's terms of service) so they have a dynamic IP address unless
they pay to get a static IP address. They might use DynDNS.org or
No-IP.org to get a static IP name associated to them but they are still
using a dynamic IP address to spew out their e-mails. I haven't seen
anyone sending me e-mails from dynamically assigned IP addresses other
than spam coming from infected user hosts. The MX plug-in does use an
obsolete DUL (dynamic user list) so I changed its config file to use a
newer and maintained one: edit "C:\Documents and
Settings\<youraccount>\Application
Data\SpamPal\plugins\mxblocking\config.dat" from:
MXEASYN YES dialup.ip.dynablock.easynet.nl 127.0.0.2
to
MXEASYN YES dul.dnsbl.sorbs.net 127.0.0.10
The plug-in doesn't provide an interface to let you edit the settings so
you have to edit the config.dat file. Basically you redefine the
hardcoded but obsolete MXEASYN entry to point at the SORBS DUL list.
Greylisting would be far more effective in eliminating the spewage from
infected user hosts but it must be implemented at the mail server and my
ISP doesn't provide greylisting as an option; see
http://www.rhyolite.com/anti-spam/dcc/greylist.html,
http://users.aber.ac.uk/auj/spam/greydesc.shtml.
The public blocklists are lists of known spam sources but some are more
aggressive than others, and some, like SPEWS, don't actually list spam
sources but rate an e-mail provider or domain regarding their spamminess
and their willingness to deter spam. Start out with the SpamHaus
SBL+XBL, NJABL, ORDB (which is really an open-relay list rather than a
spam source list), and SpamCop. The SORBS list is okay but often its
records are 3 months old, or even older, so sometimes they are just
plain wrong as they aren't current. I'm still using SORBS but am on the
edge whether I will continue to use it or not (I'm watching for the
number of false positives and how old are their records for them). When
my dynamic IP address changed (I have cable broadband which doesn't
change often but does occasionally), I got on the SORBS list because the
prior user of that IP address got blacklisted, so I got blacklisted when
I got assigned that IP address by my ISP's DHCP server. Their record
was over 3 months old but they were responsive and fixed their list the
next day after I sent them notice.
The HTML-Modify plug-in eliminates nasties in HTML-formatted e-mails.
If you set your e-mail client to use the Restricted Sites security zone
(and if that zone is set to its default High level) then most nasties
are eliminated, but HTML-modify takes care of a few more. For example,
you can configure it to change any attachment with an executable
extension (if you have configured Outlook to not block it) by adding
..txt to the filename. This makes it impossible for you to accidentally
open the file without first having to save it, rename it, and then run
it, and if you went through all that then it was YOUR deliberate choice
to run that attachment. It can also rate a message regarding spamminess
depending on the level of use of invalid HTML tags, like using
<SEX-VIAGRA>, which will display within the message because they cannot
be used in rendering the message's format, deobfuscate URLs for web
sites linked within the message, and check for no alternative text part
in an HTML-formatted e-mail (Hotmail does this but spammers do, too,
because they don't want you to see their message without all the
formatting, especially to hide the real target of URL links). None of
the security zones will block linked images but HTML-Modify can be
configured to rename the HTML tag so the image won't display so web bugs
cannot be used to track you opening an e-mail. Most e-mail clients
already have that option (to block external web content, like images)
but many still don't.
The RegEx plug-in lets you define rules to detect spam that go far
beyond what you can define using the rules in your e-mail client. It
gives you the power of regular expressions in detecting spam or
otherwise handling your incoming messages. The blocklists, Bayesian
filter, MX filter, and HTML-Modify have been so successful in removing
spam that I've never felt a need to use the RegEx plug-in. I don't need
to waste the extra high-level of effort in programming special-need
regular expressions just to get rid of the 1 or 2 spams per day that
leak past all the other filters. I've never bothered to investigate how
the RubyExec plug-in works mostly because my level of spam has decreased
enough not to bother with more filters.
The Logfile plug-in lets you keep a text-only copy of any message that
was tagged as spam by SpamPal or any plug-in. This comes in handy when
there was a false positive. I use a mail monitor that provides rules so
that I can delete spam-tagged e-mails from my server. The spamm never
reaches my computer, I don't waste time and bandwidth downloading it,
and I don't ever have a local copy of it to then delete. However, there
are always false positives, and the logfile lets me recover. Plus I can
use that text-only copy to submit when reporting the spam, like when
reporting it via SpamCop. The only defect with that plug-in is that it
does not have an auto-expiration function to get rid of old spam-tagged
copies of messages, so I wrote a batch file that should still be
available on the plug-in author's web site. It deletes the folders
based on how old they are (which you can specify in the command line to
run the batch file). I then add it as a scheduled event in Task
Scheduler to periodically clean out the old plain-text copies of the
spam suspect e-mails.
I haven't used the Bonded Sender plug-in. Bonded senders pay to have
their e-mails delivered (i.e., they pay to prove they don't send spam,
and get charged if they send spam). See
http://www.bondedsender.com/.
Basically it provides a trust rating for a sender.
The P2P (peer-to-peer) plug-in uses the concept that users vote on
whether a message is spam, or not, and that vote gets registered in a
database that other users can use. If enough votes mark the message as
spam, and votes are biased based on your trust/experience rating, the
message is deemed spam. Other users receiving that message will then
have it tagged as spam and can handle it accordingly. It is similar to
other voting schemes used to identify spam mails, like Cloudmark's
SpamNet (which used to be free, was apparently a beta test which they
never identified to their users, they renamed it when all the kinks were
ironed out at the expense of their users, and then they charged for it
without discount to their customers that helped them iron out their
service). Again, the blocklists and other filters that I use have been
more than effective enough to lower the amount of spam so it is way
below my irritation threshold. In fact, I use the Logfile plug-in to
let me report spam that would otherwise never have shown up in my Inbox
(i.e., I want to report spam that wasn't detected using the blocklists
and have to do an end-run around SpamPal to get them to report them).
