I can think of a couple of reasons, but don't know which actually apply:
a) because any such local tweaking is unlikely to make much difference
statistically against the larger background of data that Microsoft
already has to work with
That doesn't *tune* the spam filtering to an individual's experience
(i.e., the spams that THAT user receives). Like a Venn diagram, you
picture you small circle representing the spam that you get as fully
encompassed by the huge sampling of spam that Microsoft gets through
Hotmail. Not true. Some of your circle overlaps Microsoft's but some
will not overlap so Microsoft's filter won't catch that. Having a large
sample helps tailor an anti-spam solution but does not tailor it
specifically to a particular user's spam history. Just because
Microsoft see a huge influx of e-gold or PayPal phish mails doesn't mean
a particular user over at Yahoo Mail or at their own ISP will see them.
Domains don't all get hit with the same level or same crop of spam spew.
Saying that you probably won't fall off the cliff is no help to the user
that is currently falling. Despite how well the huge sample helps in
blocking spam, no one wants to be the statistical victim.
b) because most companies that buy Outlook/Office for their users would
rather have their users "set it and forget it" when it comes to managing
junk mail rather than worry about tuning a local filter.
If a company has spam filtering, obviously it should be used. If they
use DNSBLs to block connects for mail servers or relays, or to reject
mails sent in a session from a known IP address for a spam source, that
spam never shows up in the mailbox to then have to get deleted by
further filtering. Server-side anti-spam solutions are preferrable but
typically they end up being used in *addition* to client-side anti-spam
solutions to handle all the spam that leaks past the server-side spam
filtering. Server-side spam software can handle some spam more
elegantly then having to use the clumsy client-side solution. There is
information during the connect with the sending mail server that is not
available to the client.
Also, I have yet to see a company rely solely on the junk filter in
OL2003 (which is obviously just a client-side solution). If the company
uses server-side spam filtering, it is an extra operation that OL2003
has a spam filter. Obviously they don't want to tune the client-side
spam filters but the users can do that (i.e., it is rather easy to
distribute that workload amongst the employees who can tailor any
further spam filter on their own tastes and wants). Besides, regarding
tuning, I wasn't aware the OL2003's junk filter could be tuned. What
configuration options does OL2003 have to "tune" its junk filter? I
thought you got whatever Microsoft gave you and that was it.
Somehow I can't see a behemoth like Microsoft with its huge sampling at
Hotmail managing to keep current enough to eliminate anything but old
spam mails. After all, how often is Outlook getting updated to reflect
any changes in algorithms or heuristics that Microsoft has deemed needed
by its recent sampling at Hotmail? Outlook doesn't get updated on every
connect to the mail server. I've watched my firewall's connect logs and
when Outlook is connecting to my mail server it is not also connecting
elsewhere (but SpamPal does to get updated blacklists). Fact is, seems
the OL2003 junk filter is very stagnant and its Bayesian updating is all
that it manages to use to strive to remain current. Yet Bayesian is the
LAST technique that I would use for detecting spam; i.e., Bayesian
should be a catch-all method to detect spam with the other methods fail.
c) because the Delete button is most effective tool for getting rid of
spam and is faster than right-clicking and moving it to the junk mail
folder
Except that spam filtering should be automatic. Having to hit delete
means the user has to manual intervene and waste their time and distract
their concentration to do so. How would you like to waste hours
deleting several thousand spams sitting in your mailbox? Every mailbox
will have a maximum size if only due to the fact that there isn't
infinite disk space available on this planet or anywhere close to where
we could transmit it. Server-side spam filters can trim out the spam so
the user's mailbox doesn't end up with an unmangeable number of spams
sitting in it or consuming up the user's disk space quota so their
account becomes dead and any future e-mails, even good ones, will get
rejected with a "mailbox full" error report sent back to them. Having a
client-side spam filter that deletes the spam from the server also helps
to keep the mailbox quota from getting consumed. Unfortunately Outlook
yanks all mails and has no "delete from server" option that can be used
simply by interrogating the headers; i.e., Outlook yanks the full e-mail
to the client. But regular polling of your mailbox with client-side
deletion of spam still helps to prevent your mailbox quota from getting
consumed.
It isn't faster to hit Del than to have a spam filter tag a mail as spam
and have a rule delete it or move it to a folder (which probably should
be configured with auto-archive to delete the suspect mails after a
couple days). Why? Because YOU have to take the time to do the delete
whereas the tagging and rule operate without user intervention so you
can spend that time doing real work. You could also defrag your hard
disk using a disk editor to move around the sectors for files but most
folks prefer to use a defrag program.
I'm not sure which anti-spam program it is but I recall one that added
buttons to the toolbar that let a users to identify false positives
(mails that are marked as spam but are not spam to the user) and which
are false negatives (the spam that leaked past the filter) so they can
update the Bayesian database. SpamPal lets you do that but not through
Outlook's toolbars (because SpamPal is a proxy that will work with ANY
POP3/IMAP e-mail program, not tailored or limited to just Outlook). For
SpamPal, you use their tray icon to update the Bayesian database. Maybe
it is SpamBayes that add the toolbar buttons since it runs as an add-on
to Outlook (although it can run as a proxy for use with, for example,
Outlook Express). Letting the user tune the database based on THEIR
personal experience with spam is very important. What spams someone
else gets may not match what you get so some generic database based on a
huge sampling of users and what spam they all received may not work
effectively for any particular user. While letting the user tune their
database this way, it only helps to reclassify the keywords or artifacts
used to measure the spam for those particular e-mails and extrapolate
towards other e-mails but doesn't let you actually configure the
behaviors of the database itself (expiry, ignore list, word count used
for detection, etc.).
I will grant that most users wouldn't have a clue as to what all those
parameters will do but some will learn over time and they would have the
option of improving spam detection rather than just get stuck with
whatever the program's author decided was good for someone else or
generally for the community of the anti-spam program's users. If they
have the time to waste watching The Simpson or reruns of Cheers then
they have the time to tweak their anti-spam solution *if* it lets them
do any tweaking.
