[Tickets #7043] Re: Forwarded mail with national characters in the subject can be improperly encoded

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7043
------------------------------------------------------------------------------
  Ticket             | 7043
  Updated By         | mark.manning at nexussafe.com
  Summary            | Forwarded mail with national characters in the subject
                     | can be improperly encoded
  Queue              | IMP
  Version            | 4.2
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              | 1
  Owners             |
+New Attachment     | imp_7043_1.zip
------------------------------------------------------------------------------


mark.manning at nexussafe.com (2008-07-14 03:34) wrote:

Sorry about that.  Should have added more complete information and a  
scenario.  The scenario is:

User A sends a mail to User B where the subject of the mail includes  
national characters, in this case Swedish characters.  The encoding  
selected before sending the mail is iso-8859-1.

User B opens the mail, selects "Forward Entire Message", and chooses  
to send the mail with the original message as an inline attachment.  B  
also selects iso-8859-1 as the encoding and sends it to User C.

When C opens the mail, the subject is fine but in the "parts" listing  
you'll see "Forwarded Message: <original_subject>" where  
<original_subject> is the subject but where the UTF-8 characters are  
displayed literally for the national characters.

Attached is forwarded_message.jpg which makes it a lot clearer  
(<original_subject> is circled in the image).  I've also attached the  
MIME message.

As you see in the MIME message, the "name" parameter of the  
message/rfc822 Content-Type header is marked as being encoded in  
us-ascii, but because we are running everything to output UTF-8 the  
actual text string set on the name parameter is UTF-8 encoded.  Not  
sure our web output encoding is really important since when the  
message/rfc822 MIME_Part is created no encoding was being set so it  
defaulted to us-ascii as it should, but this affected the value of the  
name parameter of the Content-Type header where the code assumes it is  
already in whatever character set that applies to the part.