[hashcash] Re: PR Problem?

Todd A. Jacobs wrote:


All a
hashcash header really proves is that:

    1. Someone was technically proficient enough to set it up, and

        1a someone was obsessive with the technique enough to set it up


    2. The system is originated from was not spewing mail at such high
       volumes that minting a stamp for each message was prohibitive.

I think #2 would be a show-stopper for server-side stamping at a busy
ISP, even if the mail was (generally) legitimate. Consider the
consequences of having a botnet start spewing mail from your customers'
systems, and your mail infrastructure happily minting stamps for them.
Either it will effectively create a DoS situation (bad for business and
sysadmin sanity), or your gi-normous mail server cluster filled with
8-way Xeon systems won't even notice (defeating the value of the
stamping process).

*That* is the main argument I have against server-side stamps: it shifts
the problem from low-end hardware where the minting makes the proof of
work expensive enough to be useful, and onto higher-end hardware where
the existence of minted stamps no longer really proves anything about
the originator.

I'm not saying server-side minting is always bad. But if you do that,
you need to implement some sort of per-user token bucket to ensure that
you're saying something useful about the original sender.


Very good points.  But there is another dimension which I think is
important that changes this somewhat.
1) if you are technically proficient enough to set up the first generation filters, setting up spam generation is probably about 30 minutes more work.
2) end node stamp generation while the appropriate place for the calculation, is also a very difficult place to gather enough information to know what size of stamp is needed by the other side and how to advertise what size stamp you want from a given address.[1] 

3) no matter what size machine, stamp generation will always slow you down.
4) and this is contentious, in your scenario about a botnet jamming up a machine, there are two important things I think you might be missing (forgive me if I'm wrong). 
        4a) you are slowing down the bot net traffic
        4b) you now have a really easy signal for detecting that a botnet is 
active
        4c) and with a signal, you can sidecar and isolate botnet  traffic
4d) ordinary users won't be affected because a proper queue for stamps would detect those that don't need stamps (again assuming hybrid environment) and deliver them posthaste.
this is also another argument for the captive zombie net model. server portion of the load back onto the users machine which would provide the end-user (and the ISP) a signal saying something isn't right. Let's check your machine out for zombies.
one of the things I discussed when I give a talk on proof of work systems is that it's not just the rate limiting factor that's important but also that it tends to produce a strong signal indicating an attack.
[1]Yes, I think it would be a good idea to have variable sized postage based on the message originator instead of blacklists. 



Okay, who knows Java and is willing to make a fast (only three X
slower) stamp generator?  I've often thought the same thing about a


Um, squirrelmail is written in PHP, not Java. Even if true, so what? By
definition, expensive stamps are more valuable. If your earlier point is
that server hardware should suck it up for end-users, and that service
providers can just throw more money or hardware at a centralization
problem, then what difference does it make if it takes .5 seconds or 3
seconds to mint a stamp? It's a scaling problem, no doubt about it, but
I think uptake problems have more to do with a lack of tools, and not
with the implementation details or efficiency of the back-end code.
Sorry. I was thinking about putting the spam generator in the browser in Java because that's typically only three to five times slower than native code versus JavaScript which is something like a hundred times slower 

http://jlcooke.ca/hashcash/
when you have this kind of performance differential, you are tempted to use smaller stamps. Not good.
Anyway, squirrel mail would generate a stamp in the browser using the Java applet while you are composing a message (background mode?) When you send a message, the stamp is attached and everybody is happy(er) 


generic "contact us" mailto.  can a mail-to include random headers in
a message?


Of course. See here:

    http://xml.resource.org/public/rfc/html/rfc2368.html#anchor2

so you could insert a URL into your mail forms, if you want:

    
mailto:foo@xxxxxxx?X-Hashcash:%201:20:061113:foo@xxxxxxxxxxx::tCXVpAsAD42tT+Gh:004bC6
wonderful. this means a browser could generate a stamp and then invoke the mail client with a stamp already ready. This could be used as a demonstration for "contact us" entries for webpages. all we need now is someone to generate the right and fast as possible Java applet. 



I'm saying that hashcash itself should when it checks the stamp. Failing
that, the filtering tool should be doing that, because you can't assume
that it's the last filter in the toolchain. For example,
postfix->procmail->tmda->bogofilter->procmail might be one example.
Where does hashcash get inserted? And who inserts the resulting header
into the mail? If hashcash itself adds the verification header after
checking a stamp, that would make the most sense to me
It looks like your description is of a received side chain. Hash cash would be injected prior to the first postfix. If a stamp is valid and present, the first procmail should detect that and abort processing in the rest of the chain if successful. Otherwise you process is normal. If you need the verification header into abort processing or otherwise modify it later on, then that's your own filter responsibilities, not that of anybody else. I think this falls in the category of filter philosophy.
Also, hashcache doesn't process the entire message. You just give it a stamp and it says thumbs up or thumbs down. It's all it should do except for maybe generate a standard header that you insert in a message. No sense in burdening it with a bunch of stuff that may get in the way that some other time.
ask me privately about how CRM 114 has gotten way too complicated by trying to do too much. 

---eric

Other related posts: