On Monday, September 17 at 10:38 AM, quoth Vincent Lefevre:
On 2007-09-16 11:59:33 -0500, David Champion wrote:Subject: Re: [Mutt] #2956: =?UTF-8//TRANSLIT?Q?Reci?= =?UTF-8//TRANSLIT?Q?pient_address_broken_if_containing_?= =?UTF-8//TRANSLIT?Q?=C5?= character (UTF-8 code: 0xc5 0xA0)I do not set $send_charset. My $charset contains //TRANSLIT, but this one is correct.I thought that //TRANSLIT was a libiconv extension, not defined by spec. It's definitely not supported by all iconv implementations, so those wouldn't be able to parse this encoding string (regardless of correctness).The //TRANSLIT is supported by the libiconv implementations I use here.
The fact that it's supported by the software that you use doesn't make it a valid encoding to send over the internet. We have standards for a reason! None of the encoding names that are valid for use in email include //TRANSLIT. That encoding name is invalid. Just because iconv accepts it doesn't make it valid. If mutt is generating this, then something is wrong... perhaps mutt should recognize and strip out //TRANSLIT strings?
So, that's fine. But this doesn't explain why Mutt uses //TRANSLIT to generate this particular header. It is related to the isspace bug, as this problem doesn't occur with the Euro symbol for instance.
Wait, so, your mutt generates an encoding that doesn't contain //TRANSLIT if it's encoding a Euro symbol? That really is quite strange.
But in any case, Mutt shouldn't generate invalid UTF-8 sequences (like here).
Agreed. ~Kyle --To bathe a cat takes brute force, perseverance, courage of conviction---and a cat. The last ingredient is usually hardest to come by.
-- Stephen Baker
Attachment:
pgpLy1rCOQ1dl.pgp
Description: PGP signature