IronPort's idea is that large e-mailers with legitimate business needs can post a bond, the size of which is determined by the amount of mail being sent. ISPs and corporations that subscribe to IronPort's whitelist allow all mail that has been bonded through to their users. Spam complaints about those messages generate fines that are paid from the bond. The more complaints, the more money comes out of the bond piggy bank. Where do the fines go? According to IronPort, they are donated to nonprofit antispam organizations.
|
FYI
On Jan. 2 a state appeals court upheld a 1998 California law that requires e-mail advertisers to identify their messages as such and to provide ways for consumers to remove themselves from the advertisers' e-mail address lists or face a $1,000 fine (see "State Cour of Appel upholds Bowen's Anti-Spam Law")
|
Ingredient 3: Varietal Filters
Besides you and your users hitting the delete key hundreds of times daily, your last line of defense is filtering software. We break this category down into three distinct groups: client-based filtering, server-based filtering and outsourced filtering.
The client-side products generally plug in to your e-mail client, usually Lotus Notes or Microsoft Outlook or Outlook Express, or connect directly to your MAPI or POP3 mailbox. These products are based on an updatable list of client-side rules that filter based on sender, subject or an analysis of content. Two packages in this category that we looked at while preparing this article were McAfee.com's SpamKiller, which works with any MAPI or POP3 account, and Sunbelt Software's aptly named iHateSpam, which works with Outlook in MAPI, IMAP or POP3 mode or Outlook Express in POP3 or IMAP mode. These packages run $20 to $30 and don't consume any server resources. Additionally, each user can customize the product to his or her heart's content. The downside is that your mail server still has to process and deliver each piece of spam, your users' ability to roam from one computer to another is severely limited if they want their spam processed, and you've now distributed your support issues to each user's computer.
During our use of both of these products, we found that some legitimate mail was moved to the spam folder while some spam slipped through the cracks. The result of this less-than-perfect accuracy was that we ended up examining each message anyway, which somewhat defeated the purpose of the product. The benefit was the timing--because the messages suspected to be spam were moved to a separate folder, we could examine them during work lulls or in the evening, giving us more time to deal with legitimate mail during the day. In addition, these products "learn," so their performance improves over time.
Server-based filtering products run the gamut from commercial software, such as Brightmail's AntiSpam, Vircom's VOP modusMail and SurfControl's E-mail Filter for SMTP/Exchange, to the freely available, PERL-script-based SpamAssassin, to outsourced solutions such as Postini's Active EMS. These products are more sophisticated versions of their client-based brethren, operating on e-mail as it enters the server rather than after it is delivered. If you implement a server-based product, your users are freed from the responsibility of managing their own antispam measures, and support issues are centralized.
Before you start with one of these products, make sure you can tailor its spam-filtering activities for various user groups. Your sales folks may want to receive all their mail unfiltered--the cost of their missing an important message due to a false positive can be high--while your engineers may want to filter 110 percent of their mail. In addition, these products require the most CPU cycles of any of the antispam measures we've discussed because they examine each and every message--including headers, contents and attachments--before they pass them on or reject them.
Which brings us back to our original point: If a relatively inexpensive DNS lookup can reject a majority of your inbound spam before the workhorse, server-based filter products start eating your CPU cycles, your entire e-mail infrastructure will benefit from greater scalability. And considering that spam is projected to increase at a rate of 100 percent per year for the foreseeable future, scalability is a critical concern.
Send your comments on this article to Ron Anderson, lab director at Network Computing, at randerson_nospam@nwc.com (humans remove the _nospam, robots need not respond). Oh, and Spam is a registered trademark for a pork product, packed only by Geo. A. Hormel & Co., Austin, Minn.
RSS
