Bug 185767 - Japaneese encoding of sent mail incorrectly EUC-JP
Japaneese encoding of sent mail incorrectly EUC-JP
Product: Fedora
Classification: Fedora
Component: squirrelmail (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Warren Togami
Depends On:
Blocks: 171491
  Show dependency treegraph
Reported: 2006-03-17 14:23 EST by Hyde Yamakawa
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-07 22:56:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hyde Yamakawa 2006-03-17 14:23:49 EST
Description of problem:
Sent e-mail Japaneese font is fixed to EUC-JP.

Version-Release number of selected component (if applicable):

How reproducible:
Just send the mail in Japaneese.

Steps to Reproduce:
1.Send email in Japaneese
2.Check sent mail by any program
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
Comment 1 Warren Togami 2006-03-19 12:23:20 EST
Sorry about this problem.  A fix will be pushed soon.
Comment 2 Warren Togami 2006-03-24 08:17:44 EST
Source RPM
Installable RPM

Could you please test this, does it work properly as expected?
Comment 3 Hyde Yamakawa 2006-03-24 12:13:41 EST
Yes, it works fine.

Thank you.
Comment 4 David Woodhouse 2006-04-07 07:04:59 EDT
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 uses iso2022-jp for email but euc-jp in its interface.

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.
Comment 5 David Woodhouse 2006-04-07 07:47:34 EDT
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.
Comment 6 Warren Togami 2006-04-07 22:55:57 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.