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 Thomas Roessler):
{{{
On 2008-03-21 11:18:12 -0000, Mutt wrote:
> > that is something I'd suggest not to do given the strong inclination
> > towards UTF-8 in RFC2440.
> Not so simple: With some recipient mailers and setups, the UTF-8
> sent by Mutt is unreadable. While a well labelled Latin-1 would work
OK.
> And the contrary can happen in some other cases. Standard and practice
> are fighting, and there is no clear winner. There is clearly a looser,
> though: The impacted user.
> Worse: Encrypted UTF-8 mails sent by Mutt have no charset label.
> Properly labelling them "utf-8" would already improve a little bit the
> chances to be readable.
> Needless to say that there are no such ambiguities nor
> unsatisfactory compromises with PGP/MIME. This one is well designed.
Maybe it's time to explain the rationale behind mutt's approach to
charsets with inline PGP... ;-)
There are two fundamentally different situations here:
- 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.
This is the easy case.
- 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.
The best we can do in that situation is try to exploit whatever is
the default for PGP, and that's UTF-8 according to spec. 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. That
would seem to be completely valid according to spec, but would be
mistreated badly by any assumption that the text/plain part's
charset parameter has anything to say about the encrypted content.
No, this isn't beautiful, but it seemed to be the most consistent
interpretation of the relevant specifications.
Bottom line: If you want interoperability for anything beyond ASCII,
go for PGP/MIME.
Cheers,
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3039#comment:>