Hashcash-generation/check for IDN-domains

Hashcash-generation/check for IDN-domains

[Adam Sjøgren]

  Hi.


I (sort-of) recently acquired the domain 'sjøgren.org'.

I just tried sending an email to adam@sjøgren.org - Gnus nicely asked
me if it should translate sjøgren.org to xn--sjgren-cya.org, and I
happily accepted.

The email arrived, but was split into the nnml:bogus group and an
error-message occured. The following is the messages I get if I go to
nnml:bogus and do B q on the email (after setting gnus-verbose to 10):

 spam-split: widening the buffer (spam-use-crm114 requires it)
 spam-split: calling the spam-check-hashcash function
 Error in `nnmail-split-methods'; using `bogus' mail group
 This message would go to bogus

It seems that the hashcash generated is somehow invalid and/or the
check is (too) fragile. I'm not sure which.

The entire email is:

#v+
X-From-Line: asjo@koldfront.dk  Tue Sep 27 14:34:08 2005
Return-Path: <asjo@koldfront.dk>
X-Original-To: asjo@topper.koldfront.local
Delivered-To: asjo@topper.koldfront.local
Received: from virgil.koldfront.dk (virgil.koldfront.local [192.168.1.111])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by topper.koldfront.dk (Postfix) with ESMTP id 60489F0000E3
	for <asjo@topper.koldfront.local>; Tue, 27 Sep 2005 14:34:08 +0200 (CEST)
Received: by virgil.koldfront.dk (Postfix)
	id 50B7F3A8AF59; Tue, 27 Sep 2005 14:37:14 +0200 (CEST)
Delivered-To: asjo@koldfront.dk
Received: by virgil.koldfront.dk (Postfix, from userid 1010)
	id 4F0A93A8AF5A; Tue, 27 Sep 2005 14:37:14 +0200 (CEST)
Received: from topper.koldfront.dk (gateway.koldfront.dk [192.168.1.1])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by virgil.koldfront.dk (Postfix) with ESMTP id D769E3A8AF59
	for <adam@xn--sjgren-cya.org>; Tue, 27 Sep 2005 14:37:13 +0200 (CEST)
Received: by topper.koldfront.dk (Postfix, from userid 1000)
	id AB77AF0000E3; Tue, 27 Sep 2005 14:34:06 +0200 (CEST)
From: asjo@koldfront.dk (Adam =?iso-8859-1?Q?Sj=F8gren?=)
To: adam@xn--sjgren-cya.org
Subject: Test
Organization: koldfront - analysis & revolution, Copenhagen, Denmark
X-Face: )qY&CseJ?.:=8F#^~GcSA?F=9eu'{KAFfL1C3/A&:nE?PW\i65"ba0NS)97,Q(^@xk}n4Ou
 rPuR#V8I(J_@~H($[ym:`K_+]*kjvW>xH5jbgLBVFGXY:(#4P>zVBklLbdL&XxL\M)%T}3S/IS9lMJ
 ^St'=VZBR<gm`!Dj`dIpp?+$"$l_'JKDN\w-jB;fo0Qy}Tbw
X-Hashcash: =?iso-8859-1?Q?1=3A24=3A050927=3Aadam=40sj=F8gren=2Eorg=3A=3A+?=
 =?iso-8859-1?Q?OOJ2Vgcu8oOshd2=3A0ZBhK?=
Date: Tue, 27 Sep 2005 14:34:01 +0200
X-Gnus-Mail-Source: file:/var/mail/asjo
Message-ID: <878xxid70m.fsf@koldfront.dk>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Checker-Version: SpamAssassin 3.0.3 on virgil.koldfront.dk
X-Spam-Level: 
X-Spam-Status: No, score=-6.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 
	autolearn=ham version=3.0.3
Lines: 6
Xref: topper bogus:19

1-2

-- 
 "Vi falder samme vej eller ej"                               Adam Sjøgren
                                                         asjo@koldfront.dk



#v-

It looks like the hashcash-header was qp-encoded due to the 'ø' in the
domain and this somehow confuses hashcash.el when checking it?


  Best regards,

-- 
 "Vi falder samme vej eller ej"                               Adam Sjøgren
                                                         asjo@koldfront.dk

Other IDN-fixes (was: Hashcash-generation/check for IDN-domains)

[Arne Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

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

> I (sort-of) recently acquired the domain 'sjøgren.org'.
>
> I just tried sending an email to adam@sjøgren.org - Gnus nicely asked
> me if it should translate sjøgren.org to xn--sjgren-cya.org, and I
> happily accepted.

Your posting just reminded me that I've had and used some fixes for
the IDN-handling for some weeks now (since i bought jøssen.dk).

The patch doesn't solve your problem as far as I can tell.

It fixes the following things though:

1. Decoding articles with more than one IDN-address in the same field
   (i.e. "To: adam@sjøgren.dk, arne@jøssen.dk")

   Currently only the last address is decoded, but the patch fixes a
   regexp in `article-decode-idna-rhs' so all are handled.

2. Also encode and decode address in Reply-To:, Mail-Reply-To: and
   Mail-Followup-To:.

3. When `message-use-idna is 'ask you will be asked whether to replace
   the same idna domain once for every time it is in a header (i.e.
   twice about jøssen.dk for "To: arne@jøssen.dk, palle@jøssen.dk")
   but the replacement is done the first time for both/all.

   The patch only asks once for the same idna domain in each header,
   but will still ask twice about jøssen.dk if it is present in both
   say To: and Reply-To: (that would require a bigger rewrite of the
   idna handling).

Kind regards,
-- 
Arne Jørgensen <http://arnested.dk/>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: idna.patch --]
[-- Type: text/x-patch, Size: 4647 bytes --]

Index: lisp/ChangeLog
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/ChangeLog,v
retrieving revision 7.819
diff -u -p -r7.819 ChangeLog
--- lisp/ChangeLog	27 Sep 2005 02:16:37 -0000	7.819
+++ lisp/ChangeLog	27 Sep 2005 14:25:06 -0000
@@ -1,3 +1,18 @@
+2005-09-27  Arne J^[,Ax^[(Brgensen  <arne@arnested.dk>
+
+	* message.el (message-remove-duplicates): New function.
+	Implementation borrowed from `gnus-remove-duplicates'.
+	(message-idna-to-ascii-rhs): Also encode idna addresses in
+	Reply-To:, Mail-Reply-To: and Mail-Followup-To:.
+	(message-idna-to-ascii-rhs-1): When `message-use-idna' is 'ask
+	only ask about the same idna domain once per header and also tell
+	in what header to replace the idna domain.
+
+	* gnus-art.el (article-decode-idna-rhs): Also decode idna
+	addresses in Reply-To:, Mail-Reply-To: and Mail-Followup-To:.
+	(article-decode-idna-rhs): Fix regexp so that all idna-address in
+	a header is decoded and not just the last one.
+
 2005-09-27  Katsumi Yamaoka  <yamaoka@jpl.org>
 
 	* gnus-art.el (gnus-mime-display-single): Don't modify text if it
Index: lisp/gnus-art.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-art.el,v
retrieving revision 7.127
diff -u -p -r7.127 gnus-art.el
--- lisp/gnus-art.el	27 Sep 2005 02:16:36 -0000	7.127
+++ lisp/gnus-art.el	27 Sep 2005 14:25:11 -0000
@@ -2385,20 +2385,22 @@ If PROMPT (the prefix), prompt for a cod
 (autoload 'idna-to-unicode "idna")
 
 (defun article-decode-idna-rhs ()
-  "Decode IDNA strings in RHS in From:, To: and Cc: headers in current buffer."
+  "Decode IDNA strings in RHS in various headers in current buffer.
+The following headers are decoded: From:, To:, Cc:, Reply-To:,
+Mail-Reply-To: and Mail-Followup-To:."
   (when gnus-use-idna
     (save-restriction
       (let ((inhibit-point-motion-hooks t)
 	    (inhibit-read-only t))
 	(article-narrow-to-head)
 	(goto-char (point-min))
-	(while (re-search-forward "@.*\\(xn--[-A-Za-z0-9.]*\\)[ \t\n\r,>]" nil t)
+	(while (re-search-forward "@[^ \t\n\r,>]*\\(xn--[-A-Za-z0-9.]*\\)[ \t\n\r,>]" nil t)
 	  (let (ace unicode)
 	    (when (save-match-data
 		    (and (setq ace (match-string 1))
 			 (save-excursion
 			   (and (re-search-backward "^[^ \t]" nil t)
-				(looking-at "From\\|To\\|Cc")))
+				(looking-at "From\\|To\\|Cc\\|Reply-To\\|Mail-Reply-To\\|Mail-Followup-To")))
 			 (setq unicode (idna-to-unicode ace))))
 	      (unless (string= ace unicode)
 		(replace-match unicode nil nil nil 1)))))))))
Index: lisp/message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 7.95
diff -u -p -r7.95 message.el
--- lisp/message.el	25 Sep 2005 21:27:48 -0000	7.95
+++ lisp/message.el	27 Sep 2005 14:25:16 -0000
@@ -2088,6 +2088,14 @@ With prefix-argument just set Follow-Up,
 
 ;;; End of functions adopted from `message-utils.el'.
 
+(defun message-remove-duplicates (list)
+  (let (new)
+    (while list
+      (or (member (car list) new)
+	  (setq new (cons (car list) new)))
+      (setq list (cdr list)))
+    (nreverse new)))
+
 (defun message-remove-header (header &optional is-regexp first reverse)
   "Remove HEADER in the narrowed buffer.
 If IS-REGEXP, HEADER is a regular expression.
@@ -5027,13 +5035,15 @@ subscribed address (and not the addition
   (let ((field (message-fetch-field header))
 	rhs ace  address)
     (when field
-      (dolist (address (mail-header-parse-addresses field))
-	(setq address (car address)
-	      rhs (downcase (or (cadr (split-string address "@")) ""))
-	      ace (downcase (idna-to-ascii rhs)))
+      (dolist (rhs 
+	       (message-remove-duplicates
+		(mapcar (lambda (rhs) (or (cadr (split-string rhs "@")) ""))
+			(mapcar 'downcase
+				(mapcar 'car (mail-header-parse-addresses field))))))
+	(setq ace (downcase (idna-to-ascii rhs)))
 	(when (and (not (equal rhs ace))
 		   (or (not (eq message-use-idna 'ask))
-		       (y-or-n-p (format "Replace %s with %s? " rhs ace))))
+		       (y-or-n-p (format "Replace %s with %s in %s:? " rhs ace header))))
 	  (goto-char (point-min))
 	  (while (re-search-forward (concat "^" header ":") nil t)
 	    (message-narrow-to-field)
@@ -5053,6 +5063,8 @@ See `message-idna-encode'."
 	(message-idna-to-ascii-rhs-1 "From")
 	(message-idna-to-ascii-rhs-1 "To")
 	(message-idna-to-ascii-rhs-1 "Reply-To")
+	(message-idna-to-ascii-rhs-1 "Mail-Reply-To")
+	(message-idna-to-ascii-rhs-1 "Mail-Followup-To")
 	(message-idna-to-ascii-rhs-1 "Cc")))))
 
 (defun message-generate-headers (headers)

Re: Other IDN-fixes

[Simon Josefsson]

Arne Jørgensen <arne@arnested.dk> writes:

> The patch doesn't solve your problem as far as I can tell.
>
> It fixes the following things though:
>
> 1. Decoding articles with more than one IDN-address in the same field
>    (i.e. "To: adam@sjøgren.dk, arne@jøssen.dk")
>
>    Currently only the last address is decoded, but the patch fixes a
>    regexp in `article-decode-idna-rhs' so all are handled.
>
> 2. Also encode and decode address in Reply-To:, Mail-Reply-To: and
>    Mail-Followup-To:.
>
> 3. When `message-use-idna is 'ask you will be asked whether to replace
>    the same idna domain once for every time it is in a header (i.e.
>    twice about jøssen.dk for "To: arne@jøssen.dk, palle@jøssen.dk")
>    but the replacement is done the first time for both/all.
>
>    The patch only asks once for the same idna domain in each header,
>    but will still ask twice about jøssen.dk if it is present in both
>    say To: and Reply-To: (that would require a bigger rewrite of the
>    idna handling).

Looks good, I installed it, thanks!

Re: Hashcash-generation/check for IDN-domains

[Simon Josefsson]

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

>   Hi.
>
>
> I (sort-of) recently acquired the domain 'sjøgren.org'.
>
> I just tried sending an email to adam@sjøgren.org - Gnus nicely asked
> me if it should translate sjøgren.org to xn--sjgren-cya.org, and I
> happily accepted.
>
> The email arrived, but was split into the nnml:bogus group and an
> error-message occured. The following is the messages I get if I go to
> nnml:bogus and do B q on the email (after setting gnus-verbose to 10):
>
>  spam-split: widening the buffer (spam-use-crm114 requires it)
>  spam-split: calling the spam-check-hashcash function
>  Error in `nnmail-split-methods'; using `bogus' mail group
>  This message would go to bogus
>
> It seems that the hashcash generated is somehow invalid and/or the
> check is (too) fragile. I'm not sure which.

The X-hashcash header sent appeared to contain the non-ASCII
characters, which I believe is wrong.  So it is the generation that is
faulty.  Since, if I recall correctly, it copy the content from
To/From/Cc, it probably should do its own IDN-processing.  I'm not
sure how that would interfact with answering 'n' at the query you
refer to though.  Perhaps that query is simply wrong?  It doesn't make
sense to send mail to non-ASCII domains ever, does it?  So Gnus should
attempt to translate non-ASCII to xn--* via libidn, or refuse to send
the message.  Then the hashcash code could also unconditionally
perform idn-encoding.  Not sure what should happen if idn-encoding
inside the hashcash cookie generation fail though.  Leave the
X-hashcash as-is, with non-ASCII characters?  Or remove the header?

When we knew some more answers to these questions, I can try to
implement them...

> The entire email is:
>
> #v+
> X-From-Line: asjo@koldfront.dk  Tue Sep 27 14:34:08 2005
> Return-Path: <asjo@koldfront.dk>
> X-Original-To: asjo@topper.koldfront.local
> Delivered-To: asjo@topper.koldfront.local
> Received: from virgil.koldfront.dk (virgil.koldfront.local [192.168.1.111])
> 	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> 	(No client certificate requested)
> 	by topper.koldfront.dk (Postfix) with ESMTP id 60489F0000E3
> 	for <asjo@topper.koldfront.local>; Tue, 27 Sep 2005 14:34:08 +0200 (CEST)
> Received: by virgil.koldfront.dk (Postfix)
> 	id 50B7F3A8AF59; Tue, 27 Sep 2005 14:37:14 +0200 (CEST)
> Delivered-To: asjo@koldfront.dk
> Received: by virgil.koldfront.dk (Postfix, from userid 1010)
> 	id 4F0A93A8AF5A; Tue, 27 Sep 2005 14:37:14 +0200 (CEST)
> Received: from topper.koldfront.dk (gateway.koldfront.dk [192.168.1.1])
> 	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> 	(No client certificate requested)
> 	by virgil.koldfront.dk (Postfix) with ESMTP id D769E3A8AF59
> 	for <adam@xn--sjgren-cya.org>; Tue, 27 Sep 2005 14:37:13 +0200 (CEST)
> Received: by topper.koldfront.dk (Postfix, from userid 1000)
> 	id AB77AF0000E3; Tue, 27 Sep 2005 14:34:06 +0200 (CEST)
> From: asjo@koldfront.dk (Adam =?iso-8859-1?Q?Sj=F8gren?=)
> To: adam@xn--sjgren-cya.org
> Subject: Test
> Organization: koldfront - analysis & revolution, Copenhagen, Denmark
> X-Face: )qY&CseJ?.:=8F#^~GcSA?F=9eu'{KAFfL1C3/A&:nE?PW\i65"ba0NS)97,Q(^@xk}n4Ou
>  rPuR#V8I(J_@~H($[ym:`K_+]*kjvW>xH5jbgLBVFGXY:(#4P>zVBklLbdL&XxL\M)%T}3S/IS9lMJ
>  ^St'=VZBR<gm`!Dj`dIpp?+$"$l_'JKDN\w-jB;fo0Qy}Tbw
> X-Hashcash: =?iso-8859-1?Q?1=3A24=3A050927=3Aadam=40sj=F8gren=2Eorg=3A=3A+?=
>  =?iso-8859-1?Q?OOJ2Vgcu8oOshd2=3A0ZBhK?=
> Date: Tue, 27 Sep 2005 14:34:01 +0200
> X-Gnus-Mail-Source: file:/var/mail/asjo
> Message-ID: <878xxid70m.fsf@koldfront.dk>
> User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux)
> MIME-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
> X-Spam-Checker-Version: SpamAssassin 3.0.3 on virgil.koldfront.dk
> X-Spam-Level: 
> X-Spam-Status: No, score=-6.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 
> 	autolearn=ham version=3.0.3
> Lines: 6
> Xref: topper bogus:19
>
> 1-2
>
> -- 
>  "Vi falder samme vej eller ej"                               Adam Sjøgren
>                                                          asjo@koldfront.dk
>
>
>
> #v-
>
> It looks like the hashcash-header was qp-encoded due to the 'ø' in the
> domain and this somehow confuses hashcash.el when checking it?
>
>
>   Best regards,
>
> -- 
>  "Vi falder samme vej eller ej"                               Adam Sjøgren
>                                                          asjo@koldfront.dk

Re: Hashcash-generation/check for IDN-domains

[Arne Jørgensen]

Simon Josefsson <jas@extundo.com> writes:

> It doesn't make sense to send mail to non-ASCII domains ever, does
> it? So Gnus should attempt to translate non-ASCII to xn--* via
> libidn, or refuse to send the message.

In Gnus every thing makes sense ;-)

Maybe the default value of `message-use-idna' should be 't (Always)
instead of 'ask.

I guess 'ask was chosen as the default to make it possible to send
mail non-ASCII domains, but not send mails with typos in the addresses
(since there are only so few domains and MUA's that understand IDN).

Kind regards,
-- 
Arne Jørgensen <http://arnested.dk/>

Re: Hashcash-generation/check for IDN-domains

[Adam Sjøgren]

On Tue, 27 Sep 2005 17:09:49 +0200, Simon wrote:

> The X-hashcash header sent appeared to contain the non-ASCII
> characters, which I believe is wrong.  So it is the generation that is
> faulty.  Since, if I recall correctly, it copy the content from
> To/From/Cc, it probably should do its own IDN-processing.  I'm not
> sure how that would interfact with answering 'n' at the query you
> refer to though.  Perhaps that query is simply wrong?  It doesn't make
> sense to send mail to non-ASCII domains ever, does it?

That depends on whether the MTA that Gnus talks to understands IDN and
can convert itself, right?

But I guess IDN is meant to be handled at the MUA level, and not by
the MTAs?

If that is correct, I don't know why the user is even asked. Perhaps
the author of that piece of code can explain?

> So Gnus should attempt to translate non-ASCII to xn--* via libidn,
> or refuse to send the message. Then the hashcash code could also
> unconditionally perform idn-encoding. Not sure what should happen if
> idn-encoding inside the hashcash cookie generation fail though. 
> Leave the X-hashcash as-is, with non-ASCII characters? Or remove the
> header?

If the user really shouldn't be asked (above), it's easy (always
idn-encode in hashcash.el).

I think it sounds reasonable that if hashcash.el fails to generate a
payment, the header should not be added?


The checking does seem a little too fragile though, in that spam-split
breaks just because hashcash.el can't understand a Hashcash-header
(i.e. the mail-check-payment should just return false when the header
is not understandable, right? Instead of the error that makes nnmail
think that my fancy-split configuration is invalid).

> When we knew some more answers to these questions, I can try to
> implement them...

Great O:-)


  Best regards,

-- 
 "Mr. Cotton's... parrot. Same question."                     Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Hashcash-generation/check for IDN-domains

[Simon Josefsson]

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

> On Tue, 27 Sep 2005 17:09:49 +0200, Simon wrote:
>
>> The X-hashcash header sent appeared to contain the non-ASCII
>> characters, which I believe is wrong.  So it is the generation that is
>> faulty.  Since, if I recall correctly, it copy the content from
>> To/From/Cc, it probably should do its own IDN-processing.  I'm not
>> sure how that would interfact with answering 'n' at the query you
>> refer to though.  Perhaps that query is simply wrong?  It doesn't make
>> sense to send mail to non-ASCII domains ever, does it?
>
> That depends on whether the MTA that Gnus talks to understands IDN and
> can convert itself, right?
>
> But I guess IDN is meant to be handled at the MUA level, and not by
> the MTAs?

Right.  There is no non-ASCII API for sending e-mail.  MUAs should
IDN-encode strings.

> If that is correct, I don't know why the user is even asked. Perhaps
> the author of that piece of code can explain?

I wrote the code...  I think Arne is correct, the question was added
to avoid IDN-encoding of non-ASCII typos.  But interaction is bad.

The query is only enabled if the optional idna.el package AND the
external "idn" binary is installed.  If both of those are true, it is
likely that encoding will work.

I have changed the default to t in both 5.10 and CVS.  I also made the
test whether to enable encoding do a test-encoding to see whether it
works or not:

(defcustom message-use-idna (and (condition-case nil (require 'idna)
				   (file-error))
				 (mm-coding-system-p 'utf-8)
				 (executable-find idna-program)
				 (string= (idna-to-ascii "räksmörgås")
					  "xn--rksmrgs-5wao1o")
				 t)
  "Whether to encode non-ASCII in domain names into ASCII according to IDNA.
GNU Libidn, and in particular the elisp package \"idna.el\" and
the external program \"idn\", must be installed for this
functionality to work."
  :version "22.1"
  :group 'message-headers
  :link '(custom-manual "(message)IDNA")
  :type '(choice (const :tag "Ask" ask)
		 (const :tag "Never" nil)
		 (const :tag "Always" t)))

>> So Gnus should attempt to translate non-ASCII to xn--* via libidn,
>> or refuse to send the message. Then the hashcash code could also
>> unconditionally perform idn-encoding. Not sure what should happen if
>> idn-encoding inside the hashcash cookie generation fail though. 
>> Leave the X-hashcash as-is, with non-ASCII characters? Or remove the
>> header?
>
> If the user really shouldn't be asked (above), it's easy (always
> idn-encode in hashcash.el).
>
> I think it sounds reasonable that if hashcash.el fails to generate a
> payment, the header should not be added?

But it can still generate a payment, but it would not be to the
IDN-encoded address.  It would contain non-ASCII as in the posted
example.  I'm not sure whether sending that weird header out or
removing it is the best choice.  I'm leaning towards removing the
header of IDN-encoding fails.

> The checking does seem a little too fragile though, in that spam-split
> breaks just because hashcash.el can't understand a Hashcash-header
> (i.e. the mail-check-payment should just return false when the header
> is not understandable, right? Instead of the error that makes nnmail
> think that my fancy-split configuration is invalid).

What error is that?  Does it say "Unknown hashcash format version"?
Perhaps the call to hashcash.el should be made in a condition-case.

Re: Hashcash-generation/check for IDN-domains

[Adam Sjøgren]

On Wed, 28 Sep 2005 11:40:46 +0200, Simon wrote:

> I wrote the code...  I think Arne is correct, the question was added
> to avoid IDN-encoding of non-ASCII typos.  But interaction is bad.

Ah, okay.

[...]
>> I think it sounds reasonable that if hashcash.el fails to generate
>> a payment, the header should not be added?

> But it can still generate a payment, but it would not be to the
> IDN-encoded address.  It would contain non-ASCII as in the posted
> example.  I'm not sure whether sending that weird header out or
> removing it is the best choice.  I'm leaning towards removing the
> header of IDN-encoding fails.

I was imprecise; I agree.

>> The checking does seem a little too fragile though, in that spam-split
>> breaks just because hashcash.el can't understand a Hashcash-header
>> (i.e. the mail-check-payment should just return false when the header
>> is not understandable, right? Instead of the error that makes nnmail
>> think that my fancy-split configuration is invalid).

> What error is that?  Does it say "Unknown hashcash format version"?
> Perhaps the call to hashcash.el should be made in a condition-case.

That is where it failed, in hashcash-version, when I got the message
about error in nnmail-split-methods.

It's easy to recreate, just put the email in a buffer and run
mail-check-payment: "Unknown hashcash format version".


  Best regards,

     Adam

-- 
 "Ett, två, tre, pang på rödbetan."                           Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Hashcash-generation/check for IDN-domains

[Simon Josefsson]

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

>>> The checking does seem a little too fragile though, in that spam-split
>>> breaks just because hashcash.el can't understand a Hashcash-header
>>> (i.e. the mail-check-payment should just return false when the header
>>> is not understandable, right? Instead of the error that makes nnmail
>>> think that my fancy-split configuration is invalid).
>
>> What error is that?  Does it say "Unknown hashcash format version"?
>> Perhaps the call to hashcash.el should be made in a condition-case.
>
> That is where it failed, in hashcash-version, when I got the message
> about error in nnmail-split-methods.
>
> It's easy to recreate, just put the email in a buffer and run
> mail-check-payment: "Unknown hashcash format version".

Can you test this patch?

2005-09-29  Simon Josefsson  <jas@extundo.com>

	* spam.el: Load hashcash when compiling, to avoid warnings.  Don't
	autoload mail-check-payment.
	(spam-check-hashcash): Define unconditionally, since hashcash.el
	is part of Gnus now.  Ignore errors from payment checking.

--- spam.el	27 Sep 2005 16:46:44 +0200	7.75
+++ spam.el	29 Sep 2005 15:34:25 +0200	
@@ -42,6 +42,7 @@
 
 (eval-when-compile (require 'cl))
 (eval-when-compile (require 'spam-report))
+(eval-when-compile (require 'hashcash))
 
 (require 'gnus-sum)
 
@@ -2023,18 +2024,10 @@
 
 ;;{{{ Hashcash.
 
-(eval-when-compile
-  (autoload 'mail-check-payment "hashcash"))
-
-(condition-case nil
-    (progn
-      (require 'hashcash)
-
       (defun spam-check-hashcash ()
 	"Check the headers for hashcash payments."
-	(mail-check-payment)))	 ;mail-check-payment returns a boolean
+  (ignore-errors (mail-check-payment)))	 ;mail-check-payment returns a boolean
 
-  (file-error))
 ;;}}}
 
 ;;{{{ BBDB

Re: Hashcash-generation/check for IDN-domains

[Adam Sjøgren]

On Thu, 29 Sep 2005 15:36:30 +0200, Simon wrote:

> Can you test this patch?

Sure. It works great.

> 2005-09-29  Simon Josefsson  <jas@extundo.com>

> 	* spam.el: Load hashcash when compiling, to avoid warnings.  Don't
> 	autoload mail-check-payment.
> 	(spam-check-hashcash): Define unconditionally, since hashcash.el
> 	is part of Gnus now.  Ignore errors from payment checking.


  Best regards,

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

Re: Hashcash-generation/check for IDN-domains

[Simon Josefsson]

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

> On Thu, 29 Sep 2005 15:36:30 +0200, Simon wrote:
>
>> Can you test this patch?
>
> Sure. It works great.

Applied, thanks for testing!