Re: Any way to P-T-P Distribute the RBL list
Distributing an RBL list is the easy part. There are a variety of methods in place that can provide sufficient reliability and are sufficiently anonymous or difficult to attack, such as Usenet and Freenet and Gnutella and probably Kazaa, and it's not too hard to develop efficient data formats for baseline and incremental update and detail records (easier for IPv4 blocking than IPv6 :-), and you can use PGP or other digital signatures to protect the integrity of the transmission. SMOP... There are some problems with broadcasting the list as opposed to doing transactional interaction - a list of "mis-configured open relays or proxies with updates" is not much different from the spamware spammers' products of list of new still-usable open relays. (It's a bit less useful, because they know that some people are blocking them, but they also know that lots of people aren't.) The other half of the communications process is harder - getting the information on spammers to the list maintainer without exposing the list maintainer to attack. A simple usenet group or IRC channel can be flooded, and email can be mailbombed, and the obvious way to do it is with bogus spam reports to reduce the integrity of the information. And some of it's an arms race, e.g. spammer submits a purported open relay to list-manager the list-manager's tester tests the "relay", and the "relay" captures the tester's IP address for DDOSing. There are spam-reporting reputation systems - Cloudmark and Vipul's Razor do some of that, if imperfectly, or simple subscriber-only systems can stay below the radar (even though they'll have some spammers subscribing...) and you could probably build one that was P2P for a bit more safety.
On Thu, 25 Sep 2003, Stewart, William C (Bill), RTSLS wrote:
Distributing an RBL list is the easy part.
Why stop there ? The generating of the list itself can be a P2P thing too. You could peer with a group of people you trust and exchange the list of IP addresses that send crap into each other's spamtraps. Then block IP addresses that have sent crap (measured by SA?) into the spamtraps of multiple people, or come up with other nice metrics. I'm sure you can come up with all kinds of tricks here. I started a project with this goal a while ago, but to my shame it still hasn't moved beyond the "spamtrap fed blocklist" stage yet, we simply haven't gotten around to writing the p2p parts yet. ;( I'd appreciate help though ;) http://spamikaze.nl.linux.org/ Rik -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Hi Rik You may to have a look at "Vipul's Razor" Specifically: (from: <http://razor.sourceforge.net/docs/whatsnew.php> feature #8) ---- Truth Evaluation System (TeS) Razor v2 has a transparent, back-end component known as TeS. TeS is a combination of a reputation system and pattern recognition heuristics that assigns trust to reporters and confidence values (between 0-100) to every signature. Users can set an acceptable confidence level in their Razor configuration. The server also publishes a recommended confidence level. TeS has been designed to eliminate false positives of legit bulk email that were occasionally generated by bad reports in Razor v1. ---- General overview: <http://razor.sourceforge.net/> --- May 16,2003 - Razor-agents 2.36 released! The release of Vipul's Razor v2.36 is now available for public download. The software is comprised of two source packages, razor-agents and razor-agents-sdk that can be downloaded by following these links: * razor-agents-sdk-2.03 * razor-agents-2.36 What is Vipul's Razor? Vipul's Razor is a distributed, collaborative, spam detection and filtering network. Through user contribution, Razor establishes a distributed and constantly updating catalogue of spam in propagation that is consulted by email clients to filter out known spam. Detection is done with statistical and randomized signatures that efficiently spot mutating spam content. User input is validated through reputation assignments based on consensus on report and revoke assertions which in turn is used for computing confidence values associated with individual signatures. -- Rafi ## On 2003-09-27 12:04 -0400 Rik van Riel typed: RvR> RvR> On Thu, 25 Sep 2003, Stewart, William C (Bill), RTSLS wrote: RvR> RvR> > Distributing an RBL list is the easy part. RvR> RvR> Why stop there ? RvR> RvR> The generating of the list itself can be a P2P thing too. RvR> RvR> You could peer with a group of people you trust and exchange the RvR> list of IP addresses that send crap into each other's spamtraps. RvR> RvR> Then block IP addresses that have sent crap (measured by SA?) into RvR> the spamtraps of multiple people, or come up with other nice metrics. RvR> RvR> I'm sure you can come up with all kinds of tricks here. RvR> RvR> I started a project with this goal a while ago, but to my shame it RvR> still hasn't moved beyond the "spamtrap fed blocklist" stage yet, RvR> we simply haven't gotten around to writing the p2p parts yet. ;( RvR> RvR> I'd appreciate help though ;) RvR> RvR> http://spamikaze.nl.linux.org/ RvR> RvR> Rik RvR>
participants (3)
-
Rafi Sadowsky -
Rik van Riel -
Stewart, William C (Bill), RTSLS