[ could somebody please fix trac to not mangle folded subjects? :) ] Hi, * Kyle Wheeler [07-09-17 09:39:02 -0500] wrote:
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!
I'm absolutely sure he knows this and supports your position strongly. That's not the point... :)
If mutt is generating this, then something is wrong... perhaps mutt should recognize and strip out //TRANSLIT strings?
Yes, but that's another issue (it already has a table of valid character set names, it just needs to match them for $send_charset).
Wait, so, your mutt generates an encoding that doesn't contain //TRANSLIT if it's encoding a Euro symbol? That really is quite strange.
Yes and no. First, this one really is ISSPACE() related I think. After editing a message when composing it, mutt removes trailing spaces in muttt_read_rfc822_line().
As a consequence, 1) you can't write messages with a subject having a trailing slash (nor any other header, btw) (really, not even in us-ascii unless you change it in the compose menu) and 2) it's the cause why 0xc5 0xa0 can't be encoded properly: the 0xa0 likely is removed so that mutt only needs to encode 0xc5.
So technically it invalidates the UTF-8 itself and afterwards more or less encodes the broken subject, I think.
bye, Rocco -- :wq!