hashcash

hashcash

[Adam Sjøgren]

I just turned hashcash-stuff on in Gnus (one of my friends started
using it).

In spam.el I noticed this:

 ;; TODO: does anyone use hashcash?  We should remove it if not.

so, my answer to that question is "Yes".


It looks like generating a hashcash works well - the SpamAssasin in
the other end recognizes the postage.


I'm not sure that the checking of a hashcash in contrib/hashcash.el
does - can anyone confirm/deny this?

From stepping through hashcash-verify-payment, I think the included
patch is needed.

(An example: the token:
"1:20:040926:asjo@koldfront.dk::e9a9d8c29f7c1806:ea6e" is split on
":", and the key should be my email-adresse (number 3, zero-indexed
counting, not number 2) - hashcash.el seems to not know about the
bit-field ('20' in the example)...)

Someone who know this better should probably say whether it's okay...
it would probably be better to fix hashcash-version if the version 1.2
that is referred to in hashcash.el is in use (hashcash.org doesn't
mention that format).


*** hashcash.el	21 May 2004 00:16:54 -0000	7.3
--- hashcash.el	26 Sep 2004 15:16:15 -0000
***************
*** 137,143 ****
    "Verify a hashcash payment"
    (let ((key (if (< (hashcash-version token) 1.2)
  		 (nth 1 (split-string token ":"))
! 		 (nth 2 (split-string token ":")))))
      (cond ((null resource)
  	   (let ((elt (assoc key hashcash-accept-resources)))
  	     (and elt (hashcash-check-payment token (car elt)
--- 137,143 ----
    "Verify a hashcash payment"
    (let ((key (if (< (hashcash-version token) 1.2)
  		 (nth 1 (split-string token ":"))
! 		 (nth 3 (split-string token ":")))))
      (cond ((null resource)
  	   (let ((elt (assoc key hashcash-accept-resources)))
  	     (and elt (hashcash-check-payment token (car elt)


-- 
 "This is either madness... or brilliance."                   Adam Sjøgren
 "It's remarkable how often those two traits coincide."  asjo@koldfront.dk

Re: hashcash

[Simon Josefsson]

asjo@koldfront.dk (Adam Sjøgren) writes:

> I'm not sure that the checking of a hashcash in contrib/hashcash.el
> does - can anyone confirm/deny this?

I haven't tried it.

> From stepping through hashcash-verify-payment, I think the included
> patch is needed.
>
> (An example: the token:
> "1:20:040926:asjo@koldfront.dk::e9a9d8c29f7c1806:ea6e" is split on
> ":", and the key should be my email-adresse (number 3, zero-indexed
> counting, not number 2) - hashcash.el seems to not know about the
> bit-field ('20' in the example)...)
>
> Someone who know this better should probably say whether it's okay...
> it would probably be better to fix hashcash-version if the version 1.2
> that is referred to in hashcash.el is in use (hashcash.org doesn't
> mention that format).

I think your string is a new format, not supported by hashcash.el.  Is
your format supported by SpamAssassin?  Do you know of a reference to
the new format?  Maybe we can fix hashcash.el to support it as well.

I'm CC:ing Paul Foley in case he knows more of the new format.  Btw,
Paul, have you assigned the copyright of hashcash.el to the FSF?  Are
you willing to do so?  I think it would be useful to move hashcash.el
from contrib/ to lisp/, but we can't do that unless papers are signed.

Re: hashcash

[Adam Sjøgren]

On Sun, 26 Sep 2004 19:36:30 +0200, Simon wrote:

>> Someone who know this better should probably say whether it's
>> okay... it would probably be better to fix hashcash-version if the
>> version 1.2 that is referred to in hashcash.el is in use
>> (hashcash.org doesn't mention that format).

> I think your string is a new format, not supported by hashcash.el. 
> Is your format supported by SpamAssassin?

It recognizes it, at least that is how I read the log-entries for
email with X-Hashcash:

 Sep 26 16:59:58 virgil spamd[24419]: result: . -2 - AWL,BAYES_00,HASHCASH_20 scantime=0.2,size=27715,mid=<20040926145956.GC17305@magnetic-ink.dk>,bayes=0,autolearn=ham 

> Do you know of a reference to the new format?

Yes: <http://www.hashcash.org/docs/hashcash.html#stamp_format__version_1_>

(There is no reference there to the format that hashcash.el calls 1.2,
that is what was confusing to me).

> Maybe we can fix hashcash.el to support it as well.

That was what I was thinking (above).


  Best regards,

-- 
 "Commandeer! We're going to 'commandeer' that ship.          Adam Sjøgren
  Nautical term."                                        asjo@koldfront.dk

Re: hashcash

[Paul Foley]

On Sun, 26 Sep 2004 22:59:19 +0200, Adam Sjøgren wrote:

> (There is no reference there to the format that hashcash.el calls 1.2,
> that is what was confusing to me).

Yeah; sorry about that.  Until about mid-2002, hashcash changed
formats twice, but there was no indication of the format version in
the hashcash token itself, and I didn't know whether it would change
again, or whether it would always be possible to tell what version you
had just from looking at the stamp, so I invented a version number for
it; hashcash.el calls for the original 1997 format version 1.0, the
later version with the colons version 1.1, and what Adam called
"version 0" version 1.2.  As of (Adam's) version 0, hashcash tokens
contain their own version number, so there's no need to change the
1.2; just add support for recognising the version number in the token.

My local copy has had support for "version 1" stamps since they were
announced, but I forgot to update my web site since my CVS server had
a disk failure and was down at the time.  I'll correct that right now:
http://users.actrix.co.nz/mycroft/hashcash.el


Simon: I assigned copyright to the FSF about 18 months ago, when you
first asked me to.

-- 
Malum est consilium quod mutari non potest             -- Publilius Syrus

(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

Re: hashcash

[Simon Josefsson]

Paul Foley <mycroft@actrix.gen.nz> writes:

> My local copy has had support for "version 1" stamps since they were
> announced, but I forgot to update my web site since my CVS server had
> a disk failure and was down at the time.  I'll correct that right now:
> http://users.actrix.co.nz/mycroft/hashcash.el
>
> Simon: I assigned copyright to the FSF about 18 months ago, when you
> first asked me to.

Thanks.  I have moved hashcash.el from contrib/ to lisp/, and updated
it to your latest version.  It would facilitate future syncing if you
could apply the patch below to your version as well.

Adam, does the new version solve your problems?

--- hashcash.el 2004-09-27 03:52:27.000000000 +0200
+++ /home/jas/gnus/lisp/hashcash.el     2004-09-27 16:29:41.000000000 +0200
@@ -1,14 +1,27 @@
 ;;; hashcash.el --- Add hashcash payments to email

-;; $Revision: 1.13 $
 ;; Copyright (C) 1997--2002 Paul E. Foley
 ;; Copyright (C) 2003 Free Software Foundation

 ;; Maintainer: Paul Foley <mycroft@actrix.gen.nz>
 ;; Keywords: mail, hashcash

-;; Released under the GNU General Public License
-;;   (http://www.gnu.org/licenses/gpl.html)
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 2, or (at your option)
+;; any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.         See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs; see the file COPYING.  If not, write to the
+;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+;; Boston, MA 02111-1307, USA.

 ;;; Commentary:

@@ -217,3 +230,5 @@
        ok))))

 (provide 'hashcash)
+
+;;; arch-tag: 0e7fe983-a124-4392-9788-0dbcbd2c4d62

Re: hashcash

[Adam Sjøgren]

On Mon, 27 Sep 2004 14:03:56 +1200, Paul wrote:

> My local copy has had support for "version 1" stamps since they were
> announced, but I forgot to update my web site since my CVS server
> had a disk failure and was down at the time. I'll correct that right
> now: http://users.actrix.co.nz/mycroft/hashcash.el

Great - thanks!

(I think the comment in hashcash-version could use an update
describing the change from Adam Back's "version 0" to "version 1"
above hashcash.el's description of it's version 1.2 - what do you
think?)


Oh, another thing: there is a script for mutt called
"hashcash-sendmail"¹ that apparantly appends six or so trailing spaces
to the X-Hashcash: [stamp]-header (a friend of mine uses it, and I get
those from him).

hashcash.el sends those along to the hashcash-binary which then
rejects the stamp.

In my local copy of hashcash.el I've worked around this by doing this:

--- hashcash.el.orig	2004-09-27 03:52:27.000000000 +0200
+++ hashcash.el	2004-09-27 16:30:59.000000000 +0200
@@ -211,7 +211,7 @@
 	      (setq ok (hashcash-verify-payment (cadr value))))))
 	(goto-char (point-min))
 	(while (and (not ok) (search-forward "X-Hashcash: " end t))
-	  (setq ok (hashcash-verify-payment (hashcash-token-substring))))
+	  (setq ok (hashcash-verify-payment (replace-in-string (hashcash-token-substring) " " ""))))
 	(when ok
 	  (message "Payment valid"))
 	ok))))

If there's a cleaner/better way/place to do it, it should probably be
done in hashcash.el proper.


  Best wishes,

    Adam

¹ <http://www.hashcash.org/mail/mua/hc-sendmail/>
  <http://www.toehold.com/~kyle/hashcash/>

-- 
 "Stop blowing holes in my ship!"                             Adam Sjøgren
                                                         asjo@koldfront.dk

Re: hashcash

[Adam Sjøgren]

On Mon, 27 Sep 2004 16:32:49 +0200, Simon wrote:

> Adam, does the new version solve your problems?

Yes.

Much thanks to both of you.


  Best regards,

-- 
 "Stop blowing holes in my ship!"                             Adam Sjøgren
                                                         asjo@koldfront.dk

Re: hashcash

[Simon Josefsson]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Oh, another thing: there is a script for mutt called
> "hashcash-sendmail"¹ that apparantly appends six or so trailing spaces
> to the X-Hashcash: [stamp]-header (a friend of mine uses it, and I get
> those from him).

hashcash.el should definitely not care about white space in header
fields...

> -	  (setq ok (hashcash-verify-payment (hashcash-token-substring))))
> +	  (setq ok (hashcash-verify-payment (replace-in-string (hashcash-token-substring) " " ""))))

...however, replace-in-string is XEmacs specific.

Re: hashcash

[Adam Sjøgren]

On Mon, 27 Sep 2004 17:21:37 +0200, Simon wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:
>> Oh, another thing: there is a script for mutt called
>> "hashcash-sendmail"¹ that apparantly appends six or so trailing
>> spaces to the X-Hashcash: [stamp]-header (a friend of mine uses it,
>> and I get those from him).

> hashcash.el should definitely not care about white space in header
> fields...

(The author of hashcash-sendmail says it's the hashcash-binary that
puts the extra whitespace there, so my "blame" above was placed
incorrectly.)

>> (setq ok (hashcash-verify-payment (replace-in-string
>> (hashcash-token-substring) " " ""))))

> ...however, replace-in-string is XEmacs specific.

My elisp-vocabulary is unfortunately very limited, and my list of
common elisp-idioms is even shorter, so I don't know what the nice way
to strip trailing space is in elisp. Yet.


  :-),

-- 
 "Kanske ett tips till hiphoppare som inte får ihop           Adam Sjøgren
  sina 'rhymes' - börja rimma på teckenspråk!"           asjo@koldfront.dk

Re: hashcash

[Ted Zlatanov]

On Sun, 26 Sep 2004, asjo@koldfront.dk wrote:

> I just turned hashcash-stuff on in Gnus (one of my friends started
> using it).
> 
> In spam.el I noticed this:
> 
>  ;; TODO: does anyone use hashcash?  We should remove it if not.
> 
> so, my answer to that question is "Yes".

Now that SpamAssassin includes it, it will probably be more popular.
Before, I had very little feedback about the spam-use-hashcash
backend.  I'll take the comment out when I make the next commit.

Ted

Re: hashcash

[Jesper Harder]

asjo@koldfront.dk (Adam Sjøgren) writes:

> On Mon, 27 Sep 2004 17:21:37 +0200, Simon wrote:
>
>>> (setq ok (hashcash-verify-payment (replace-in-string
>>> (hashcash-token-substring) " " ""))))
>
>> ...however, replace-in-string is XEmacs specific.
>
> My elisp-vocabulary is unfortunately very limited, and my list of
> common elisp-idioms is even shorter, so I don't know what the nice way
> to strip trailing space is in elisp. Yet.

It's `replace-regexp-in-string' in Emacs¹ -- you can use
`gnus-replace-in-string' as a compatibility function which works in
both flavours.

¹ A slightly better name, IMHO, since it isn't obvious that it works
with regexps from the XEmacs name.
-- 
Jesper Harder                                <http://purl.org/harder/>

Re: hashcash

[Adam Sjøgren]

On Mon, 27 Sep 2004 19:13:15 +0200, Jesper wrote:

> It's `replace-regexp-in-string' in Emacs¹ -- you can use
> `gnus-replace-in-string' as a compatibility function which works in
> both flavours.

Ah, thanks.

I couldn't work out how to incorporate trailing-slash-removal in
hashcash-token-substring, so I did this (questionable?) thing instead:

 (defun hashcash-token-substring ()
+  (gnus-replace-in-string (hashcash-token-substring-unfold) " +$" ""))
+
+(defun hashcash-token-substring-unfold ()
   (save-excursion
     (let ((token ""))
       (loop
 	(setq token
 	  (concat token (buffer-substring (point) (hashcash-point-at-eol))))
 	(goto-char (hashcash-point-at-eol))
 	(forward-char 1)
 	(unless (looking-at "[ \t]") (return token))
 	(while (looking-at "[ \t]") (forward-char 1))))))


  Thanks for the input,

-- 
 "Och jag säger som Jennifer Lopez: Utan mina pärmar          Adam Sjøgren
  hade det blivit oordning!"                             asjo@koldfront.dk

Re: hashcash

[Simon Josefsson]

asjo@koldfront.dk (Adam Sjøgren) writes:

> On Mon, 27 Sep 2004 19:13:15 +0200, Jesper wrote:
>
>> It's `replace-regexp-in-string' in Emacs¹ -- you can use
>> `gnus-replace-in-string' as a compatibility function which works in
>> both flavours.
>
> Ah, thanks.
>
> I couldn't work out how to incorporate trailing-slash-removal in
> hashcash-token-substring, so I did this (questionable?) thing instead:
>
>  (defun hashcash-token-substring ()
> +  (gnus-replace-in-string (hashcash-token-substring-unfold) " +$" ""))
> +
> +(defun hashcash-token-substring-unfold ()

Then hashcash.el will have to depend on Gnus... perhaps it is cleaner
to use replace-regexp-in-string?

Why would you want to remove a trailing slash?

Re: hashcash

[Adam Sjøgren]

On Mon, 27 Sep 2004 21:38:33 +0200, Simon wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:

>> I couldn't work out how to incorporate trailing-slash-removal in
>> hashcash-token-substring, so I did this (questionable?) thing
>> instead:

>> (defun hashcash-token-substring () + (gnus-replace-in-string
>> (hashcash-token-substring-unfold) " +$" ""))
>> +
>> +(defun hashcash-token-substring-unfold ()

> Then hashcash.el will have to depend on Gnus... perhaps it is
> cleaner to use replace-regexp-in-string?

Maybe I misunderstood Jesper Harder, but does function that exist in
XEmacs?

Maybe I should learn how to shave of those spaces using some other
construct :-)

> Why would you want to remove a trailing slash?

Thinko. "trailing space(s)" was what I meant.


  Best regards,

-- 
 "Och jag säger som Jennifer Lopez: Utan mina pärmar          Adam Sjøgren
  hade det blivit oordning!"                             asjo@koldfront.dk

Re: hashcash

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> Then hashcash.el will have to depend on Gnus... perhaps it is cleaner
> to use replace-regexp-in-string?

But then it won't work in XEmacs :-)  Better to copy the definition
from gnus-util.el and call it, say, hashcash-replace-in-string.

-- 
Jesper Harder                                <http://purl.org/harder/>

Re: hashcash

[Simon Josefsson]

Jesper Harder <harder@ifa.au.dk> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Then hashcash.el will have to depend on Gnus... perhaps it is cleaner
>> to use replace-regexp-in-string?
>
> But then it won't work in XEmacs :-)  Better to copy the definition
> from gnus-util.el and call it, say, hashcash-replace-in-string.

Ah, right.  Or hashcash-replace-regexp-in-string. ;-)

Perhaps we can add a compatibility function replace-regexp-in-string
to XEmacs?  Seems like a better name, and it is starting to be widely
known.

Re: hashcash

[Ted Zlatanov]

I modified hashcash.el to fail gracefully (with a message) if the
hashcash-path is nil.  I didn't use gnus-error because I got the
impression no one wants to make hashcash.el dependent on Gnus, so
instead it's a (message) and then (sleep-for 1).

I hope that's OK with everyone.

Ted

Re: hashcash

[Simon Josefsson]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> I modified hashcash.el to fail gracefully (with a message) if the
> hashcash-path is nil.  I didn't use gnus-error because I got the
> impression no one wants to make hashcash.el dependent on Gnus, so
> instead it's a (message) and then (sleep-for 1).

I changed it to use `error' instead.  The code isn't used unless the
user specifically asked for it, and it that case it might as well stop
if the user made an error.

Feel free to revert or change again.

Oh. But maybe that's bad for verification?  Yes.  I reverted it
partially, so now hashcash-generate-payment will throw an error if the
binary doesn't exist, while hashcash-check-payment will display a
message and sleep.

Feel free to revert or change again.

Re: hashcash

[Ted Zlatanov]

On Tue, 28 Sep 2004, jas@extundo.com wrote:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
> 
>> I modified hashcash.el to fail gracefully (with a message) if the
>> hashcash-path is nil.  I didn't use gnus-error because I got the
>> impression no one wants to make hashcash.el dependent on Gnus, so
>> instead it's a (message) and then (sleep-for 1).
> 
> I changed it to use `error' instead.  The code isn't used unless the
> user specifically asked for it, and it that case it might as well stop
> if the user made an error.
> 
> Feel free to revert or change again.
> 
> Oh. But maybe that's bad for verification?  Yes.  I reverted it
> partially, so now hashcash-generate-payment will throw an error if the
> binary doesn't exist, while hashcash-check-payment will display a
> message and sleep.
> 
> Feel free to revert or change again.

I think error on generate, but warning on checking is the right way to
go.

Thanks!
Ted

Re: hashcash

[Dan Christensen]

Simon Josefsson <jas@extundo.com> writes:

> Thanks.  I have moved hashcash.el from contrib/ to lisp/

The hashcash info page needs a minor update too.  It says:

   The `hashcash.el' library can be found in the Gnus development
  contrib directory or at ...

Dan

Re: hashcash

[Ted Zlatanov]

On Wed, 29 Sep 2004, jdc@uwo.ca wrote:

> Simon Josefsson <jas@extundo.com> writes:
> 
>> Thanks.  I have moved hashcash.el from contrib/ to lisp/
> 
> The hashcash info page needs a minor update too.  It says:
> 
>    The `hashcash.el' library can be found in the Gnus development
>   contrib directory or at ...

I did that, plus a few other small fixes (the variable hashcash-path
was incorrectly listed as hashcash and hashcash.el can now check
payments).

Ted

Re: hashcash

[Dan Christensen]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> I did that, plus a few other small fixes (the variable hashcash-path
> was incorrectly listed as hashcash and hashcash.el can now check
> payments).

Cool.  Has anyone considering getting gnus to generate the hashcash
asynchronously while the message is being edited?  I think that if
this was done, *many* more people would start using hashcash (and with
higher payments)...

Gnus could check every minute whether the To or Cc lists had changed,
and if so, start generating payments.  

A nice feature would be that if nothing has changed, gnus could try
generating higher payments.  So the more time you spend writing a
message, the higher the payment!

Dan

Re: hashcash

[Magnus Henoch]

Dan Christensen <jdc@uwo.ca> writes:

> Cool.  Has anyone considering getting gnus to generate the hashcash
> asynchronously while the message is being edited?  I think that if
> this was done, *many* more people would start using hashcash (and with
> higher payments)...

I did, once, and made an own version of hashcash.el: (might need syncing)
http://stor.no-ip.org/~magnus/hashcash.el

> Gnus could check every minute whether the To or Cc lists had changed,
> and if so, start generating payments.  
>
> A nice feature would be that if nothing has changed, gnus could try
> generating higher payments.  So the more time you spend writing a
> message, the higher the payment!

That's interesting features... I never got around to do that; I would
just specify the number of bits to generate when starting to write the
message based on manual estimate.

Magnus

Re: hashcash

[Ted Zlatanov]

On Wed, 29 Sep 2004, mange@freemail.hu wrote:

> Dan Christensen <jdc@uwo.ca> writes:
> 
>> Cool.  Has anyone considering getting gnus to generate the hashcash
>> asynchronously while the message is being edited?  I think that if
>> this was done, *many* more people would start using hashcash (and with
>> higher payments)...
> 
> I did, once, and made an own version of hashcash.el: (might need syncing)
> http://stor.no-ip.org/~magnus/hashcash.el

Are your papers on file with the FSF?  If not, we can't use your code
(we'd have to rewrite it).

>> Gnus could check every minute whether the To or Cc lists had changed,
>> and if so, start generating payments.  
>>
>> A nice feature would be that if nothing has changed, gnus could try
>> generating higher payments.  So the more time you spend writing a
>> message, the higher the payment!
> 
> That's interesting features... I never got around to do that; I would
> just specify the number of bits to generate when starting to write the
> message based on manual estimate.

I don't think this is incredibly important, but if you have the time
to work on it... :)  I'd rather have simple background generation working.

Ted

Re: hashcash

[Magnus Henoch]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> Are your papers on file with the FSF?  If not, we can't use your code
> (we'd have to rewrite it).

Ah, no, I have no papers at all...  It was a quick hack; shouldn't
take long to reach that functionality.

Magnus

Re: hashcash

[Simon Josefsson]

There is a variable to toggle hashcash generation in message now:

** Gnus now support the "hashcash" client puzzle anti-spam idea.  See
the Gnus manual, section Hashcash, for more information.  Use (setq
message-generate-hashcash t) to enable.

`message-generate-hashcash'
     Boolean variable that indicate whether `X-Hashcash' headers should
     be computed for the message.  *Note Hashcash: (gnus)Hashcash.

Re: hashcash

[Ted Zlatanov]

On Thu, 30 Sep 2004, jas@extundo.com wrote:

> There is a variable to toggle hashcash generation in message now:
> 
> ** Gnus now support the "hashcash" client puzzle anti-spam idea.  See
> the Gnus manual, section Hashcash, for more information.  Use (setq
> message-generate-hashcash t) to enable.

After using hashcash on systems with and without the hashcash binary,
I think the sending error (when hashcash is missing) should be changed
to a warning and sit-for 1.  The user can't override the error
otherwise to send mail, and has to manually set hashcash-path to nil.

Ted

Re: hashcash

[Simon Josefsson]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> After using hashcash on systems with and without the hashcash binary,
> I think the sending error (when hashcash is missing) should be changed
> to a warning and sit-for 1.

But why did you enable hashcash generation, if you don't have the
binary?  If you are using the same .emacs on several systems, some
with a hashcash binary, and some without, it seems the proper .emacs
setting would be:

(setq message-generate-hashcash (executable-find "hashcash"))

> The user can't override the error otherwise to send mail, and has to
> manually set hashcash-path to nil.

I'm not sure I agree with this view.  It seems the user already
overrode the default behavior when she request hashcash in the first
place.  So she could revert to the default behavior by disabling it:

M-x set-variable RET message-generate-hashcash RET nil RET

I think this is comparable to other features: User requests PGP, but
PGP doesn't exist => error.  User requests spell check, aspell doesn't
exist => error.  User attaches a file, but file doesn't exist when
message is sent => error.  I feel that replacing all these errors,
including the hashcash one, with a warning would be confusing.

But if you think your view is more user friendly, then change it.

Thanks.

Re: hashcash

[Dan Christensen]

Simon Josefsson <jas@extundo.com> writes:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
>
>> After using hashcash on systems with and without the hashcash binary,
>> I think the sending error (when hashcash is missing) should be changed
>> to a warning and sit-for 1.
>
> But why did you enable hashcash generation, if you don't have the
> binary? 

I think we should aim to have things work as well as possible with as
little customization as possible.  In fact, if we get background
generation of hashcash working, then I'd argue that it should be
enabled by default, if the binary is present.

Dan

Re: hashcash

[Ted Zlatanov]

On Mon, 04 Oct 2004, jas@extundo.com wrote:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
> 
>> After using hashcash on systems with and without the hashcash binary,
>> I think the sending error (when hashcash is missing) should be changed
>> to a warning and sit-for 1.
> 
> But why did you enable hashcash generation, if you don't have the
> binary?  If you are using the same .emacs on several systems, some
> with a hashcash binary, and some without, it seems the proper .emacs
> setting would be:
> 
> (setq message-generate-hashcash (executable-find "hashcash"))

How about:

(defcustom message-generate-hashcash (executable-find "hashcash")
  "*Whether to generate X-Hashcash: headers.
You must have the \"hashcash\" binary installed, see `hashcash-path'."
  :group 'message-headers
  :link '(custom-manual "(message)Mail Headers")
  :type 'boolean)

(it's nil by default now)

But then what if users don't want to generate it?  I'm not sure what's
the right way to proceed.  Maybe there should be these extra
possibilities: (shorter names will probably be needed)

- enable-when-hashcash-binary-in-path
- enable-when-hashcash-binary-in-path-and-fast-machine [but how do we
  know this?]
- ask-to-enable-when-hashcash-binary-in-path [default?]

It seems like we should encourage hashcash generation in order to make
Gnus mail less likely to be tagged as spam - I see this as a service
to the users.  On the other hand it will slow down an already slow
process (sending mail, which often does extra network I/O anyway).

>> The user can't override the error otherwise to send mail, and has to
>> manually set hashcash-path to nil.
> 
> I'm not sure I agree with this view.  It seems the user already
> overrode the default behavior when she request hashcash in the first
> place.  So she could revert to the default behavior by disabling it:
> 
> M-x set-variable RET message-generate-hashcash RET nil RET

My particular problem was that I was doing it the old way with a hook
so I had to remove-hook :) I think you are right, generally speaking,
I was just blinded by my experience.

Ted

Re: Hashcash

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> Calling external SHA1 will be too slow (it loops many times), but
> maybe looping a elisp sha1 in the idle-timer could work (every loop is
> short and it can be resumed fast).

Is there a SHA1 implementation in Emacs Lisp?  Hm, yes, I remember
some talk about that...

> Perhaps the simplest thing is to disable hashcash in Gnus if the
> external "hashcash" binary isn't installed, and to enable it if it
> is present, though.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Hashcash

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>>> Also, the posting code seems to be synchronous.  I think it would be
>>> nice to put the hashcash generation in the background, and postpone
>>> the sending until the message has been hashcashed.  Has anybody done
>>> any work in that area?  Could, perhaps, the delayed nndrafts code be
>>> used for that?
>>
>> Sounds like a good idea.  We'd might as well write a complete elisp
>> implementation of it, since it justs loop over a SHA-1 computation.
>
> But if we do it in Emacs Lisp, will we be able to do it
> asynchronously?  Hm, perhaps -- is it just running an external SHA-1
> program repeatedly?  Then it can be done with process sentinels, I
> guess...

Calling external SHA1 will be too slow (it loops many times), but
maybe looping a elisp sha1 in the idle-timer could work (every loop is
short and it can be resumed fast).  Perhaps the simplest thing is to
disable hashcash in Gnus if the external "hashcash" binary isn't
installed, and to enable it if it is present, though.

Re: Hashcash

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> I lobbied for this in SpamAssassin, and there are patches available,
> but nothing seems to happen.  They seemed to want to wait for a
> standard to emerge, which seemed very backwards to what SA is all
> about to me, but anyway.

Yup.  :-)

>> Also, the posting code seems to be synchronous.  I think it would be
>> nice to put the hashcash generation in the background, and postpone
>> the sending until the message has been hashcashed.  Has anybody done
>> any work in that area?  Could, perhaps, the delayed nndrafts code be
>> used for that?
>
> Sounds like a good idea.  We'd might as well write a complete elisp
> implementation of it, since it justs loop over a SHA-1 computation.

But if we do it in Emacs Lisp, will we be able to do it
asynchronously?  Hm, perhaps -- is it just running an external SHA-1
program repeatedly?  Then it can be done with process sentinels, I
guess...

Then sending could basically be:

1) Put the message in the draft buffer

2) Compute the payment in the background

3) Insert the payment and send it

If the user quits Gnus/Emacs before the payment has been computed,
the message will remain in the draft group, which might be annoying,
but probably not a major problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Hashcash

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> There doesn't seem to be any code in there to verify the hashcash
> payment.  Does anybody have anything for doing that?

I lobbied for this in SpamAssassin, and there are patches available,
but nothing seems to happen.  They seemed to want to wait for a
standard to emerge, which seemed very backwards to what SA is all
about to me, but anyway.

I noticed that Lars updated Gnus' hashcash.el from upstream that has
verify functions, but it seems XEmacs specific, and it didn't work in
incomming mail buffers with RFC 822 body separators.  Patch attached;
Paul do you think it is OK?

> Also, the posting code seems to be synchronous.  I think it would be
> nice to put the hashcash generation in the background, and postpone
> the sending until the message has been hashcashed.  Has anybody done
> any work in that area?  Could, perhaps, the delayed nndrafts code be
> used for that?

Sounds like a good idea.  We'd might as well write a complete elisp
implementation of it, since it justs loop over a SHA-1 computation.

--- hashcash.el.~1.6~	Thu Jan  2 17:52:32 2003
+++ hashcash.el	Thu Jan  2 19:28:44 2003
@@ -37,11 +37,19 @@
   "*The default minimum number of bits to accept on incoming payments."
   :type 'integer)
 
-(defcustom hashcash-accept-resources `((,(user-mail-address) nil))
+(defcustom hashcash-accept-resources `((,(if (fboundp 'user-mail-address)
+					     (user-mail-address)
+					   user-mail-address) . nil))
   "*An association list mapping hashcash resources to payment amounts.
 Resources named here are to be accepted in incoming payments.  If the
 corresponding AMOUNT is NIL, the value of `hashcash-default-accept-payment'
-is used instead.")
+is used instead."
+  :type '(repeat (cons (string)
+		       (choice (const :tag "Default" nil)
+			       (const :tag "20 bits" 20)
+			       (const :tag "25 bits" 25)
+			       (const :tag "30 bits" 30)
+			       (integer)))))
 
 (defcustom hashcash "/usr/local/bin/hashcash"
   "*The path to the hashcash binary.")
@@ -93,11 +101,19 @@
 
 (defun hashcash-check-payment (token str val)
   "Check the validity of a hashcash payment."
-  (zerop (call-process hashcash nil nil nil "-c"
+  (zerop (save-excursion
+	   (set-buffer (get-buffer-create " *hashcash verify*"))
+	   (erase-buffer)
+	   (insert (format "%s -c -d -f %s -b %s -r %s %s\n"
+			   hashcash hashcash-double-spend-database
+			   (number-to-string val) str token))
+	   ;; hashcash uses isatty() to set -quiet flag, so we don't
+	   ;; see anything. process-connection-type doesn't help.
+	   (call-process hashcash nil t nil "-c"
 		       "-d" "-f" hashcash-double-spend-database
 		       "-b" (number-to-string val)
 		       "-r" str
-		       token)))
+			 token))))
 
 ;;;###autoload
 (defun hashcash-insert-payment (arg)
@@ -112,14 +128,16 @@
 ;;;###autoload
 (defun hashcash-verify-payment (token &optional resource amount)
   "Verify a hashcash payment"
-  (let ((key (cadr (split-string-by-char token ?:))))
+  (let ((key (caddr (split-string token ":"))))
     (cond ((null resource)
 	   (let ((elt (assoc key hashcash-accept-resources)))
-	     (and elt (hashcash-check-payment token (car elt)
-			(or (cadr elt) hashcash-default-accept-payment)))))
+	     (and elt (hashcash-check-payment
+		       token (car elt)
+		       (or (cdr elt) hashcash-default-accept-payment)))))
 	  ((equal token key)
 	   (hashcash-check-payment token resource
-				(or amount hashcash-default-accept-payment)))
+				   (or amount
+				       hashcash-default-accept-payment)))
 	  (t nil))))
 
 ;;;###autoload
@@ -159,7 +177,8 @@
 					   hashcash-default-accept-payment)))
     (save-excursion
       (goto-char (point-min))
-      (search-forward mail-header-separator)
+      (or (search-forward (concat "\n" mail-header-separator "\n") nil t)
+	  (search-forward-regexp "[^:]+:\\([^\n]\\|\n[ \t]\\)+\n\n" nil t))
       (beginning-of-line)
       (let ((end (point))
 	    (ok nil))