Re: OmniMix with recipient related Hashcash

Christian Danner wrote and I rearranged:
> Hi!
> >=20
> That's why I added a simple Hashcash minter to OmniMix (v0.9.9.2), a
> Windows based NNTP/SMTP/POP3 proxy server used to anonymize messages
> by means of onion routers. It now allows to equip all mails, whether
> sent the normal way or through the remailer network, with tokens based
> on the recipients' ('To:'/'Cc:') mail addresses ('[email protected]').

this is fantastic.  I am impressed but I do hope you'll add IMAP to that=20
one of these days.

> The
> size has to be set within the program. To prevent from exaggerated
> computation times there's an option to reduce it on a
> message-by-message basis dependent on the number of tokens to be
> calculated. So even longer mailing lists don't 'cost' more time and
> shouldn't overload the system.

I don't mean to be too denigrating because I really appreciate the work=20
you've done but you hitting the same problems we had about eight years=20
ago (if memory serves).  This is why stamp generation is more=20
complicated than it seems it should be.

> I followed the recent discussion about methods to use Hashcash for
> spam protection. I have to admit that most of those strategies appear
> to me much too complex to achieve a better acceptance. IMHO in order
> to raise the approval rate deployment and practical operation have to
> be less complicated in the first place. Keep it simple! And later on,
> if it stands the test, add further gadgets or even build a dedicated
> infrastructure.

The simple is na=EFve sender-pays.  It's been around since the days of=20
Penny Black which is well over a decade.  Hash Cash, if I remember=20
correctly, it's coming up on its 10th birthday in a year or two.  All of=20
the problems with na=EFve sender pays (high load on everyone, unusable on=
=20
small devices (cell phones, PDAs), unfair load on older devices, reduced=20
damage on spammers, almost mandatory requirement to place damp=20
generation on end-user devices) have triggered significant decreases to=20
and kept it from widespread adoption.

The strategies for reducing the problems with na=EFve sender pays are not=
=20
difficult.  You send a stamp when:

    o you have never sent mail to the user before
    o the site has a DNS TXT record stating:
       o baseline size of required stamp
       o type of s-p (na=EFve, conditional/hybrid)
       o URL of address->Stamp size server (optional)

I've implemented the first element but the second is going to have to=20
wait for a future release.

> The presence of a recipient specific token itself already qualifies a
> message, so that spam recognition systems have to rate it in their
> evaluation process, considering the value (bits) it represents as
> well. More bits - better rating.

I'm assuming this is as a front-end or part of a content filter.  I=20
again my concern with that model is that it won't eliminate false=20
positives and second, it may give spammers an easy way through for a=20
fairly small/low-cost stamp.  Have you done any modeling that could help=20
put my mind at rest?

---eric