Re: blacklist to Brown list conversion

Eric S. Johansson, who definitely talks too much, wrote:

> to bring it back on topic, a blacklist repair service based on proof of 
> work systems could be quite useful.  Especially if we can make it 
> something that doesn't have to change the message recipient.  For 
> example, make it a transaction between blacklisted site and blacklist 
> database.   Something like "I have been blacklisted from..., I want to 
> send one message, how much?"  and after they received the price, the 
> sender can either generate the stamp or throw away the message.  After 
> some threshold or number of times of generating stamps, the stamp price 
> declines as long as there are no hits reinforcing the pricing level.  Or 
> something like that.  Yes, I am a fan boy for dynamic pricing systems 
> because that lets us get around Moore's law inflation and reward people 
> for doing good things.

thinking some more on this, I do believe the key to dealing with 
blacklists is a Brown list CBL type system driven by tokens from blocked 
sites.

on the sender side, there should be some form of proxy intercepting 
traffic between the sending MTA and the receiving MTA.  The proxy should 
be on the sending MTA side of the transaction.  If the proxy detects a 
blacklist block, it takes the message that had been sent and stuffs it 
in a queue.  The queue consumer queries the CBrL for pricing, generates 
the appropriate size token, and then delivers the message.  The CBrL 
then gives one "not blocked" response for a query about the token 
generating address.

On the other side of the equation is the number of reports of bad 
behavior.  As the number reports climb, the cost of postage goes up.  As 
the number of reports drop and the number of tokens generated go up, the 
cost of postage goes down.

Pricing for stamps in this context should be reasonably large.  I think 
that something like a 16 minute stamp would not be unrealistic in the 
very beginning.  It's large enough that it will dissuade spammers from 
sending a single message but it's small enough to make it possible for 
someone to get a "hey, something's broken" message.  And, as the pricing 
model describes, it will get better with time if you clean up your act.

I think the "easiest" way to implement this would be to take advantage 
of modern firewall rules to intercept traffic and redirect it to a proxy 
program.  The proxy front-end should be something written in something 
like C/C++ so that it will run reasonably fast for the 99% case.  The 
backend can be cobbled together out of twopenny blue pieces because, 
quite frankly, you don't care about performance when you are generating 
eight or 16 minute stamps.

The threat model is the same as other proof of work systems, i.e. 
overwhelming force applied to the problem.  Using the zombie calculator 
13 billion spam baseline and 16 minutes stamps, you'd need 441 million 
zombies.  with proper feedback, the number of zombies needed would 
increase significantly as individual zombies are identified and priced 
out of the market.  The other advantage is that stampers can't send 
anywhere near as many spam messages.

A couple of challenges involve scaling.  How does one scale such a 
service.  How does one communicate pricing information across a network 
in such a way that it can't be double spent?

I don't think the problems should dissuade one from trying because this 
is another good example of how proof of work stamps can be used in a 
positive fashion to repair a broken system.

anyway, that's my thoughts on the subject.

---eric

-- 
Speech-recognition in use.  It makes mistakes, I correct some.