Description of problem: Sent e-mail Japaneese font is fixed to EUC-JP. Version-Release number of selected component (if applicable): squirrelmail-1.4.6-3.fc4 How reproducible: Just send the mail in Japaneese. Steps to Reproduce: 1.Send email in Japaneese 2.Check sent mail by any program 3. Actual results: Japaneese font is EUC-JP even header says UTF-8 Expected results: This should be configurable and header and font kind should match. Additional info: Prebious version is also fixed to ISO-2022-jp but the heaser and font kind is matched.
Sorry about this problem. A fix will be pushed soon.
http://people.redhat.com/wtogami/temp/squirrelmail-1.4.6-4.fc4.src.rpm Source RPM http://people.redhat.com/wtogami/temp/squirrelmail-1.4.6-4.fc4.noarch.rpm Installable RPM Could you please test this, does it work properly as expected?
Yes, it works fine. Thank you.
There was an error in my 1.4.6-3 package -- although I attempted to change all ja_JP to UTF-8, the specfile still had this... case $LOCALE in ja_JP) # ja_JP uses iso2022-jp for email but euc-jp in its interface. CHARSET=euc-jp ;; If that meant that the web interface was euc-jp, then it's hardly surprising that we got euc-jp text from the web browser, then of course we just send that in email without looking at it... assuming it was UTF-8. A better fix for the 1.4.6-3 package might have been just to remove the offending four lines above.
No, that doesn't make sense -- having looked at it again I remember what that was about. A better option would probably be to disable the XTRA_CODE setting for ja_JP in functions/i18n.php -- the japanese_charset_xtra() function. That seems to be all about these weird special cases for swapping ja_JP charsets, and should probably all be dropped.
By all indications the current rawhide behavior is no worse than upstream's behavior for Japanese, so I am hesitant to make any further changes here.