Drew Weaver <drew.weaver@thenap.com> inquired:
I know you all have probably already thought of this, but can
anyone think of a feasible way to run a RBL list that does not have a single
point of failure? Or any attackable entry?
Fedex. "Never underestimate the bandwidth of a station wagon loaded with DLT
cartridges barreling along the highway at 70mph"...
Seriously, as has already been pointed out, the distribution side of the
equation is the easy part. Server admins can use an out-of-band technique
like ordinary dialup to get access to the blocklist. But generating the
blocklist requires real-time reporting back to a central server. Even if the
server is decentralized, it will still require a relatively small handful of
accessable IP addresses.
An out of band layer-2 network could be created for that at the peering
points, so as to prevent outside attack. Probably worth doing among major
ISPs. Wouldn't scale to end users, of course. But end users could still
subscribe to the blocklist through periodic updates.
The other obvious thing that could be done would work pretty much like caller
ID: create a set of SMTP enhancements that allow email recipients to accept
mail from those who have provided traceable ID to the ISPs that participate,
and who have agreed to acceptable-use policies that place strict limits on
bulk email. Wait, hasn't that been done? The pre-1987 ARPAnet? Oh yeah,
we've outgrown that...
Public humiliation might also work. Bring back the stockades so we can place
spammers out front of courthouses everywhere. Too bad society's outgrown that
too...
-rich
I respectfully disagree. What it requires is some mechanism to get updates
back to "authorized" server(s), and those "authorized" servers need to
determine what to do with the reports. This does not need to be
real-time. Near-time would suffice IMO. The interesting issue with regards
to this component is indeed not the transport mechanism, but rather
dealing with the influx of reports, and mitigating DOS's through floods of
bogus reports. This is where things like the "web-of-trust" concept comes
in handy.
Sorry, but this is definitely getting off the operational charter of
NANOG, so I'll stop. 
There are a few people that have expressed
interest in exploring this further. If anyone is interested drop me a
line privately.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell
Asking the wrong questions is the leading cause of wrong answers
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
I seem to recall a distributed server network, something called USENET, uses NNTP for sharing data with other servers in the network... Last I heard there were over 30,000 such servers netwide/worldwide, all sharing data with one or more neighbors, automagically sharing data that is input into one system to all systems in a relatively and reasonably short amount of time.
I propose that a private spamrbl nntp server system be established. Only allow feeds from those you know, use PGP authentication for all feeds and all submissions. If there is a personally verifiable web of trust built around personally verified signed PGP keys, it should prevent spammers from infiltrating the system. Perhaps the only way you can get approved/added to the network is to be approved by your upstream or a peer, and so they are held accountable for letting you into the system.
This system could house a number BLs, each as a "newsgroup", allowing each network to then utilize the BLs that they want to implement in their network at any given time. Some of the newsgroups could be open, anyone can add a listing, others would be moderated (e.g. Monkeys or Spamhaus) and only the moderator(s) could add or remove listings.
It seems too easy. I must be overlooking something really stupid and obvious about why this won't work.
jc