Description of problem: Attempting to test Squirrelmail's errata resulted in
some strange behavior relating to PHP and Japanese character displaying. I don't
have enough information to be sure it's all archs, but the fact that it happened
(with varying results) on the stable s390x, ia64, and x86_64 qa boxes makes me
suspicious that it's not really arch-specific, regardless of the fact that the
stable i386, ppc, and s390 qa boxes seemed ok (i386 and s390 even appeared to be
able to handle Japanese characters even if the display for Squirrelmail was
still set to English, oddly enough).

Version-Release number of selected component (if applicable):
php-4.3.2-14.ent.i386

How reproducible:
Always, on the ones it was happening on.

Steps to Reproduce:
1. Start imap on the local host if not already running, since Squirrelmail needs
imap and it's easier to configure on one's local box. (imap is handled by xinetd)
2. put the attached file into your imap mail directory (default is 'mail' in the
home directory of user you log into Squirrelmail as)
3. Log into http://hostname/webmail - this will need to be as an existing user
on the server handling imap
4. Go to the 'Folder' setting, and add the folder named the same as the file you
put into the mail directory. Refresh the folder settings so you can see it on
the lefthand side.
5. Go into Options, click Display Preferences, and change the Language to Japanese.
6. Go into the Folder you added. There should be two mail messages here, both of
which are mostly japanese characters. You should also already be seeing "You
need to have php4 installed with the multibyte string function enabled
(using configure option --enable-mbstring)." messages at the top of the screen.
If you try to read either of the two messages, you will see that same message,
as well as "Fatal error: Call to undefined function: mb_detect_encoding() in
/usr/share/squirrelmail/functions/mime.php on line 351"
  
Depending on something I'm not entirely sure of, you might get the initial php
error message upon attempting to log into squirrelmail on the s390x (I may have
left it set to Japanese language. That could explain it, maybe), and not even
manage to login.

Actual results:
Errors about php as mentioned above.

Expected results:
No errors. Should just work happily.

Additional info:

The owner of squirrelmail suspects this behavior is php and not actually
squirrelmail. I had a similar suspicion.

The mbstring extension is known to be 64-bit-unsafe so if it just gives
corrupted output or crashes or something on the 64-bit platforms that's
completely unsurprising.  An "undefined function" error is surprising though -
is that reproducible always?

Created attachment 109718 [details]
Folder as seen in Mozilla Mail (correct)

We believe we're seeing the same bug. Not only are japanese mails
unreadable (invisible), they also cause other mails to disappear from
folder lists. See attached images of the same folder in Mozilla mail
and Squirrelmail.

We're running up2date EL3 on x86_64.

Created attachment 109719 [details]
Folder as seen in Squirrelmail (NOT correct, mails missing)

Could you attach a minimal mailbox which displays correctly e.g. via
Mozilla, and doesn't work correctly via Squirrelmail?

Created attachment 109721 [details]
maildir folder containing problem mails

Here's a maildir folder that contains a sanitized version of the problem mails
in the screenshots, and some additional mails. In squirrelmail, I see none of
the emails in the folder view, in mozilla mail I see them all.

The non-japanese mails can be seen if you search for them using Squirrelmails
built in search feature, but the japanese ones can't.

FYI

We updated to php-4.3.9-3 (and the various things needed for that,
file, pcre, c-client) built from SRPMs from the nahant beta to get
around this. 

(We need it working on monday, when the students show back up)

That fixed it for us until a proper update (or RH4) comes along.

This is fixed in Red Hat Enterprise Linux 4 and later; the mbstring extension
was not 64-bit-safe in earlier releases.