| Summary | Forwarded mail with national characters in the subject can be improperly encoded |
| Queue | IMP |
| Queue Version | 4.2 |
| Type | Enhancement |
| State | Rejected |
| Priority | 1. Low |
| Owners | |
| Requester | mark.manning (at) nexussafe (dot) com |
| Created | 07/07/2008 (6207 days ago) |
| Due | |
| Updated | 07/15/2008 (6199 days ago) |
| Assigned | |
| Resolved | 07/15/2008 (6199 days ago) |
| Milestone | |
| Patch | Yes |
http://cvs.horde.org/diff.php/imp/lib/Compose.php?r1=1.365&r2=1.366
New Attachment: imp_7043_1.zip
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.
State ⇒ Feedback
message that is incorrectly forwarded? Which forwarding method do you
use? And which is your default charset for sending messages?
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Forwarded mail with national characters in the subject can be improperly encoded
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ Yes
New Attachment: imp_lib_Compose.php.patch
State ⇒ New
when the receiver views the message the "Forwarded Message: [subject]"
line can display the "[subject]" incorrectly. The underlying cause is
that the name parameter of the Content-Type header is marked with the
wrong charset. In our case, for example, the text was in UTF-8 but
was marked as us-ascii.
Attached is a working patch but I have to admit I don't really like
the solution. A lot of mail clients (well, Microsoft's anyway) don't
always handle MIME messages correctly and assume the first character
encoding they stumble over is the one that applies for everything in
the message. In this case they will see utf-8 whereas the actual
message may have other/another encoding for other MIME parts.