[hashcash] Re: PR Problem?

I apologize if my writing is a little more rough than usual. I'm into the 27th hour of a migraine. 

Todd A. Jacobs wrote:

On Sat, Nov 11, 2006 at 10:56:34PM -0500, Eric S. Johansson wrote:


then there is no "objection" to that system.  What appears to be the
most contentious is generating stamps.  Any stamps.  Without
addressing that objection, we won't get off of T0.


I'm not sure what the objection is there, unless it's from the mail
systems admins. See, I think the downside to sender-pays
stamp-generation at the MTA level is that, if you're a busy ISP and no
one else is using sender-pays, you basically reduce your available CPU
cycles for no discernable benefit.
that is one of the two arguments against naïve sender-pays as well as the source of the resistance by mail administrators. They cannot comprehend that one can apply a predicate to the stamp generation process and reduce unnecessary stamps. There is also an emotional reaction which is "why should I spend cycles so you can read my e-mail?" there is a bit of arrogance in that "why should I do anything for anybody else. I can just filter the spam out" while not recognizing that the filtering process actually contributes to the increase in spam.
The important aspect of deploying proof of work stamps is doing it in such a way that early adopters are not hurt but then it turns on automatically as adoption climbs hence my DNS-based predicate. 



*I* would run sender-pays from postfix if there were an easy way to do
it, but I don't push nearly the volume that a major ISP would. That's
why I think that *validating* at the MTA might be useful, but that the
stamps really should generally be minted by the MUA.
As soon as I publish my twopenny blue bzr repository, you will have all of the components you need to do that. I have postfix pre-and post-queuing capability, message queuing and even a message format which will record important data elements about the message as it comes in.
You're more than welcome to slice and dice them any way you see fit. although I think you'll mostly need postfix_stamper.py and all of its associated bits of code. one suggestion however, all of the traps and error checking are necessary because spammers write really crummy mail messages as a way of bypassing filters. 



Think about it this way: a spammer isn't going to install sender-pays,
and an ISP that is being used by a spammer essentially gets punished
twice if they have sender-pays on the server side. Just my $0.02, but
minting stamps really belongs in the MUA *unless* you have a dedicated
MTA for things like mailing lists or legitimate e-commerce.
I agree. But unless somebody's going to pull their thumb out and build a client-side proxy or plug-in, the best we've got right now is the various bits of work done by various people on this list. The really sad thing is we are very close to multiple good solutions for different people but for some reason, we're not able to step over the line to something finished.
But I would also suggest considering this when looking at the end user versus centralized service model. What is more work for a corporation or enterprise? Changing everybody's desktop or running a server performing the desired operation? Anyone who operates in enterprise environments will tell you, if they can do on a central server, they will do so because users are idiots and they don't want to have to deal with them any more than they have to.
ISPs on the other hand know their users are idiots and deal with them anyway. So if they are going to run a stamping service how do they convince the user base to upgrade their software to be able to run client-side stamping? The answer is they don't. They will just shrug and say the solution is unacceptable.
Now a middle ground might be the Zombie idea developed by Jonathan Morton. The Zombie is a stand-alone process that runs on a client machine and generates stamps. We can make it more secure than the classic zombie so they can't be taken over. The idea would be that the MTA meeting stamps would ask a zombie for a stamp. It really doesn't matter which zombie as long as the zombie is free. The stamp is generated at a leaf node and there is no excess load placed on the MTA.
The question is how do you secure the zombie engine and does this make the mail server a more valuable target of attack? Would it make sense to limit stamps generated? It's an interesting idea that is worth examining. It's also easy to deploy in the sense that the user is running a new piece of software and not changing what they know. Enterprise deployment is also easier because you make it part of your centralized startup script for your Windows boxes or on your under loaded servers. although I would suggest for enterprise deployment that the sales department funds their own mail server and spam generation capability.
But coming back to the load and hybrid issue. What I am seeing today in relatively small enterprises is roughly and under 5% of total message volume stamp generation rate. so you're looking at a relatively small number of stamps with the first generation of hybrid sender-pays. 


Since hybrid sender-pays can reduce the cost of generating stamps to
almost nothing and the DNS info propagation method proposed can reduce


Lots of people implemented SPF records, but I don't know a lot of people
who actually *use* them for filtering. There might be some, but I don't
know any of them personally.

But it *is* a good example of how to increase uptake: the SPF folks
created a web interface that made it trivial to create the appropriate
SPF records, which people could then plug into their DNS. I still think
that's beyond most end-users, but would be useful for a busy sysadmin
who was willing to implement such a feature but didn't have enough time
or interest to wrestle with the details.
Fair enough. That makes a lot of sense. SPF is not a useful antispam technique, it's a useful anti-forgery technique which merely limits one of the types of spam disguises. But I think your point of giving them the tools and let them just cut and paste the text record makes a lot of sense. 




one way to prove the lack of damage is to run an e-mail service.


Creating a hashcash plugin for squirrelmail might be a quick way to
generate some interest in that. Just a thought.
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 generic "contact us" mailto. can a mail-to include random headers in a message? 


if you want to have something like open PGP clear text signing, we
could create the equivalent of a multipart mime document in which one


Well, MIME attachments will increase the complexity and CPU cost of
inbound filtering. I think the correct thing to do is create filtering
mechanisms that can attach visible headers or mime attachments when a
stamp is authenticated. For example, bogofilter creates the X-Bogosity
headers that let you know what bogofilter thinks of the email, and MUAs
like mutt display the validity of PGP attachments or inlines in the
message body.
I'd leave the X-Hashcash header alone, but suggest having hashcash
itself create something like an X-Hashcash-Validated or
X-Hashcash-Result field, instead of requiring the end user to shell out
to something like procmail+hashcash+formail to generate one, because
that creates some instant complexity.
do not let the thoughts of procmail, pine or mutt even enter your head. Think Outlook first Thunderbird second. There is no third.
I'm still not getting this however. It may be the migraine and I'm being dim. It seems like what you're saying is that the filter should attach some sort of a mime trailer indicating success or failure of stamp analysis. 

Is this even close?


(maybe).  another advantage to multipart mime document form is
multi-parts stamps.  That instead of having a single 24-bit stamp, you
would use 16 20 bit stamps to reduce the variability of stamp search
time from message to message.


I'm not sure I follow that. How would that reduce CPU time?
It reduces time variability. A search for a hash cash stamp is a linear process. 2^(n-1) average search time but the distribution of search terms is pretty much random as far as I understand it. So sometimes they happen fast, sometimes they go very long. But if you do a series of much smaller searches adding up to the same number of bits as the larger search, that variability averages out. Not always but it's better than a single search variability. 

others can probably explain this better than I can.



One question would be what happens if you stand a gpg signed document?


I'm not sure I follow that either. What do you mean?
sorry about the speech recognition error. If you had a mime attachment for holding stamps, and you also signed the document with gpg, would gpg be able to cope with a document that had the stamps attached post-signing? 

---eric

Other related posts: