[hashcash] Re: PR Problem?
- From: "Todd A. Jacobs" <nospam@xxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Mon, 13 Nov 2006 13:49:47 -0800
On Mon, Nov 13, 2006 at 09:43:22AM -0500, Eric S. Johansson wrote:
> 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]
Well, ideally this is where hybrid systems with DNS records and such
would come into play, but in a more realistic and practical system I
think one just defines a best-practice. That's why I tossed the idea of
basing the "standard policy" on the number of addresses in the mail out
there: because the MUA *does* know how many addresses are involved.
Granted, that doesn't mean the destined recipients will check, but if
they did they should probably be following the "recommended standards,"
whatever they end up being.
> 3) no matter what size machine, stamp generation will always slow you
> down.
True.
> 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.
You keep assuming "hybrid environment," whatever that means, but I don't
think that's currently a practical real-world scenario. Real-world, you
aren't slowing down the botnets, you're busting the performance of an
ISP or e-commerce server.
Statistics claim that 80% of all email traffic is spam. Well, if you're
an ISP, you want to track botnets by spam volume (e.g. reading your
logs), not by seeing which server has just crashed because its CPU is
pegging out at 100%.
Slow-minting is a selling point to *recipients*, not senders. So, if you
want centralized minting, you have to come up with a better slogan than
"we'll crash your servers if your users are sending spam." :)
> 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
Yes. That would allow a policy daemon to verify stamps outbound, too,
which *would* be a win from an ISP or enterprise point of view.
> present, the first procmail should detect that and abort processing in
> the rest of the chain if successful. Otherwise you process is normal.
See, that's sort of my point. I'm not sure that hashcash should assume
it is the final arbiter of what is or isn't spam. I realize that at
present all it does is mint or verify hashcash stamps; I just think it
should be hashcash's job to append or validate the RFC 822 headers in
filtering mode.
If you want to talk Unix philosophy (one tool, one job) that's a
different conversation--although most Unix tools are capable of being
used directly in a pipeline wile hashcash can't . But if the question is
"Why don't more people implement this as part of their toolchain," I
think that the inability to simply drop it in as a filter (in the sense
of filter-processing, not mailbox filtering) is part of the reason.
> 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.
Yes and no. Most tools, including bogofilter, spamassassin, and even
procmail support the idea of acting as a pass-through filter and provide
error codes and header modification (although in procmail's case you
have to shell out to formail for the latter). I'm *not* saying that
hashcash should decide what to do with an email; I'm saying that it
*should* be able to mark an email as containing a valid or invalid
stamp.
--
Unabashedly littering the information superhighway with detritus like
this for over 15 years now.
Other related posts:
