* hashcash @ 2004-09-26 15:30 Adam Sjøgren 2004-09-26 17:36 ` hashcash Simon Josefsson 2004-09-27 16:10 ` hashcash Ted Zlatanov 0 siblings, 2 replies; 34+ messages in thread From: Adam Sjøgren @ 2004-09-26 15:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-26 15:30 hashcash Adam Sjøgren @ 2004-09-26 17:36 ` Simon Josefsson 2004-09-26 20:59 ` hashcash Adam Sjøgren 2004-09-27 16:10 ` hashcash Ted Zlatanov 1 sibling, 1 reply; 34+ messages in thread From: Simon Josefsson @ 2004-09-26 17:36 UTC (permalink / raw) Cc: Paul Foley 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-26 17:36 ` hashcash Simon Josefsson @ 2004-09-26 20:59 ` Adam Sjøgren 2004-09-27 2:03 ` hashcash Paul Foley 0 siblings, 1 reply; 34+ messages in thread From: Adam Sjøgren @ 2004-09-26 20:59 UTC (permalink / raw) Cc: Paul Foley 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-26 20:59 ` hashcash Adam Sjøgren @ 2004-09-27 2:03 ` Paul Foley 2004-09-27 14:32 ` hashcash Simon Josefsson 2004-09-27 14:45 ` hashcash Adam Sjøgren 0 siblings, 2 replies; 34+ messages in thread From: Paul Foley @ 2004-09-27 2:03 UTC (permalink / raw) 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>")) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 2:03 ` hashcash Paul Foley @ 2004-09-27 14:32 ` Simon Josefsson 2004-09-27 14:46 ` hashcash Adam Sjøgren 2004-09-29 14:37 ` hashcash Dan Christensen 2004-09-27 14:45 ` hashcash Adam Sjøgren 1 sibling, 2 replies; 34+ messages in thread From: Simon Josefsson @ 2004-09-27 14:32 UTC (permalink / raw) Cc: Paul Foley 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 14:32 ` hashcash Simon Josefsson @ 2004-09-27 14:46 ` Adam Sjøgren 2004-09-29 14:37 ` hashcash Dan Christensen 1 sibling, 0 replies; 34+ messages in thread From: Adam Sjøgren @ 2004-09-27 14:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 14:32 ` hashcash Simon Josefsson 2004-09-27 14:46 ` hashcash Adam Sjøgren @ 2004-09-29 14:37 ` Dan Christensen 2004-09-29 14:40 ` hashcash Ted Zlatanov 1 sibling, 1 reply; 34+ messages in thread From: Dan Christensen @ 2004-09-29 14:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-29 14:37 ` hashcash Dan Christensen @ 2004-09-29 14:40 ` Ted Zlatanov 2004-09-29 19:11 ` hashcash Dan Christensen 0 siblings, 1 reply; 34+ messages in thread From: Ted Zlatanov @ 2004-09-29 14:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-29 14:40 ` hashcash Ted Zlatanov @ 2004-09-29 19:11 ` Dan Christensen 2004-09-29 21:08 ` hashcash Magnus Henoch 0 siblings, 1 reply; 34+ messages in thread From: Dan Christensen @ 2004-09-29 19:11 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-29 19:11 ` hashcash Dan Christensen @ 2004-09-29 21:08 ` Magnus Henoch 2004-09-30 14:30 ` hashcash Ted Zlatanov 0 siblings, 1 reply; 34+ messages in thread From: Magnus Henoch @ 2004-09-29 21:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-29 21:08 ` hashcash Magnus Henoch @ 2004-09-30 14:30 ` Ted Zlatanov 2004-09-30 20:42 ` hashcash Magnus Henoch 0 siblings, 1 reply; 34+ messages in thread From: Ted Zlatanov @ 2004-09-30 14:30 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-30 14:30 ` hashcash Ted Zlatanov @ 2004-09-30 20:42 ` Magnus Henoch 0 siblings, 0 replies; 34+ messages in thread From: Magnus Henoch @ 2004-09-30 20:42 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 2:03 ` hashcash Paul Foley 2004-09-27 14:32 ` hashcash Simon Josefsson @ 2004-09-27 14:45 ` Adam Sjøgren 2004-09-27 15:21 ` hashcash Simon Josefsson 2004-09-28 14:08 ` hashcash Ted Zlatanov 1 sibling, 2 replies; 34+ messages in thread From: Adam Sjøgren @ 2004-09-27 14:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 14:45 ` hashcash Adam Sjøgren @ 2004-09-27 15:21 ` Simon Josefsson 2004-09-27 15:38 ` hashcash Adam Sjøgren 2004-09-28 14:08 ` hashcash Ted Zlatanov 1 sibling, 1 reply; 34+ messages in thread From: Simon Josefsson @ 2004-09-27 15:21 UTC (permalink / raw) Cc: Paul Foley 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 15:21 ` hashcash Simon Josefsson @ 2004-09-27 15:38 ` Adam Sjøgren 2004-09-27 17:13 ` hashcash Jesper Harder 0 siblings, 1 reply; 34+ messages in thread From: Adam Sjøgren @ 2004-09-27 15:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 15:38 ` hashcash Adam Sjøgren @ 2004-09-27 17:13 ` Jesper Harder 2004-09-27 19:02 ` hashcash Adam Sjøgren 0 siblings, 1 reply; 34+ messages in thread From: Jesper Harder @ 2004-09-27 17:13 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 17:13 ` hashcash Jesper Harder @ 2004-09-27 19:02 ` Adam Sjøgren 2004-09-27 19:38 ` hashcash Simon Josefsson 0 siblings, 1 reply; 34+ messages in thread From: Adam Sjøgren @ 2004-09-27 19:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 19:02 ` hashcash Adam Sjøgren @ 2004-09-27 19:38 ` Simon Josefsson 2004-09-27 19:54 ` hashcash Adam Sjøgren 2004-09-27 19:56 ` hashcash Jesper Harder 0 siblings, 2 replies; 34+ messages in thread From: Simon Josefsson @ 2004-09-27 19:38 UTC (permalink / raw) Cc: Paul Foley 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? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 19:38 ` hashcash Simon Josefsson @ 2004-09-27 19:54 ` Adam Sjøgren 2004-09-27 19:56 ` hashcash Jesper Harder 1 sibling, 0 replies; 34+ messages in thread From: Adam Sjøgren @ 2004-09-27 19:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 19:38 ` hashcash Simon Josefsson 2004-09-27 19:54 ` hashcash Adam Sjøgren @ 2004-09-27 19:56 ` Jesper Harder 2004-09-27 20:50 ` hashcash Simon Josefsson 1 sibling, 1 reply; 34+ messages in thread From: Jesper Harder @ 2004-09-27 19:56 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 19:56 ` hashcash Jesper Harder @ 2004-09-27 20:50 ` Simon Josefsson 0 siblings, 0 replies; 34+ messages in thread From: Simon Josefsson @ 2004-09-27 20:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-27 14:45 ` hashcash Adam Sjøgren 2004-09-27 15:21 ` hashcash Simon Josefsson @ 2004-09-28 14:08 ` Ted Zlatanov 2004-09-28 14:49 ` hashcash Simon Josefsson 1 sibling, 1 reply; 34+ messages in thread From: Ted Zlatanov @ 2004-09-28 14:08 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-28 14:08 ` hashcash Ted Zlatanov @ 2004-09-28 14:49 ` Simon Josefsson 2004-09-28 17:41 ` hashcash Ted Zlatanov 0 siblings, 1 reply; 34+ messages in thread From: Simon Josefsson @ 2004-09-28 14:49 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-28 14:49 ` hashcash Simon Josefsson @ 2004-09-28 17:41 ` Ted Zlatanov 2004-09-30 20:50 ` hashcash Simon Josefsson 0 siblings, 1 reply; 34+ messages in thread From: Ted Zlatanov @ 2004-09-28 17:41 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-28 17:41 ` hashcash Ted Zlatanov @ 2004-09-30 20:50 ` Simon Josefsson 2004-10-04 17:06 ` hashcash Ted Zlatanov 0 siblings, 1 reply; 34+ messages in thread From: Simon Josefsson @ 2004-09-30 20:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-30 20:50 ` hashcash Simon Josefsson @ 2004-10-04 17:06 ` Ted Zlatanov 2004-10-04 19:36 ` hashcash Simon Josefsson 0 siblings, 1 reply; 34+ messages in thread From: Ted Zlatanov @ 2004-10-04 17:06 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-10-04 17:06 ` hashcash Ted Zlatanov @ 2004-10-04 19:36 ` Simon Josefsson 2004-10-05 2:34 ` hashcash Dan Christensen 2004-10-06 15:17 ` hashcash Ted Zlatanov 0 siblings, 2 replies; 34+ messages in thread From: Simon Josefsson @ 2004-10-04 19:36 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-10-04 19:36 ` hashcash Simon Josefsson @ 2004-10-05 2:34 ` Dan Christensen 2004-10-06 15:17 ` hashcash Ted Zlatanov 1 sibling, 0 replies; 34+ messages in thread From: Dan Christensen @ 2004-10-05 2:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-10-04 19:36 ` hashcash Simon Josefsson 2004-10-05 2:34 ` hashcash Dan Christensen @ 2004-10-06 15:17 ` Ted Zlatanov 1 sibling, 0 replies; 34+ messages in thread From: Ted Zlatanov @ 2004-10-06 15:17 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hashcash 2004-09-26 15:30 hashcash Adam Sjøgren 2004-09-26 17:36 ` hashcash Simon Josefsson @ 2004-09-27 16:10 ` Ted Zlatanov 1 sibling, 0 replies; 34+ messages in thread From: Ted Zlatanov @ 2004-09-27 16:10 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* new spam functionality added @ 2002-07-31 19:24 Ted Zlatanov 2002-07-31 20:14 ` Simon Josefsson 0 siblings, 1 reply; 34+ messages in thread From: Ted Zlatanov @ 2002-07-31 19:24 UTC (permalink / raw) I just added spam-split: a function to be used in nnmail-split-fancy, for instance. It outputs the value of smap-split-group if a message is sent from a blackhole relay, or if the sender is blacklisted. The whitelist is checked before the blacklist is consulted. I also made some small fixes here and there to the source of spam.el, nothing major. query-dns from dns.el didn't work for me, and I couldn't figure out the exact problem. That caused problems with the blackhole check. Who's in charge of dns.el? I'm ramping up after 2 months of 10% use of my right hand, so I'll try to keep up with the spam work but I'm still pretty slow. Sorry for the delay, and feel free to suggest improvements. Look in the ding archives for previous discussions on this topic, where Lars and I have mentioned the plans for the spam.el library. Thanks Ted ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: new spam functionality added @ 2002-07-31 20:14 ` Simon Josefsson 2002-07-31 20:25 ` Josh Huber 0 siblings, 1 reply; 34+ messages in thread From: Simon Josefsson @ 2002-07-31 20:14 UTC (permalink / raw) Cc: Ted Zlatanov, ding Scott A Crosby <scrosby@cs.rice.edu> writes: > On Wed, 31 Jul 2002 15:24:34 -0400, Ted Zlatanov <tzz@lifelogs.com> writes: > >> I'm ramping up after 2 months of 10% use of my right hand, so I'll try >> to keep up with the spam work but I'm still pretty slow. Sorry for >> the delay, and feel free to suggest improvements. Look in the ding >> archives for previous discussions on this topic, where Lars and I have >> mentioned the plans for the spam.el library. > > Why reimplement the wheel? We can link to an external program (like > spamassassin) and have it do all the real work for us. (Thats what my > current setup is). Then just patternmatch on the headers it adds to > the email. How to hook up to external programs is already described in the manual (suggest improvements if something is missing). Reimplementing it allows for greater flexibility, although I guess much work will be needed until it can supersede spamassassin. It is also more lightweight than calling external programs. My only suggestion is: texi documentation ;-) Another thought on documentation: if spam.el documentation is added, and the NoCeM node is moved, to the "Thwarting Email Spam" node, I think that node becomes long enough, and important enough, to warrant moving it up to the top-level menu. Opinions? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: new spam functionality added 2002-07-31 20:14 ` Simon Josefsson @ 2002-07-31 20:25 ` Josh Huber 2002-07-31 20:34 ` Scott A Crosby 0 siblings, 1 reply; 34+ messages in thread From: Josh Huber @ 2002-07-31 20:25 UTC (permalink / raw) Simon Josefsson <jas@extundo.com> writes: > Another thought on documentation: if spam.el documentation is added, > and the NoCeM node is moved, to the "Thwarting Email Spam" node, I > think that node becomes long enough, and important enough, to > warrant moving it up to the top-level menu. Opinions? Sure, perhaps we should include something about TMDA? http://cvs.sf.net/cgi-bin/viewcvs.cgi/~checkout~/tmda/tmda/contrib/tmda.el I'm in the middle of writing up some documentation to put on my.gnus.org, and converting it into texi for the manual would be simple. What do you think? -- Josh Huber ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: new spam functionality added 2002-07-31 20:25 ` Josh Huber @ 2002-07-31 20:34 ` Scott A Crosby 2002-07-31 20:41 ` Josh Huber 0 siblings, 1 reply; 34+ messages in thread From: Scott A Crosby @ 2002-07-31 20:34 UTC (permalink / raw) On Wed, 31 Jul 2002 16:25:53 -0400, Josh Huber <huber+dated+1028578998.eb7ca9@alum.wpi.edu> writes: > Simon Josefsson <jas@extundo.com> writes: > > Sure, perhaps we should include something about TMDA? > Please don't.. TMDA is tragedy of the commons. It only helps one person by putting extra work and effort upon everyone else. If everyone used it, things will turn to crap. BTW, whats the archive address for this list? Scott ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: new spam functionality added 2002-07-31 20:34 ` Scott A Crosby @ 2002-07-31 20:41 ` Josh Huber 2002-07-31 21:07 ` Scott A Crosby 0 siblings, 1 reply; 34+ messages in thread From: Josh Huber @ 2002-07-31 20:41 UTC (permalink / raw) Scott A Crosby <scrosby@cs.rice.edu> writes: > Please don't.. TMDA is tragedy of the commons. It only helps one > person by putting extra work and effort upon everyone else. If > everyone used it, things will turn to crap. I disagree. With all of TMDA's facilities for tagging messages which expire, keyword addresses and sender addresses most people don't even know you're using it. (apart from a funny looking dated email address). In practice, over the past 2 weeks the only messages which have appeared in my pending queue have been spams. It's worked 100%, with 0 false positives. I used an initial seed whitelist based on my outbox and a few other sources, and it's been working quite well. What don't you like about it? > BTW, whats the archive address for this list? Well, it's archived on nntp+quimby.gnus.org:gnus.ding, which is where I read/post. have a nice day, -- Josh Huber ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: new spam functionality added 2002-07-31 20:41 ` Josh Huber @ 2002-07-31 21:07 ` Scott A Crosby 2002-08-02 2:05 ` Jason R. Mastaler 0 siblings, 1 reply; 34+ messages in thread From: Scott A Crosby @ 2002-07-31 21:07 UTC (permalink / raw) On Wed, 31 Jul 2002 16:41:30 -0400, Josh Huber <huber+dated+1028579883.ab0915@alum.wpi.edu> writes: > Scott A Crosby <scrosby@cs.rice.edu> writes: > > > Please don't.. TMDA is tragedy of the commons. It only helps one > > person by putting extra work and effort upon everyone else. If > > everyone used it, things will turn to crap. > > I disagree. With all of TMDA's facilities for tagging messages which > expire, keyword addresses and sender addresses most people don't even > know you're using it. (apart from a funny looking dated email > address). > > In practice, over the past 2 weeks the only messages which have > appeared in my pending queue have been spams. It's worked 100%, with > 0 false positives. I used an initial seed whitelist based on my > outbox and a few other sources, and it's been working quite well. Because its tragedy of the commons, I bitbucket any TMDA user. (and if I start getting too many of em, I'll make a public blacklist of em.) > > What don't you like about it? > Well, Jack Twilly phrased one of my problems most elegantly. :) TMDA ''works'' by pushing work onto everyone else.. You know, tragedy of the commons. Here's a post I did a while ago on why I don't like it, or any other scheme requiring autoreply-crap for communication. ++ No.. Think of it carefully.. TMDA works by polluting everyone else. By forcing everyone else you contact to do extra work. This is tragedy of the commons. Imagine a world where everyone uses it (or something similar), but, say, 10% have it misconfigured. This is a world with mailing lists. Mailing list maintance functions (including initial requests to subscribe, or confirmation requests from web-maintance.) either get accepted automatically, (direct route for spam!), or force the mailing list admin to deal with the automated 'please reply to me' messages.. Which they'll ignore, then they'll still get users asking why email subscriptions don't work. Mailing list messages... Post to a mailing list the first time and potentially get tens, hundreds, even thousands of 'please reply to me' messages. Hey, they only take a second each to deal with! Now, imagine there's a daemon that autoreplies to such 'please reply to me' messages.. Well, just forge the spam to appear to come from a legitimate user, and guess what, the bounces go to them, and their client helpfully 'authenticates' the spam.. (The daemon can't be configured to record every email sent and only autoreply to autoreplies to emails the user actually sent. Many times people will use many systems and email servers, but only one email address.) For more fun, you may even get mail loops of 'please reply to me' messages. Now, in the above examples, you can eliminate this undesireable behavior by automatically accepting, unchecked, mailing list maintance messages, or autoreply messages, or a blanket opening for mailing list messages... However, spam can be easily forged to appear to be a maintance message or an autoreply message. Under the assumption that there *will* be misconfigured clients, they'll have to deal with mailing lists that they don't know about. either by spamming posters to the list (unacceptable), or filtering them out into a seperate folder that the user will have to manually check. In all cases, if the 'please reply to me' messages are mechanically replyable, then a daemon will be created to deal with that trash automatically, and most users will use it. (So, spammers can forge their email to come from almost any user, and the daemon of the forged address will reply.) Or, those messages can be used to indicate that an email address is live. (Send a message to someone using TMDA, confirm that they use TMDA, now you know you can forge spam from that address and their daemon will authenticate it for you for free!) Of course the other option here is to spam from legitimate hosts that have been cracked by today's IIS/outlook worm. (Or one of the 30,000 *STILL* infected code-red machines.) The cracked systems run email servers and reply automatically. Now, if the 'please reply to me' messages are NOT mechanically replyable, then we've saturated the internet with an even larger amount of trash and mail pollution that has to be dealt with on a message-by-message basis. (As per the above scenario's.) In any case. TMDA is not a solution, its a problem. TMDA and any other scheme that requires such automated response to all sent emails is tragedy of the commons. There's no better example. It superficially helps the user, to the detriment of everyone else. Ergo, it will proliferate and everyone will be even worse off. ++ > Well, it's archived on nntp+quimby.gnus.org:gnus.ding, which is where > I read/post. Thanks! Scott ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: new spam functionality added 2002-07-31 21:07 ` Scott A Crosby @ 2002-08-02 2:05 ` Jason R. Mastaler 2002-08-02 3:43 ` Russ Allbery 0 siblings, 1 reply; 34+ messages in thread From: Jason R. Mastaler @ 2002-08-02 2:05 UTC (permalink / raw) Scott A Crosby <scrosby@cs.rice.edu> writes: > Because its tragedy of the commons, I bitbucket any TMDA user. While I don't feel such animosity is warranted, I've heard it before, and understand where it's coming from. Unwillingness to accept the severity of the spam problem, and the fact that the Internet isn't the place it used to be. Like those who refuse to lock their front doors despite the changing climate of their neighborhood, because they never have before, and don't want to hear what the neighbors are saying. Unfortunately, boycotting TMDA users will do nothing to help the problem. You aren't teaching anyone a lesson with such behavior. Would it make you feel better if I uninstalled TMDA and went back to an unsavory e-mail experience? How about putting your energy into something productive such as working on a real solution to the problem instead of hurting those who have found some temporary relief? I never said TMDA was a solution to spam, it's morphine for the cancer patient. It alleviates some of my suffering, while I keep my eye on the prize, which is a real "cure". > (and if I start getting too many of em, I'll make a public blacklist > of em.) Who is going to respect a "public blacklist" filled with the names of those whom Scott has philosophical differences with. Please. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: new spam functionality added 2002-08-02 2:05 ` Jason R. Mastaler @ 2002-08-02 3:43 ` Russ Allbery 2002-08-02 4:29 ` Jason R. Mastaler 0 siblings, 1 reply; 34+ messages in thread From: Russ Allbery @ 2002-08-02 3:43 UTC (permalink / raw) Jason R Mastaler <jason@mastaler.com> writes: > While I don't feel such animosity is warranted, I've heard it before, > and understand where it's coming from. Unwillingness to accept the > severity of the spam problem, and the fact that the Internet isn't the > place it used to be. It's not unwillingness to accept anything. It's refusal to jump through other people's hoops so that they can receive my mail. Spam sucks. I deal with it. Other people can too. There are a lot of different tactics that can work. Making people go to more effort to send you mail isn't one that I'm willing to support by extending that effort. > Unfortunately, boycotting TMDA users will do nothing to help the > problem. You aren't teaching anyone a lesson with such behavior. If you use TMDA in a configuration that requires me confirm my mail when I send it to you, then you simply won't receive mail from me. I am of the somewhat egotistical opinion that in general you'll lose more from not receiving mail from me than I'll lose in not being able to send mail to you, since I'm more frequently answering questions than asking them. If you can live with simply cutting off communication with people like me as acceptable lossage in keeping away the spam, then more power to you. If you ever want to get mail from me, you'll write to me with a repliable address; requiring confirmation renders the e-mail address unrepliable as far as I'm concerned and I will treat it accordingly. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: new spam functionality added 2002-08-02 3:43 ` Russ Allbery @ 2002-08-02 4:29 ` Jason R. Mastaler 2002-08-02 4:34 ` Russ Allbery 0 siblings, 1 reply; 34+ messages in thread From: Jason R. Mastaler @ 2002-08-02 4:29 UTC (permalink / raw) Russ Allbery <rra@stanford.edu> writes: > It's refusal to jump through other people's hoops so that they can > receive my mail. Do you have the same objections to confirming a mailing list subscription? What's the difference? > Spam sucks. I deal with it. Other people can too. Misery loves company. > There are a lot of different tactics that can work. Work, yes, but not nearly well enough. Ibuprofen won't cut it; I need morphine. > If you can live with simply cutting off communication with people > like me as acceptable lossage in keeping away the spam, then more > power to you. No, that's certainly not acceptable. However, senders who won't confirm their messages merely out of spite are in the vast minority, so it's not really a problem. TMDA has ways around these situations anyway. > If you ever want to get mail from me, you'll write to me with a > repliable address; requiring confirmation renders the e-mail address > unrepliable as far as I'm concerned and I will treat it accordingly. Of course. Have you actually taken a look at TMDA, or are you just making assumptions here? With TMDA, I'll always write to you with a repliable address. This is one of the reasons another poster in this thread said that the majority of correspondents won't even notice it. I totally agree, doing otherwise would be extremely rude. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: new spam functionality added 2002-08-02 4:29 ` Jason R. Mastaler @ 2002-08-02 4:34 ` Russ Allbery 2002-08-02 16:17 ` TMDA (was: new spam functionality added) Paul Jarc 0 siblings, 1 reply; 34+ messages in thread From: Russ Allbery @ 2002-08-02 4:34 UTC (permalink / raw) Jason R Mastaler <jason-exp-1028953774.6ffe92@mastaler.com> writes: > Russ Allbery <rra@stanford.edu> writes: >> It's refusal to jump through other people's hoops so that they can >> receive my mail. > Do you have the same objections to confirming a mailing list > subscription? No. > What's the difference? That's a service that I'm requesting, and the confirmation protects *me* against forged subscriptions to mailing lists. It is also a one-time cost to pay for an ongoing stream of mail, whereas with individual confirmations I have to keep confirming my mail to individuals I only mail once. > Of course. Have you actually taken a look at TMDA, or are you just > making assumptions here? I'm not making any assumptions. My message spelled out in great detail specifically what I was objecting to. If you're using TMDA in some other configuration, then I'm not objecting to that, am I? I have encountered people with TMDA configured precisely along the lines that I've previously described. I don't confirm my mail to them. It's a waste of my time, which I consider valuable and refuse to allow be wasted in that fashion. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-02 4:34 ` Russ Allbery @ 2002-08-02 16:17 ` Paul Jarc 2002-08-05 17:38 ` Per Abrahamsen 0 siblings, 1 reply; 34+ messages in thread From: Paul Jarc @ 2002-08-02 16:17 UTC (permalink / raw) Russ Allbery <rra@stanford.edu> wrote: > I have encountered people with TMDA configured precisely along the lines > that I've previously described. I don't confirm my mail to them. It's a > waste of my time, which I consider valuable and refuse to allow be wasted > in that fashion. If a reliable autoconfirmer were written, would you consider it a waste of time to set it up for your mailbox? Jason, you might want to consider adding such a component to TMDA. Messages I send would get a header field added containing hash(secret+hash(message)). When I send a message to you, the TMDA confirmation request would contain at least hash(message) as computed by you and hash(secret+hash(message)) as contained in my message, if not the whole message itself, which I could use to compute hash(message) if you didn't include it. Given that, a program receiving my mail can verify the the hash in the original message was computed using my secret, and can send a confirmation and drop/reroute the confirmation request. paul ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-02 16:17 ` TMDA (was: new spam functionality added) Paul Jarc @ 2002-08-05 17:38 ` Per Abrahamsen 2002-08-05 17:49 ` Paul Jarc 0 siblings, 1 reply; 34+ messages in thread From: Per Abrahamsen @ 2002-08-05 17:38 UTC (permalink / raw) prj@po.cwru.edu (Paul Jarc) writes: > If a reliable autoconfirmer were written, would you consider it a > waste of time to set it up for your mailbox? If a reliable autoconfirmer were written, some spammers would start using it. We need some amount manual intervention for the system to scale. But I don't consider the problem with people who will refuse to spend a second or two to confirm their existence for significant. I lose mail today because by filters (automatic and manual) are too agressive, and I can't afford the time to use less agressive filters: - Today, I can lose mail from anybody, through no fault of theirs. Even if it is something that it is very important to them that I see. - With TMDA, I will only lose mail from people who deliberately decide that getting their message through isn't worth two seconds of their tine. It seem much more fair to lose mail from the later category than the former. The problem that does frighten me is whether non-technical people will understand the request for a confirmation message. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-05 17:38 ` Per Abrahamsen @ 2002-08-05 17:49 ` Paul Jarc 2002-08-05 17:57 ` Simon Josefsson 0 siblings, 1 reply; 34+ messages in thread From: Paul Jarc @ 2002-08-05 17:49 UTC (permalink / raw) Per Abrahamsen <abraham@dina.kvl.dk> wrote: > If a reliable autoconfirmer were written, some spammers would start > using it. In doing so, they would give up their anonymity. We'd be able to find them and report them (and blacklist them). paul ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-05 17:49 ` Paul Jarc @ 2002-08-05 17:57 ` Simon Josefsson 2002-08-05 20:18 ` David Masterson 0 siblings, 1 reply; 34+ messages in thread From: Simon Josefsson @ 2002-08-05 17:57 UTC (permalink / raw) prj@po.cwru.edu (Paul Jarc) writes: > Per Abrahamsen <abraham@dina.kvl.dk> wrote: >> If a reliable autoconfirmer were written, some spammers would start >> using it. > > In doing so, they would give up their anonymity. We'd be able to > find them and report them (and blacklist them). Is this the problem? In theory I can track down IP's on the net today, but tracking down spammers this way doesn't seem like a solution that prevents all spam in practice, as spammers uses hacked or incorrectly configured machines. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-05 17:57 ` Simon Josefsson @ 2002-08-05 20:18 ` David Masterson 2002-08-05 20:46 ` Stainless Steel Rat 0 siblings, 1 reply; 34+ messages in thread From: David Masterson @ 2002-08-05 20:18 UTC (permalink / raw) >>>>> Simon Josefsson writes: > prj@po.cwru.edu (Paul Jarc) writes: >> Per Abrahamsen <abraham@dina.kvl.dk> wrote: >>> If a reliable autoconfirmer were written, some spammers would >>> start using it. >> In doing so, they would give up their anonymity. We'd be able to >> find them and report them (and blacklist them). > Is this the problem? In theory I can track down IP's on the net > today, but tracking down spammers this way doesn't seem like a > solution that prevents all spam in practice, as spammers uses hacked > or incorrectly configured machines. When the spammer assumes that no one can reply to his message, then all these things can be spoofed in the email. All you really know is the hostname and IP address of the last relayer of the email which is something that spammers rely upon to maintain their anonymity. If the spammer decides to put in an autoconfirmer to get around TMDA, then he has to supply a good "return address" in his SPAM which now makes him traceable. Even if it's only traceable back to a compromised machine, that machine can be blacklisted and the sysadmin informed to fix it. -- David Masterson David DOT Masterson AT synopsys DOT com Sr. R&D Engineer Synopsys, Inc. Software Engineering Sunnyvale, CA ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-05 20:18 ` David Masterson @ 2002-08-05 20:46 ` Stainless Steel Rat 2002-08-06 3:04 ` David Masterson 0 siblings, 1 reply; 34+ messages in thread From: Stainless Steel Rat @ 2002-08-05 20:46 UTC (permalink / raw) * David Masterson <dmaster@synopsys.com> on Mon, 05 Aug 2002 | something that spammers rely upon to maintain their anonymity. If the | spammer decides to put in an autoconfirmer to get around TMDA, then he | has to supply a good "return address" in his SPAM which now makes him | traceable. Even if it's only traceable back to a compromised machine, | that machine can be blacklisted and the sysadmin informed to fix it. "winatial9077@hotmail.com" is not what I would call "easilly traceable". A spammer only needs it for one round of automatically responding to TMDA approvals. -- Rat <ratinox@peorth.gweep.net> \ Happy Fun Ball may stick to certain types Minion of Nathan - Nathan says Hi! \ of skin. PGP Key: at a key server near you! \ That and five bucks will get you a small coffee at Starbucks. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-05 20:46 ` Stainless Steel Rat @ 2002-08-06 3:04 ` David Masterson 2002-08-06 14:27 ` Stainless Steel Rat 0 siblings, 1 reply; 34+ messages in thread From: David Masterson @ 2002-08-06 3:04 UTC (permalink / raw) >>>>> Stainless Steel Rat writes: > * David Masterson <dmaster@synopsys.com> on Mon, 05 Aug 2002 > | something that spammers rely upon to maintain their anonymity. If > | the spammer decides to put in an autoconfirmer to get around TMDA, > | then he has to supply a good "return address" in his SPAM which > | now makes him traceable. Even if it's only traceable back to a > | compromised machine, that machine can be blacklisted and the > | sysadmin informed to fix it. > "winatial9077@hotmail.com" is not what I would call "easilly > traceable". A spammer only needs it for one round of automatically > responding to TMDA approvals. Sure, but now you (the receiver of spam) are sure that the email came from hotmail.com and you have (a list of) email addresses that were used to do the spamming. Thru some of the recent legislation (like, IIRC, the anti-spamming law in California), I think you (or a class action group) have reasonable cause to sue Hotmail to either: * find out who the spammer is and sue them -and/or- * force Hotmail to prevent anonymous account generation -- David Masterson dsm@rawbw.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-06 3:04 ` David Masterson @ 2002-08-06 14:27 ` Stainless Steel Rat 2002-08-06 17:13 ` David Masterson 0 siblings, 1 reply; 34+ messages in thread From: Stainless Steel Rat @ 2002-08-06 14:27 UTC (permalink / raw) * David Masterson <dsm@rawbw.com> on Mon, 05 Aug 2002 | * find out who the spammer is and sue them -and/or- | * force Hotmail to prevent anonymous account generation ... crushing any chance at confidental access to on-line cancer and rape support groups, for example. -- Rat <ratinox@peorth.gweep.net> \ Happy Fun Ball may stick to certain types Minion of Nathan - Nathan says Hi! \ of skin. PGP Key: at a key server near you! \ That and five bucks will get you a small coffee at Starbucks. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-06 14:27 ` Stainless Steel Rat @ 2002-08-06 17:13 ` David Masterson 2002-08-06 17:26 ` David Masterson 0 siblings, 1 reply; 34+ messages in thread From: David Masterson @ 2002-08-06 17:13 UTC (permalink / raw) >>>>> Stainless Steel Rat writes: > * David Masterson <dsm@rawbw.com> on Mon, 05 Aug 2002 > | * find out who the spammer is and sue them -and/or- > | * force Hotmail to prevent anonymous account generation > ... crushing any chance at confidental access to on-line cancer and rape > support groups, for example. The needs of the many... -- David Masterson David DOT Masterson AT synopsys DOT com Sr. R&D Engineer Synopsys, Inc. Software Engineering Sunnyvale, CA ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-06 17:13 ` David Masterson @ 2002-08-06 17:26 ` David Masterson 2002-08-06 18:08 ` Stainless Steel Rat 0 siblings, 1 reply; 34+ messages in thread From: David Masterson @ 2002-08-06 17:26 UTC (permalink / raw) >>>>> David Masterson writes: >>>>> Stainless Steel Rat writes: >> * David Masterson <dsm@rawbw.com> on Mon, 05 Aug 2002 >> | * find out who the spammer is and sue them -and/or- >> | * force Hotmail to prevent anonymous account generation >> ... crushing any chance at confidental access to on-line cancer and >> rape support groups, for example. > The needs of the many... Also, if needed, a system could be set up for this purpose that allow people with these accounts to send limited numbers of email within a given time period, thus making the system unattractive to spammers. -- David Masterson David DOT Masterson AT synopsys DOT com Sr. R&D Engineer Synopsys, Inc. Software Engineering Sunnyvale, CA ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-06 17:26 ` David Masterson @ 2002-08-06 18:08 ` Stainless Steel Rat 2002-08-07 12:02 ` Lloyd Zusman 0 siblings, 1 reply; 34+ messages in thread From: Stainless Steel Rat @ 2002-08-06 18:08 UTC (permalink / raw) * David Masterson <dmaster@synopsys.com> on Tue, 06 Aug 2002 | Also, if needed, a system could be set up for this purpose that allow | people with these accounts to send limited numbers of email within a | given time period, thus making the system unattractive to spammers. I like the idea of just making the system unattractive to spammers without making it unattractive to Joe Average. -- Rat <ratinox@peorth.gweep.net> \ Warning: pregnant women, the elderly, and Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged PGP Key: at a key server near you! \ exposure to Happy Fun Ball. That and five bucks will get you a small coffee at Starbucks. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: TMDA (was: new spam functionality added) 2002-08-06 18:08 ` Stainless Steel Rat @ 2002-08-07 12:02 ` Lloyd Zusman 2002-12-30 0:22 ` Hashcash (was: TMDA) Lars Magne Ingebrigtsen 0 siblings, 1 reply; 34+ messages in thread From: Lloyd Zusman @ 2002-08-07 12:02 UTC (permalink / raw) Stainless Steel Rat <ratinox@peorth.gweep.net> writes: > * David Masterson <dmaster@synopsys.com> on Tue, 06 Aug 2002 > | Also, if needed, a system could be set up for this purpose that allow > | people with these accounts to send limited numbers of email within a > | given time period, thus making the system unattractive to spammers. > > I like the idea of just making the system unattractive to spammers without > making it unattractive to Joe Average. Agreed ... and for that reason, I putting my two cents in to support Hashcash. And I also support TMDA and others of its ilk ... because in my experience, very few "Joe Average" type folks that I know have had a problem with the couple extra keystrokes or mouseclicks that are necessary to send the initial confirmation message. In fact, several of my "Joe Average" correspondents have written back to tell me that after being introduced to TMDA via my email account, they are off to try to install it and use it themselves. In the ideal email world that I'm envisioning today, there would be some sort of combination of hashcash and confirmation. Most people I know would consider this to be a small and quite acceptable price to pay for spam reduction. In the case of a the small minority who are dead set against email confirmation (and yes, in my experience so far, it IS a small minority), I'd be happy to pre-whitelist those people if I really want to communicate with them ... many of them are vocal about their opposition to email confirmations, which makes it easy for me to identify a lot of them before I communicate. There will still be the occasional person who wants to initiate contact, but who is morally opposed to my confirmation system, and who therefore decides not to follow through once he or she discovers that I'm using such a system. Even in that case, I can see the initial email that this person sent, since I keep a "pending" queue that I review once or twice a day. And if I want to respond to that person, TMDA easily allows me to "release" his or her email and to whitelist the return address. So I can still respond to that person, who then has the choice as to whether he or she wants to continue communicating with me, without any need for confirmation. I believe that only the most die-hard anti-email-confirmation zealots would refuse to continue communicating with someone with whom they originally initiated contact, from whom they received a confirmation request that they ignored, and from whom they subsequently received a gracious reply anyway, with an explanation that confirmation is no longer necessary for them, because they have been whitelisted. And I wouldn't lose a whole lot of sleep if an person like that would refuse to continue the email conversation that he or she originally initiated with me, and which I voluntarily chose to continue anyway, under these circumstances. So for me (and I believe for lots of other "Joe Average" folks), a TMDA-like system is useful and desirable. And as I mentioned, that in combination with hashcash would go a long way towards significantly reducing spam. -- Lloyd Zusman ljz@asfast.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* Hashcash (was: TMDA) 2002-08-07 12:02 ` Lloyd Zusman @ 2002-12-30 0:22 ` Lars Magne Ingebrigtsen 2003-01-02 18:33 ` Hashcash Simon Josefsson 0 siblings, 1 reply; 34+ messages in thread From: Lars Magne Ingebrigtsen @ 2002-12-30 0:22 UTC (permalink / raw) Cc: Paul Foley (To sum up my feelings on the issue -- I recognize that other people feel that they have no other option but to use a challenge-response service to deal with mail from people they don't know, and that's OK by me. I do feel, however, that if I were to do so, I would be slightly rude, since I haven't gotten to the point of desperation where spam is concerned. But people are different.) Lloyd Zusman <ljz@asfast.com> writes: > Agreed ... and for that reason, I putting my two cents in to support > Hashcash. Which brings me to what I wanted to write about. I think hashcash is a brilliant idea, as it requires no centralized functionality, and people can just switch over to using hashcash when they want, and other people can choose to recognize hashcash when they want, or not. For instance, I could easily see me putting in a mail split rule that says "if this is a hashcashed message, put it in nnml:misc, and don't do any further tests for spamminess. So I want to make Gnus support X-Hashcash. I see that there's a hashcash.el in the contrib directory, written by Paul E. Foley. Would it be possible to assign the copyright for this to the FSF? There doesn't seem to be any code in there to verify the hashcash payment. Does anybody have anything for doing that? 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? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Hashcash 2002-12-30 0:22 ` Hashcash (was: TMDA) Lars Magne Ingebrigtsen @ 2003-01-02 18:33 ` Simon Josefsson 2003-01-02 19:25 ` Hashcash Lars Magne Ingebrigtsen 0 siblings, 1 reply; 34+ messages in thread From: Simon Josefsson @ 2003-01-02 18:33 UTC (permalink / raw) Cc: Paul Foley 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)) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Hashcash 2003-01-02 18:33 ` Hashcash Simon Josefsson @ 2003-01-02 19:25 ` Lars Magne Ingebrigtsen 2003-01-02 21:01 ` Hashcash Simon Josefsson 0 siblings, 1 reply; 34+ messages in thread From: Lars Magne Ingebrigtsen @ 2003-01-02 19:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Hashcash 2003-01-02 19:25 ` Hashcash Lars Magne Ingebrigtsen @ 2003-01-02 21:01 ` Simon Josefsson 2003-01-02 21:05 ` Hashcash Lars Magne Ingebrigtsen 0 siblings, 1 reply; 34+ messages in thread From: Simon Josefsson @ 2003-01-02 21:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Hashcash 2003-01-02 21:01 ` Hashcash Simon Josefsson @ 2003-01-02 21:05 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 34+ messages in thread From: Lars Magne Ingebrigtsen @ 2003-01-02 21:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2004-10-06 15:17 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-09-26 15:30 hashcash Adam Sjøgren 2004-09-26 17:36 ` hashcash Simon Josefsson 2004-09-26 20:59 ` hashcash Adam Sjøgren 2004-09-27 2:03 ` hashcash Paul Foley 2004-09-27 14:32 ` hashcash Simon Josefsson 2004-09-27 14:46 ` hashcash Adam Sjøgren 2004-09-29 14:37 ` hashcash Dan Christensen 2004-09-29 14:40 ` hashcash Ted Zlatanov 2004-09-29 19:11 ` hashcash Dan Christensen 2004-09-29 21:08 ` hashcash Magnus Henoch 2004-09-30 14:30 ` hashcash Ted Zlatanov 2004-09-30 20:42 ` hashcash Magnus Henoch 2004-09-27 14:45 ` hashcash Adam Sjøgren 2004-09-27 15:21 ` hashcash Simon Josefsson 2004-09-27 15:38 ` hashcash Adam Sjøgren 2004-09-27 17:13 ` hashcash Jesper Harder 2004-09-27 19:02 ` hashcash Adam Sjøgren 2004-09-27 19:38 ` hashcash Simon Josefsson 2004-09-27 19:54 ` hashcash Adam Sjøgren 2004-09-27 19:56 ` hashcash Jesper Harder 2004-09-27 20:50 ` hashcash Simon Josefsson 2004-09-28 14:08 ` hashcash Ted Zlatanov 2004-09-28 14:49 ` hashcash Simon Josefsson 2004-09-28 17:41 ` hashcash Ted Zlatanov 2004-09-30 20:50 ` hashcash Simon Josefsson 2004-10-04 17:06 ` hashcash Ted Zlatanov 2004-10-04 19:36 ` hashcash Simon Josefsson 2004-10-05 2:34 ` hashcash Dan Christensen 2004-10-06 15:17 ` hashcash Ted Zlatanov 2004-09-27 16:10 ` hashcash Ted Zlatanov -- strict thread matches above, loose matches on Subject: below -- 2002-07-31 19:24 new spam functionality added Ted Zlatanov 2002-07-31 20:14 ` Simon Josefsson 2002-07-31 20:25 ` Josh Huber 2002-07-31 20:34 ` Scott A Crosby 2002-07-31 20:41 ` Josh Huber 2002-07-31 21:07 ` Scott A Crosby 2002-08-02 2:05 ` Jason R. Mastaler 2002-08-02 3:43 ` Russ Allbery 2002-08-02 4:29 ` Jason R. Mastaler 2002-08-02 4:34 ` Russ Allbery 2002-08-02 16:17 ` TMDA (was: new spam functionality added) Paul Jarc 2002-08-05 17:38 ` Per Abrahamsen 2002-08-05 17:49 ` Paul Jarc 2002-08-05 17:57 ` Simon Josefsson 2002-08-05 20:18 ` David Masterson 2002-08-05 20:46 ` Stainless Steel Rat 2002-08-06 3:04 ` David Masterson 2002-08-06 14:27 ` Stainless Steel Rat 2002-08-06 17:13 ` David Masterson 2002-08-06 17:26 ` David Masterson 2002-08-06 18:08 ` Stainless Steel Rat 2002-08-07 12:02 ` Lloyd Zusman 2002-12-30 0:22 ` Hashcash (was: TMDA) Lars Magne Ingebrigtsen 2003-01-02 18:33 ` Hashcash Simon Josefsson 2003-01-02 19:25 ` Hashcash Lars Magne Ingebrigtsen 2003-01-02 21:01 ` Hashcash Simon Josefsson 2003-01-02 21:05 ` Hashcash Lars Magne Ingebrigtsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).