<<< Date Index >>>     <<< Thread Index >>>

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:>