* Hashcash-generation/check for IDN-domains @ 2005-09-27 13:23 Adam Sjøgren 2005-09-27 14:29 ` Other IDN-fixes (was: Hashcash-generation/check for IDN-domains) Arne Jørgensen 2005-09-27 15:09 ` Hashcash-generation/check for IDN-domains Simon Josefsson 0 siblings, 2 replies; 11+ messages in thread From: Adam Sjøgren @ 2005-09-27 13:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Other IDN-fixes (was: Hashcash-generation/check for IDN-domains) 2005-09-27 13:23 Hashcash-generation/check for IDN-domains Adam Sjøgren @ 2005-09-27 14:29 ` Arne Jørgensen 2005-09-27 15:14 ` Other IDN-fixes Simon Josefsson 2005-09-27 15:09 ` Hashcash-generation/check for IDN-domains Simon Josefsson 1 sibling, 1 reply; 11+ messages in thread From: Arne Jørgensen @ 2005-09-27 14:29 UTC (permalink / raw) [-- 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) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Other IDN-fixes 2005-09-27 14:29 ` Other IDN-fixes (was: Hashcash-generation/check for IDN-domains) Arne Jørgensen @ 2005-09-27 15:14 ` Simon Josefsson 0 siblings, 0 replies; 11+ messages in thread From: Simon Josefsson @ 2005-09-27 15:14 UTC (permalink / raw) Cc: ding 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! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hashcash-generation/check for IDN-domains 2005-09-27 13:23 Hashcash-generation/check for IDN-domains Adam Sjøgren 2005-09-27 14:29 ` Other IDN-fixes (was: Hashcash-generation/check for IDN-domains) Arne Jørgensen @ 2005-09-27 15:09 ` Simon Josefsson 2005-09-27 15:31 ` Arne Jørgensen 2005-09-27 15:54 ` Adam Sjøgren 1 sibling, 2 replies; 11+ messages in thread From: Simon Josefsson @ 2005-09-27 15:09 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hashcash-generation/check for IDN-domains 2005-09-27 15:09 ` Hashcash-generation/check for IDN-domains Simon Josefsson @ 2005-09-27 15:31 ` Arne Jørgensen 2005-09-27 15:54 ` Adam Sjøgren 1 sibling, 0 replies; 11+ messages in thread From: Arne Jørgensen @ 2005-09-27 15:31 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hashcash-generation/check for IDN-domains 2005-09-27 15:09 ` Hashcash-generation/check for IDN-domains Simon Josefsson 2005-09-27 15:31 ` Arne Jørgensen @ 2005-09-27 15:54 ` Adam Sjøgren 2005-09-28 9:40 ` Simon Josefsson 1 sibling, 1 reply; 11+ messages in thread From: Adam Sjøgren @ 2005-09-27 15:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hashcash-generation/check for IDN-domains 2005-09-27 15:54 ` Adam Sjøgren @ 2005-09-28 9:40 ` Simon Josefsson 2005-09-28 9:57 ` Adam Sjøgren 0 siblings, 1 reply; 11+ messages in thread From: Simon Josefsson @ 2005-09-28 9:40 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hashcash-generation/check for IDN-domains 2005-09-28 9:40 ` Simon Josefsson @ 2005-09-28 9:57 ` Adam Sjøgren 2005-09-29 13:36 ` Simon Josefsson 0 siblings, 1 reply; 11+ messages in thread From: Adam Sjøgren @ 2005-09-28 9:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hashcash-generation/check for IDN-domains 2005-09-28 9:57 ` Adam Sjøgren @ 2005-09-29 13:36 ` Simon Josefsson 2005-09-29 14:35 ` Adam Sjøgren 0 siblings, 1 reply; 11+ messages in thread From: Simon Josefsson @ 2005-09-29 13:36 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hashcash-generation/check for IDN-domains 2005-09-29 13:36 ` Simon Josefsson @ 2005-09-29 14:35 ` Adam Sjøgren 2005-09-30 0:19 ` Simon Josefsson 0 siblings, 1 reply; 11+ messages in thread From: Adam Sjøgren @ 2005-09-29 14:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Hashcash-generation/check for IDN-domains 2005-09-29 14:35 ` Adam Sjøgren @ 2005-09-30 0:19 ` Simon Josefsson 0 siblings, 0 replies; 11+ messages in thread From: Simon Josefsson @ 2005-09-30 0:19 UTC (permalink / raw) Cc: ding 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! ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-09-30 0:19 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-09-27 13:23 Hashcash-generation/check for IDN-domains Adam Sjøgren 2005-09-27 14:29 ` Other IDN-fixes (was: Hashcash-generation/check for IDN-domains) Arne Jørgensen 2005-09-27 15:14 ` Other IDN-fixes Simon Josefsson 2005-09-27 15:09 ` Hashcash-generation/check for IDN-domains Simon Josefsson 2005-09-27 15:31 ` Arne Jørgensen 2005-09-27 15:54 ` Adam Sjøgren 2005-09-28 9:40 ` Simon Josefsson 2005-09-28 9:57 ` Adam Sjøgren 2005-09-29 13:36 ` Simon Josefsson 2005-09-29 14:35 ` Adam Sjøgren 2005-09-30 0:19 ` Simon Josefsson
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).