There are three system architectures for handling spam: At the desktop, at the mail server, or outsourced.
Handling spam at the desktop requires that you install anti-spam software on each PC. This can be a significant overhead unless you have an automated software distribution system. And managing and supporting, say, 1,000 anti-spam desktop installations is not a trifling task unless most of your users are smart with computers.
That said, for “power users” or small workgroups a desktop product might be the best solution. One such product I use and find very effective is Ella from Open Field Software Inc.
Mail server-based and outsourced products are easier to deploy in large organizations, but how the users interact with the anti-spam system will be crucial to effectiveness. For example, messages determined to be spam usually will be held in a folder somewhere. This raises a number of questions: How will users know if suspected spam to their address is on hold? How will they examine messages on hold and release them if they are false positives? How do users notify the anti-spam system in the case of false negatives?
And for all architectures there are management questions: Can users submit whitelists of correspondents whose messages must be passed without examination? Do the users have to submit the lists through tech support or can they manage it themselves? Can users select the auto-purge duration or is it a system-wide value?
Some systems use distributed blacklists and/or detection rules that are provided by the anti-spam system vendor or another third party. Can you define whitelists that will override the third-party blacklist? This is important because if your biggest customer accidentally gets on a blacklist you don’t want to find you’ve missed their huge urgent order because someone else thinks they are spamming!
There are the reporting considerations: You want to know how many messages were received and how many of those were determined to be spam.
Many anti-spam products are collections of different filters that together determine the probability that a particular message is spam. For example, this is the strategy SurfControl uses in its server-based product E-mail Filtering.
Another interesting approach is to not worry at all about content filtering and simply pay attention to white and black lists.
Yet another approach that doesn’t use content filtering is to verify that there’s really a human sending the message – a technique called challenge/response. These systems require unknown senders to take a test (for example, follow a link to a Web site and enter a code presented in a graphic that a computer can’t read) to release the sender’s held messages. The problem is that the testing technique often seems to irritate people because it’s too complex.
A simplified version of this approach is called source verification or, less accurately, source authentication. The idea is to hold messages from unknown senders and respond with a message asking that they simply reply. The fact that the sender replies means that he isn’t a spammer operating out of a temporary account, so the message is then released.
While this doesn’t catch the spam from clueless companies that buy junk e-mail lists to “build” business, it surprisingly appears to block maybe 90 per cent of spam!
Comment with authentication to backspin@gibbs.com.
