[hashcash] Re: OmniMix with recipient related Hashcash
- From: "Eric S. Johansson" <esj@xxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Mon, 04 Dec 2006 09:56:34 -0500
Christian Danner wrote and I rearranged:
Hi!
>
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 ('abc@xxxxxxx').
this is fantastic. I am impressed but I do hope you'll add IMAP to that
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
you've done but you hitting the same problems we had about eight years
ago (if memory serves). This is why stamp generation is more
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ïve sender-pays. It's been around since the days of
Penny Black which is well over a decade. Hash Cash, if I remember
correctly, it's coming up on its 10th birthday in a year or two. All of
the problems with naïve sender pays (high load on everyone, unusable on
small devices (cell phones, PDAs), unfair load on older devices, reduced
damage on spammers, almost mandatory requirement to place damp
generation on end-user devices) have triggered significant decreases to
and kept it from widespread adoption.
The strategies for reducing the problems with naïve sender pays are not
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ïve, conditional/hybrid)
o URL of address->Stamp size server (optional)
I've implemented the first element but the second is going to have to
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
again my concern with that model is that it won't eliminate false
positives and second, it may give spammers an easy way through for a
fairly small/low-cost stamp. Have you done any modeling that could help
put my mind at rest?
---eric
Other related posts:
