[Top] [All Lists]

Re: comments? hashcash based MTA filtering

1999-02-24 13:01:46

Dave Kristol wrote:
Adam Back wrote:

As started to come out in my response to Tim Showalter there is some
complexity once you start to think seriously about using hashcash:

- mailing lists

  need a way to by pass postage requirement for list software

Unfortunately, mailing lists are hard.  

To be clear, I meant that the list software (eg. majordomo) would be
exempt from including postage for each list subscriber that it will
forward list traffic to.

You could require postage to post to the list, where the list software
could reject posts without sufficient postage.

You want to by-pass the postage requirement, but only if the sender
is a legitmate sender.  (And how do you define that?)  How many
lists have you been on where a spammer sent junk to it?

Sure it happens.  The most sensible solution I have seen for this
problem is moderation, third party filtered versions of lists, and
distributed ratings / filtering using NoCeM.  (NoCeMs can be used for
mailing lists as well as USENET news, and allow any number of people
to submit article ratings that NoCeM aware clients can use).

Also, how do you deal with just lists of recipients (as in the Cc line
of this message?)  Do you attach coins for each recipient?

Well there are at least two things that you could do:

- attach a coin for each recipient (as you suggest)

- send a combined coin (a collision computed over the concatenation of
the recipients)

The first approach could leak the identity of a Bcc if you included
the postage in all copies.

The second approach does not work so well if there are also some

I think the first approach could work, if you sent the postage in the
email address using the +extension.  eg. for this message:

without hashcash:

To: dmk(_at_)bell-labs(_dot_)com
CC: wall(_at_)cyrusoft(_dot_)com, ietf-mta-filters(_at_)imc(_dot_)org, 

with hashcash:

To: dmk+10646-066ce5349777340d(_at_)bell-labs(_dot_)com
Cc: wall+10646-28d3b2c2cc27b192(_at_)cyrusoft(_dot_)com,

(The above are real 20 bit collisions, taking average 8 seconds each
to produce on AMD k6-2/300Mhz linux box.)

using the transform of X(_at_)Y -> X+date-cash(_at_)Y

The software at creates
hashcash with slightly different form to those I used above.  It

% hashcash -20 wall(_at_)cyrusoft(_dot_)com
speed: 126758 hashes per sec
find: 20 bit partial sha1 collision
estimate: 8 seconds
expected: 1048576 tries = 2 ^ 20 tries
collision: 10646wall(_at_)cyrusoft(_dot_)com28d3b2c2cc27b192
tries: 952419 0.91 x expected
time: 8 seconds

so it's hashcash is of form:


because it tries to require no other state -- the string the collision
is on is included in the cash.  The alternate format I used above must
be formatted differently because the result must be a valid and
deliverable RFC822 mail address.