[hashcash] Re: PR Problem?
- From: "Todd A. Jacobs" <nospam@xxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Sun, 12 Nov 2006 14:09:31 -0800
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.
*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.
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.
> 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.
> 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.
> 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.
> (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?
> 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?
--
Unabashedly littering the information superhighway with detritus like
this for over 15 years now.
Other related posts: