"People have to understand that SPF is an antiforgery implementation, not an antispam solution," said conference attendee Mark Ramos of Granite Software. "It plugs a hole that has been exploited by spammers and virus writers alike. What I really like about SPF is that it can be quickly adopted, because it uses existing infrastructure elements to fix that hole in the e-mail infrastructure. The resistance to SPF is understandable, given that existing systems such as listservs, ecard, and 'send-to-friend' Web implementations rely on the ability to spoof a sender e-mail address. Change is difficult, but I think the benefits outweighs the risks." You can find out more about SPF at http://spf.pobox.com.

Representatives of several other companies offering antispam solutions attended the conference, including BrightMail and CipherTrust. Apart from a familiar face or two, however, this conference had little in common with the types of events the Lotus community is used to. Everything took place in one room, with no breakout tracks and no hour-long sessions. Nineteen presenters each had a 20-minute slot, including the question and answer time.

Legal issues

Two presenters dealt with legal issues, including the new U.S. CAN-Spam law, two presenters dealt with economic approaches to spam (so-called "sender-pay solutions"), two presented statistical analyses of spam traffic patterns, and the rest of the speakers dealt with specific antispam technologies. SPF was only one of several subjects that generated spirited disagreement. Some of the presenters came close to having completely opposite conclusions. For example, the two presenters who covered legal issues offered dramatically different interpretations, one guardedly optimistic and the other quite pessimistic. One area of technical disagreement was the volatility of spam content. One presenter showed a statistical analysis of SpamAssassin results on a large archive of spam from a single mailbox over several years and demonstrated that no more than 14 percent of the variance in detected characterstics of spam was correlated with the passage of time, whereas several other presenters took the conventional wisdom that spam is a fast-moving target as a premise of their talks.

Antispam technologies

Many of the presentations dealt with Bayesian filtering, also known as adaptive statistical filtering. This has been the hottest topic in spam research for most of the past year and a half. The open-source kSpam project (http://www.openntf.org) is one of many Bayesian filtering options available, and it's the only one that's fully integrated with Lotus Domino. Bayesian filters analyze the differences in frequency of word occurances in spam and non-spam messages, and use this analysis to calculate a spam probability score for new messages. The prevailing view of many at the conference was that Bayesian filtering is still only a client-based technology, too CPU-intensive for server implementation in an enterprise setting, but two presentations challenged this assertion.

A variation on the Bayesian theme came in a presentation on Bayesian whitelisting. Whitelists have emerged as an important part of antispam technology. All spam filtering techniques are somewhat expensive in CPU time, and the best techniques can be quite expensive. The purpose of a whitelist is to detect non-spam messages quickly to bypass as much of the expensive processing as possible for as many messages as possible. Some existing products already build their whitelists automatically. The problem with whitelists is that spammers try to get around them by forging From addresses that make their messages look like they came from a friend. Viruses and worms also frequently appear to come from friends. The idea behind Bayesian whitelisting is to do a statistical analysis of all the addresses that appear in headers of good e-mail messages to detect patterns that go beyond simply identifying trusted senders. For example, a Bayesian whitelist might result in a decision to whitelist all messages from a particular sender that include a CC: to a particular recipient, but to do the expensive spam checks on messages from the same sender that don't include that CC: recipient.

Another theme that came up in several presentations was "inoculation," which refers to sharing data about known spam across multiple servers in near real time. Vendors of Domino-based antispam solutions will probably take advantage of replication to inoculate servers within a Domino domain, but in multi-vendor
e-mail environments this won't be enough. The good news at the conference was that a standard for exchanging inoculation data between different antispam
systems is in the works.

Of the many different technologies presented at this conference, the one IBM should pay the most attention to is SPF. Controversial as it may be, it's gaining the acceptance of many major ISPs, and some Domino customers are going to want to be able to check SPF records during receipt of SMTP messages. IBM also must
pay attention to whitelisting in several parts of Domino's existing antispam features. The other technologies presented mostly fall into the realm of IBM Business Partners' antispam solutions.