Re: Hashcash-generation/check for IDN-domains

[Simon Josefsson <jas@extundo.com>]

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.