[hashcash] Re: hashcash-sendmail daemonizes better.
- From: Kyle Hasselbacher <kyle@xxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Sat, 12 Jun 2004 13:22:39 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Jun 12, 2004 at 09:52:30AM -0400, Adam Back wrote:
>I installed and am using it now. Seems to work. (Didn't have problem
>before either tho).
Glad to hear it. 8-)
>I am thinking of trying out the 2nd program hashcash-request.
I mainly use it for debugging. When hashcash-sendmail croaks and leaves a
queue with messages in it, sending in a hashcash-request is a decent way to
restart delivery.
>What I'm wondering is this: could one take previous sending (which
>hashcash-sendmail sees as it creates hashcash) as an indicator that
>you will send to that person again and put in
>eg. .hashcash/recipients. Next when a mail arrives (.procmailrc hook)
>with I suppose From, Reply-To, or Cc in this set (and procmail could
>probably do this) then call hashcash-request on receipt.
>
>Or other suggestions on how to hook hascash-request in so that it does
>not compute stamps for all incoming mail?
There was a teeny discussion of this a while back. Methods I remember are:
1. Manual. "I'm about to email Fred, I'll ask for a token before I start
so it's done when the email is ready." I do this rarely.
2. Preconfigured. Have a cron job cook the same tokens daily. "I email
hashcash@xxxxxxxxxxxxx an average of five times a day, therefore mint five
tokens every night around 1:00."
3. Assume replies. That's what you were saying 'bout a procmail hook.
When email arrives, make tokens for replies.
4. Heuristics. You could cook up all manner of complex guesswork. There's
a full log of everything you send (with other superfluous information) to
go on.
All of the above are possible with hashcash-request, but you have to write
the logic yourself. (They're "possible" in the sense that a mansion is
"possible" with a hammer.)
Example heuristics (still thinking of a daily cron job):
* For each address I've emailed in the last hundred days, mint for that
address a number of tokens equal to the number of times I've emailed it,
divided by some factor (say, 100).
* Look at the last N (say, 20) tokens you've minted, and mint those over
again.
Probably the best thing to do would be some combination of the above. If I
were doing this, I'd probably have a preconfigured set, and a heuristic or
two. It would be messy.
For me, though, I consider premade tokens something of a waste. Every time
I make one, there's a chance I'm not going to use it. In that sense, they
cost more than "sure thing" tokens made for actual messages. My processor
is weak. Having a premade token available GREATLY speeds delivery. On the
other hand, it's a BIG waste of CPU if I don't use them. If my CPU were
fast, it wouldn't be a big deal to premake (and waste) tokens, but then it
wouldn't be such a speed advantage either.
On the third hand, hashcash-request is made to be as low-impact as
possible. Premaking tokens won't hinder delivery of real messages, and it
always runs nice 19 to give other processes on the system as much
precedence as possible. The only down side is this scenario:
1. hashcash-request -r fred
2. Compose email to fred.
3. Hit 'send' before the hashcash is finished.
4. hashcash-sendmail uses the still-running process to get the token.
5. Oops, Fred waits for a 'nice 19' hashcash instead of the (faster) default.
If the system is busy, Fred might wait LONGER for the email than if I
hadn't tried to premake a token at all.
Anyway, that's my thoughts on that.
My personal "future directions of hashcash-sendmail" focus right now is
"enlist the help of other computers." I have four x86 machines here,
totaling just a bit over 1GHz in clock rates. It'd be nice to get them to
work together somewhat when my queue gets big.
- --
Kyle Hasselbacher | Life may have no meaning. Or even worse, it may have
kyle@xxxxxxxxxxx | a meaning of which I disapprove. -- Ashleigh Brilliant
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAy0nv10sofiqUxIQRAuRqAKDI8/2wR1m7AUTiNZdyEC893JIJ1wCcCI1+
4xT711oR17lnhO6KR9ozYHY=
=6xJr
-----END PGP SIGNATURE-----
Other related posts: