[Spambayes] Two Stage Plan

[Eric S. Johansson]

Kaitlin Duck Sherwood wrote:
> (Sorry I'm late to this particular discussion on using postage...)
> 
> I'd like to suggest
> + making the postage stamp computationally VERY expensive for the 
> client, and
> + assume that users look at postage as only one factor in judging 
> spaminess.

actually, there is a project for this type of system called camram.  I 
have a working proof of concept including handling postage due notices 
etc. I'm expanding it to include a Bayesian style filter as a 
discriminator in case a message fails the stamp or white list tests.  If 
you'd like a white paper on this, either way a few days for it to be 
published (theoretically) in the proceedings of the upcoming antispam 
conference, or you can ask me nice and I'll send you the document 
(unfortunately in Microsoft Word format).

> If postage is only one factor, then it can be useful before "everybody" 
> adopts it.  If postage is only one factor, then listbots can insist on 
> one postage unit for messages that the listbot receives, but the listbot 
> can then send out out messages (to the teeming hordes on the list) 
> without postage

not exactly true.  If you use postage due notices with the ability to 
generate postage stamps via a Java applet, you can get some benefit 
without 100 percent adoption.

We operate on the principal that "strangers cost, friends fly free" 
which means that I only expect stamps from people I don't know.  A 
mailing list is someone I know and therefore I don't expect any stamps 
from them.

A mailing list could ask for stamps from everyone but it would make more 
sense to use the postage due mechanism only for nonsubscribers.  Then 
you can use the same technique I do and camram which is that anyone you 
can't deliver a postage due notice to is spam and therefore the message 
can be safely discarded.  Yes, I know it's not strictly true but if you 
pay attention to why message delivery fails, it's effectively true.

white list on the other hand our home other topic and I believe should 
be based on name but on public key.

> I want postage to be computationally *very* expensive.  Like five or ten 
> minutes on a (currently) high-end desktop.  I want strangers to have to 
> spend some time -- not just money -- to be sure that I'll read their 
> messages.  Shoot, I don't even care if there is no money involved at 
> all, "only" time.
> 
> I also want the reverse algorithm -- where I check to see if their token 
> is valid -- to be very fast.

google for Adam Back, hashcash.  Also look for "proof of work" puzzles. 
  unfortunately, proof of work puzzles suffer from Moore's Law 
inflation.  I've been given a lead that says a proof of work puzzled 
exercises the memory bus will be less susceptible to Moore's law 
inflation and I'm talking with a cryptographer about a memory intensive 
POW puzzle.

By the way, if you do the math, a three second computation would slow 
down a high-powered spammer 140 times or, put another way they would 
need 140 machines generating stamps constantly in order to keep up the 
same data rate through a T1.

Computation length is very tricky because you don't want it to be so 
long that you discourage low-end machine users while at the same time, 
not giving high-end machine users a significant advantage.  although, 
this problem can be reduced by pushing the stamp calculation and mail 
delivery into the background.

> So are there any one-way algorithms that would involve my email address 
> and some other piece of changing data, like seconds since Jan 1, 1970?  
> Or perhaps make and use a Web service that generates and posts random 
> time-stamped numbers?  (A web service with random, time-stamped numbers 
> could also provide for essentially constant difficulty as processors get 
> higher-powered, e.g. the random numbers keep getting bigger.)

centralized services fail from a reliability perspective.  They can also 
fail if a service can be corrupted or abused.


> BTW, anyone who is going to the spam conference, look for me in the 
> colored (probably purple) beret! 

as will I. (be there I mean. sans beret, may be bright yellow terry 
cloth hat at times)

---eric