Re: [Mutt] #3039: mutt-1.5.17: wrong character set for traditional PGP
#3039: mutt-1.5.17: wrong character set for traditional PGP
Comment (by Alain Bench):
{{{
Hi Thomas,
On Friday, March 21, 2008 at 11:54:31 -0000, Thomas Roessler wrote:
> - Clearsigned messages. In this case, the original message's character
> set is preserved, the message is signed, and the signed message then
> MIME encoded, probably as text/plain. It's pretty clear that we don't
> expect PGP to do any character set mangling in this case, so the
> text/plain body part's charset parameter is properly set to whatever
> the message is written in.
Wrong: The original message's charset is not preserved. Mutt
converts it to UTF-8 before signing.
> - Encrypted messages. In this case, all we see on the MIME level is
> information about the ASCII armor, plus whatever might be around it.
> There is simply no information on the MIME level about what hides
> inside the armor.
Again wrong: There are hints. They can be absent, or wrong, but most
of the time they accurately represent the enclosed charset.
Also wrong on the sending side: Mutt knows which charset it passes
to encryption. And we know for sure that at a later time decryption will
recreate the exact same charset.
> To give one example, there might be a message in some obscure
> encoding, say, iso-8859-7, that then includes an ASCII armored,
> encrypted message in UTF-8 which itself happens to be in Klingon.
Without a "Charset: utf-8" armor header, Tamo's patch would fail.
But it would succeed otherwise. Straight Mutt succeeds in both cases.
Nicely crafted example.
What about another one from real world: A Latin-9 encrypted message
with a Latin-9 "Charset:" armor header and a Latin-9 MIME label. Mutt
fails, Tamo succeeds.
> No, this isn't beautiful, but it seemed to be the most consistent
> interpretation of the relevant specifications.
Another interpretation exists. And I fear to suspect that it
provides a better interoperability in practice.
Bye! Alain.
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3039#comment:>