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):
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.
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.
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.
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:
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.
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.
© 2008 SYS-CON Media Inc.