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:[email protected]?X-Hashcash:%201:20:061113:[email protected]::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