The Rise of Reputations in the Fight Against Spam @ LinuxWord

The battle with spam can easily be compared to an arms race. Spammers will learn about and start exploiting a certain method to send their garbage messages. E-mail administrators (with the help of open source developers and vendors) will respond with anti-spam tools battling the latest and "greatest" spammer methodologies. This seems to be an endless cycle, having yet to reach an end point.

Some of the more common anti-spam methodologies in use today include (though this is certainly not an exhaustive list):

Header/content checks (SpamAssassin)
Bayesian analysis
Sender authentication (Sender Policy Framework, Yahoo DomainKeys, etc.)
Challenge/response (TMDA, Camram)
Static whitelists/blacklists
Blackhole listing (SORBS, Kelkea MAPS)
Distributed checksums (DCC, Vipul's Razor)

These methods continue to be very useful in the fight against spam and will likely remain that way for the forseeable future. Reputations are (arguably) the newest tool in the administrator's fight against unwanted junk e-mail. Almost every commercial anti-spam vendor implements some sort of reputation in their product or service. In addition to the commercial products, an open source reputation solution called GOSSiP (Gossip Optimization for Selective Spam Prevention) is in early alpha and I'll discuss it later in the article.

What Is a Reputation?

The wider area of reputation is rather broad and deep, and certainly not unique to the fight against spam. The References section at the end of this article lists a few of the available research papers on the subject of reputations and their potential use. The generic field of reputation is related to many areas, such as security and trust. This means the field of reputation overlaps with such things as SSL certificates, domain registration, and the operation of the root domain name system (DNS). As a result of the connection between reputation, network trust, and basic Internet operational components, companies such as Verisign are entering the reputation field.

A reputation score is often compared to a credit score from one of the credit bureaus (Equifax, TransUnion, or Experian). This analogy is useful, though credit scores are somewhat different from reputation scores. A credit score (and similarly a reputation score) is all about measuring the risk of a "bad event" happening. In the case of credit, the risk is whether the customer will pay his or her bill. When it comes to spam, the risk is the likelihood that a given entity (IP address, domain, From: address, etc.) will send a spam message.

The idea that a high credit score means a customer is more likely to pay the bills is similar to a higher reputation score indicating a message is not spam. Alternatively, a lower credit score indicates that a person is less likely to repay a debt as a lower reputation score indicates a message is more likely spam.

There are a couple of differences between reputation scores and credit reporting. First, each organization (anti-spam vendor) has its own idea of what a reputation is. There are no standards that govern what should go into a reputation score, so each vendor uses different criteria. Not surprisingly, in the case of commercial vendors these criteria are held as trade secrets and not disclosed publicly. Knowing and evaluating the criteria used by each vendor and comparing the results of each particular vendor are impossible. Unfortunately, this is unlikely to change in the near future.

Along with the issue of transparency, there is no centralized clearinghouse of reputations such as there is with credit scores, e.g., Equifax, TransUnion, and Experian. This makes it more difficult for anti-spam vendors (or interested e-mail administrators for that matter) to exchange reputation scores. With the widespread use of open source reputation tools such as GOSSiP and work by the IETF, this may change. Also, market forces (i.e., customers) may compel commercial anti-spam vendors to define an interoperability standard, and perhaps even the criteria used in generating the reputation scores. At the very least, we can always hope!

Another way of managing reputations is for marketers to pay a bond to a third party. Then, if/when the marketers have spamming complaints lodged against them, the third party penalizes the marketer monetarily. Ironport's Bonded Sender program is an example of a company that does this. Being financially based, critics say this "accreditation" may turn into a way for spammers to legitimize sending their trash, if the bonding company "turns a blind eye" and doesn't penalize the marketing organization for sending spam. Unfortunately, the only way we'll know for sure whether these solutions are truly effective is when bonding programs have a track record over time that can be evaluated.

Reputation scores can be used in other areas besides fighting spam. For example, reputations can be used in the fight against phishing attacks (where people unknowingly give out their personal financial-related information to criminals). If e-mail messages had a way to securely verify to the recipient that the sender was indeed who he said he was (the legitimate domain and not a scammer), it might force the criminals to use alternative methods. It's for reasons like this that companies such as Verisign have entered the reputation market.

Reputations and Spam

At the most basic level, almost any type of spam blocking could be considered a variant of reputation scoring. For example, in challenge/response systems, the receiver chooses to question the reputation of the sender until the sender performs some specific task. In the case of static blacklists, the recipient chooses to "score" the senders on the recipient's blacklist as spammers and not see messages originated by those senders.

For the purposes of this article, I'll define reputations as nonbinary scores that are shared between e-mail servers and are persistent (though changing) over time. If you think about it, black hole listing services and distributed checksums systems are really binary reputation systems.

Blacklists allow you to block messages using header IP addresses, senders, and other criteria in an e-mail message. If you don't want to receive e-mail from a particular server, just put the appropriate criterion that uniquely identifies the server on your static blacklist.

Want to share static blacklists with others? Set up your own blackhole listing service. Examples of such services are Kelkea MAPS and SORBS. A blackhole listing service such as SORBS is usually (though doesn't have to be) implemented by the spam-blocking e-mail administrator, essentially as a dynamic blacklist. In other words, messages originating from IP addresses/mail servers on the dynamic blacklist are blocked. Alternatively, the services can be used as an input to message-scoring systems such as SpamAssassin.

Distributed checksums are another example of binary reputation systems. In the case of Vipul's Razor, if a message is considered to be spam its signature is added to the list and reported to other Razor servers. Similar in nature to static blacklists and blackhole listing, distributed checksums can be considered binary reputation systems. Either your e-mail message is on the list (and probably blocked) or it's not and allowed through. Again, the collaborative services can be used as part of a message score for "spaminess" in systems like SpamAssassin.

Reputations and Sender Domain Authentication

Sender Policy Framework (and similar schemes) is a protocol by which domain owners publish DNS TXT records that indicate which IP addresses are allowed to send mail on behalf of a given domain. These records can be thought of as "reverse MX records" for a domain. Recipient mailservers who want to enforce SPF records simply check the DNS SPF records associated with the domain; if the sending e-mail server is listed in the SPF records, the message is allowed through. If not, the message can be rejected or subjected to additional checks.

Not surprisingly, many spammers quickly published SPF records for their domains. This is due to the fact that spammer domain owners (like all domain owners) are responsible for publishing SPF records for their own domains. As a result, the SPF backers/protocol designers had to endorse another method to catch spammers plying their trade, and the obvious choice was combining domain authentication with reputations.

The idea is that once spammers identify themselves without question via SPF, recipients block spam by using the reputations associated with the spammers' well-known SPF-identified mail servers sending the trash. SPF's site calls the new approach the Aspen Framework and it was under active discussion at the time this article was written. The combination of authentication with reputation should make spammers even easier to identify.

GOSSiP

GOSSiP is one of the only open source reputation software available. Be aware that it's in the early alpha stage and not all features are implemented. GOSSiP is available under the GNU GPL from Sourceforge. It's useful to look at GOSSiP in some detail, as it may give some insight regarding how commercial vendors might approach the problem of assigning reputation scores. GOSSiP works by generating reputations for known senders by using feedback from the mail server's anti-spam engine. This information is combined with reputation scores from other GOSSiP servers to come up with a "final" reputation score for incoming messages.

A GOSSiP identity is the sender's IP address paired with the right-hand side of the MAIL FROM field. Each identity is assigned a score, which consists of three attributes:

A GOSSiP server's experience with an identity, including the GOSSiP server's peers
The trust the GOSSiP server has regarding scores assigned by its peers
The confidence level the GOSSiP server has in its data

When GOSSiP servers propagate scores between themselves, scores are assigned confidence levels as well as time-to-live (TTL) values. Assigning a TTL enables GOSSiP identity scores to "time out" of the system. The GOSSiP server will not use scores from its peers that are significantly different from its own. Also, it uses the confidence level of the score and the trust rating of the peer to determine the new reputation score for the identity. The new identity score is calculated by using an average, and that information is what is reported to a GOSSiP peer or a (local) mailserver processing a message.

Integral to the GOSSiP system is a feedback mechanism from the anti-spam software running on the local mail server to the GOSSiP server. Without feedback, GOSSiP would not be able to update its reputation. Currently, only SpamAssassin has hooks to send feedback to the GOSSiP server so it can update the reputation of its identities. The feedback to the GOSSiP server consists of the message ID and a binary value, indicating the message associated with that message ID was either spam or non-spam.

Figure 1 shows the flow of an inbound message and the interaction between GOSSiP servers in a GOSSiP-enabled e-mail infrastructure setup.

Conclusion

Reputations are a central part of most commercial anti-spam services and firewalls, like credit reporting is central to issuing credit cards. The field of reputations in the fight against spam is currently in a state of rapid flux. Each vendor has its own secret idea of what should constitute a reputation, and there is little or no sharing of reputations between services/providers. Vendors haven't agreed upon common reputation standards, and no single reputation service has emerged as a "clearing house." The combination of sending domain authentication schemes such as SPF with the idea of reputations will likely be a significant advance in the fight against spam, once such systems are widely deployed.

Reputations could be used for addressing other security issues, such as phishing, but this particular application of reputations hasn't happened yet, at least on a large scale. GOSSiP is a freely available reputation software and system that can be used in the fight against spam. While the code is in early alpha stages, it is certainly worth watching and learning more about if for no other reason than to understand how anti-spam vendors might be implementing their own nonpublic reputation systems.

Acknowledgments

I would like to thank the following people for their input and for taking the time to speak to me about reputations and spam: Mark C. Langston; Stephen Pollei of the GOSSiP project; Scott Chasin, CTO, MXlogic; Dave Rand, founder/CEO, Kelkea; Andrew Lochart, director of product marketing, Postini; Sushant Rao, senior product manager, Mailfrontier.