[hashcash] Re: OmniMix with recipient related Hashcash

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: