[ 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!
