Sender Authentication Techniques
Sender authentication techniques and a reputation framework work together to create a trusted group of reputable senders. A verified identity (through an existing authentication mechanism) is a required basis for maintaining sender’s reputation. Moreover, a reputation service is able to guide a receiver through the process of validating the sender before the sender’s emails are accepted. Email Id-identity systems, such as PGP, can be used to maintain reputation. However, using email ids entails maintaining a huge overhead for vote collection, storage and reputation computation. Instead of using email ids as identities for reputation management, we use domain authentication schemes, thereby decreasing the number of identities needed. We believe that this approach is more scalable than the email id based reputation system. Recent reports mention that about 35% of all authenticated email over the Internet is authenticated using SPF, DKIM or SenderID. A reputation management system can be built to help evaluate the senders who are being authenticated using these mechanisms. Such a mechanism will help evaluate the domains that adhere to a common guideline. The lack of a centralized authority has been noted as a main reason for the inability to tie email forgery to a single user or the organization. A central authority can maintain a trusted group of reputable senders where each sender needs to maintain a high reputation. Such a echanism allows a common best email practice to be enforced among senders.
Email Infrastructure with RepuScore
RepuScore's heirarchical architecture consists of RepuServers reporting reputation information to RepuCollectors. We define RepuServer as a mail server with the capability of verifying the users and collecting the reputation votes from them. Each local RepuServer at a domain collects votes from its users and email filters, aggregates the votes locally, and forwards them to the RepuCollector of the domain. We define a RepuCollector as an organizational level service that aggregates the votes from the local RepuServers and participates in a global reputation of peer RepuCollectors. Each RepuServer records the total number of emails received during a given period and counts the ones that are considered to be spam by the currently available spam-filtering mechanism or by the user’s input. Listing 1a demonstrates the mechanism for the receivers to report spam to their local RepuServer.
Listing 1a: Collection of reputation votes by different RepuServers in an organization. The sender’s identity could be used with any domain authentication technique. The reputation votes can be submitted either by users such as Bob or using any currently available filtering mechanism.
Heirarchical Email Infrastructure
Listing 1b shows the heirarchy of the RepuServers and RepuCollectors. A single or multiple organizations can maintain a single RepuCollector. For the sake of brewity, we assume that each organization maintains a single RepuCollector. Each RepuServer in the organization uses the local RepuServer Algorithm to compute the change in the reputation that is reported to the RepuCollectors. Each RepuCollector averages the information received from its RepuServers. Such computation distributes the load in an heirarhical manner. It is important as each organization can submit a single vote to the Central Authority. Addition of multiple RepuServers does not imply additional votes for a single organization. This thwarts spammers from creating multiple RepuCollectors to thwart RepuScore.
Listing 1b: Demonstrates the hierarchy of RepuServers and RepuCollectors. Each domain maintains a single RepuCollector that collects the reputation votes from the multiple RepuServers in the organization.