Bug 194457 - squirrelmail cannot handle handle multibyte characters in attachment.
squirrelmail cannot handle handle multibyte characters in attachment.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: squirrelmail (Show other bugs)
4.0
All Linux
high Severity high
: ---
: ---
Assigned To: Warren Togami
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-08 06:43 EDT by Issue Tracker
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2006-0668
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-26 08:26:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 1 Issue Tracker 2006-06-08 06:43:35 EDT
Description of problem:

After update squirrelmail to squirrelmail-1.4.6-5.el4, it can't handle
handle multibyte characters in the bese64 attachment correctly.

Version-Release number of selected component (if applicable):
squirrelmail-1.4.6-5.el4

How reproducible:
Always

Steps to Reproduce:

1. accesss http://dhcp-82.brisbane.redhat.com/webmail/src/webmail.php

Actual results:
Please see Actual_results_01.png or Actual_results_02.png

Expected results:
Please see Expected_results.png

Additional info:
squirrelmail-1.4.3a-9.EL4 works fine, but the latest version can not 
treat multibyte characters in the bese64 attachment.

It seems that a bug in formatBody() of functions/mime.php.
It passes the wrong args against translateText(). 
Or $body_message->header->getParameter('charset'), it may not
work correctly.

Kind regards,
Fuchi

This event sent from IssueTracker by jnansi  [Support Engineering Group]
 issue 95106
Comment 9 Warren Togami 2006-06-08 12:31:38 EDT
Copied Fuchi's mail to another RHEL4 server and tried to read it in both
versions of Squirrelmail, with Japanese language mode set for the interface, and
Firefox web browser.  The results that I'm seeing indicate that even the
previous version wasn't working properly.

http://people.redhat.com/wtogami/temp/squirrelmail-1.4.3a-9.EL4.png
The garbage text where the attachment text should be viewable is encoded in
UTF-8, while the rest of the Japanese text in both the interface and body are
EUC-JP.  If you view this in either Firefox or Konqueror, you can read the
attachment text *ONLY* if you force the encoding to UTF-8.  But then you can't
read anything else on the page, because everything else is EUC-JP encoded and it
becomes garbage.

http://people.redhat.com/wtogami/temp/squirrelmail-1.4.6-5.el4.png
In the case of the newer squirrelmail, it does fail to display UTF-8 where the
attachment text is.

Key questions here:
1) *WHY* has the Squirrelmail web interface always been in EUC-JP?  This doesn't
match the encoding of most incoming mail (ISO-2022-JP) and it isn't UTF-8 or
ASCII compatible.
2) It appears that the "Expected result" screenshot above is using Safari.  Does
Safari behave differently in your tests from Firefox in rendering different
parts of the page in different encodings?  In my tests the browsers cannot
handle this mixed encoding display that the old version of squirrelmail did.
Comment 10 Warren Togami 2006-06-08 12:39:43 EDT
To be clear, it seems to me that between 1.4.3a and 1.4.6, the view attachment
behavior went from one broken behavior to another broken behavior.  Is this not
the case?
Comment 11 Issue Tracker 2006-06-14 00:51:16 EDT
translateText() is added new arg in test5.patch. It is not good,
since translateText() is called the other main php, like view_text.php. 


This event sent from IssueTracker by fuchi 
 issue 95106
Comment 13 Warren Togami 2006-07-10 13:24:57 EDT
http://people.redhat.com/wtogami/temp/squirrelmail-1.4.7-2.el4.noarch.rpm
Believed to be fixed in FC and this test package.
Comment 30 Red Hat Bugzilla 2006-09-26 08:26:39 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0668.html

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