[hashcash] Re: hashcash for camram-spam list? (Re: [camram-spam] Re: Friday news)

On Sun, Mar 28, 2004 at 04:38:11PM -0500, Eric S. Johansson wrote:
> >Adam wrote:
> >>This is an anti-spam measure; perhaps we could tweak the mail list
> >>software so it allows posts with hashcash for the list address (such
> >>as this one with a hashcash for camram-spam@xxxxxxxxxx).
> 
> I would be careful about this.  Allowing any address in based on a stamp 
> effectively devalues the stamp.  In other words, for a given amount of 
> effort, you can reach more people.  

Maybe I'm misunderstanding what you're saying.  But the value of
sending hashcash pre-emptively even when you don't know the recipient
can handle it is that:

- you should not be blacklisted based on IP
- your mail should not be subject to false +ve

- your mail should not be subject to a challenge-response that you:
  - are too lazy to reply to
  - that gets accidentally filed in trash by your own spam filter
  - that gets tied up in a knot with someone else's competing CR system

in keeping with this another kind of false +ve avoidance is:

- avoiding your mailing list post getting forwarded to a moderator
  because there is something which triggers mailing list anti-spam
  filter or spam based policy (eg not list member by it's necessarily
  crude approximation -- I am a list member, but making my list
  headers match the subscription address is more pain than it's worth(*)).

in short more stuff should just work.

> This is where the signature based if stamps we have been dancing
> around would shine.
> 
> If on the other hand, you use something like hmac-sha1, [...]

Not sure how to make this would help the mailing list case without
mailing list support.  The sender doesn't know who is behind the
mail-exploder.

I'm wondering if we need to think ahead about v1 format wrt adding
signatures, hmacs etc.  Auth tokens are "special" in the sense that
they sign the rest of the stuff, and so need to be divided from it in
someway, and yet would be useful to be able to have the in the same
header via an extension.

eg. hash on introduced public key, signature instead of or in addition
to smaller hash on subsequent mails (if you're doing the CAMRAM
introduce sig key thing).


On the approach to add hashcash/camram support to mailing-lists
proper, I mention in the FAQ a race condition issue with list is
recipient approach, and a view on a better approach: have the list
accept hashcash, remove it, and replace it with it's own signature.

Then you the recipient know you've received mail from the list because
of the signature.  You know the list made use of hashcash (probably it
would not reject mail without hashcash because not many people are
using hashcash, but it might be easier to post to the list with
hashcash by avoiding filtering, policies etc).

So perhaps this can be done with what you had in mind for CAMRAM sigs
where the subscriber and the list are CAMRAM aware.  You send the list
hashcash / CR at subscription time, you get back an allowed to post
cert, or the list remembers your public key, then you can post.

(Allowed to post cert saves storage on list server, it can figure it
out for itself from the allowed to post cert you re-present -- list
storage vs bandwidth tradeoff).

Adam

(*) reasons this can fail

- there's a lot of outbound sender re-writing going on, and sometimes
it changes over time

- some people forward via different shell accounts, smtp servers when
travelling etc; this can lead to varying From addresses (though a
constant From: address); both are trivially forgeable, yet many
mailing list software places more weight on one which is inconvenient
to forge on a regular basis with out doing direct to MX sending.

Other related posts: