My definition of an email reputation Aggregator is a service that uses multiple sources of reputation data (from Reputation Collectors) to come up with a score or action useful for inbound email servers.

For example, SenderScore by ReturnPath states in their beta announcement press release (end of June 2005) "The data used to create the Sender Score system comes from dozens of different high quality sources" including Cloudmark, a sophisticated user feedback / trust network and Lashback, a relatively new company which helps user unsubscribe while identifying senders who don't live up to their promises to remove addresses when asked. SenderScore's beta announcement refers to 60 datapoints used in determining the score.

My company, Server Authority, Inc's Outbound Index also fits the definition of email reputation Aggregator. Articles in September 2004 refer to "Business Trust Ratings for Email" and relate the Outbound Index's focus on the simple theory of relationship, stability and longevity in recognizing messages generally welcomed by recipients. I can tell you more about the Outbound Index since I am one of the creators of the Outbound Index, SIQ domain+IP public domain protocol for email reputation services, and SIQuery clients for Sendmail, Exchange, and Postfix.

The Outbound Index has continuously updated inhouse databases that can be use to track:

 -  longevity and stability of domain names used in email

 - age, density, and churn rate of name servers

 - FQDN host patterns of mail servers and non-mail servers

 - FQDN stability

 - Charaterizations by nethandle, ASN, route and ClassC

 - high verification threshold SSL certificate holders

 - domains of Forbes, Fortune, Business Week listees

In addition, the Outbound Index uses all freely available quality whitelists such as Habeas and Bonded Sender IP whitelists. SPF records are checked and optionally available for use in scoring but are not used as the sole determinant. Other People's Blacklists are used - both RHSBL (Right Hand Side BlackList - domain name blacklist) and IP blacklists.

Aggregation is in my opinion a must. Blacklists alone will miss 40% of the spam we see. Requirements for passing "authentication only" are easily met by spammers. Purely statistical methods do not achieve 100% accuracy because the human judgement and research currently done by the most trusted black and white list operators is needed as an adjunct.

Email reputation began with blacklists, often with a single person acting in the role of reputation collector and aggregator, delivering a binary decision of yes or no to the MTA (Mail Transfer Agent aka inbound email server.)

As MTA admins became frustrated with the limitations of blacklists, they began doing aggregation in their own inbound servers. They wrote Perl scripts, milters, Procmail recipes, hooked into DCC and Razor networks, checked 20 blacklists instead of just one. SpamAssassin helped MTA admins become aggregators and even collectors of their own spam and ham data. We tried it too - for awhile.

Some downsides to the MTA-as-aggregator:

 - High resource usage

 - If there are 100,000 MTA admins, 100,000 man-hours needed for each hour of education / re-configuration / upgrade / writing of new rule to stop new way spammers are getting around it. Updated "do it yourself" sets of aggregator rules are not easy to find - maybe because spammers like to have them to tune their next piece of spam to before the big mailing is sent out. Maybe because it is hard for anyone to keep up.

 - Updates and changes to mail servers put reliability at risk - and constant updating is required.

 - Some tests are not practical to do within one machine

Third party aggregator services can dramatically reduce the load on inbound MTAs and increase message throughput by reducing the number and complexity of email reputation tests the MTA does locally.

In addition, adding new tests doesn't mean changes to the MTA - the updates take place within the aggregator, while the MTA client remains untouched.

Aggregators may also be  more likely than an isolated local MTA to have DNS and other email related responses in a cache.

In the future, I predict that MTA admins will be able to choose the Aggregator they prefer from a variety of different companies with different philosophies and different bias, offloading most of the pre-DATA anti-spam processing to their choice of reputation Aggregator service.