Bug 784015

I can reproduce this. php downgrade fixed this issue. I'll try to find what exactly is failing and (probably) reassign this bug to php

Please try if following fixes the problem:
- open /usr/share/squirrelmail/functions/i18n.php
- in function charset_decode there is line 187:

if (! $save_html) $string = htmlspecialchars ($string);

remove this line and just before "return $ret;" in the same function add this line:

if (! $save_html) $ret = htmlspecialchars ($ret);

thanks

There is extra return, that would prevent this to work correctly. So, instead of steps in comment #2, try following:

- open /usr/share/squirrelmail/functions/i18n.php
- in function charset_decode there is line 187:

if (! $save_html) $string = htmlspecialchars ($string);

change it to:

if (! $save_html) $string = htmlspecialchars ($string, ENT_COMPAT, 'ISO-8859-1');

(In reply to comment #3)
> There is extra return, that would prevent this to work correctly. So, instead
> of steps in comment #2, try following:
> 
> - open /usr/share/squirrelmail/functions/i18n.php
> - in function charset_decode there is line 187:
> 
> if (! $save_html) $string = htmlspecialchars ($string);
> 
> change it to:
> 
> if (! $save_html) $string = htmlspecialchars ($string, ENT_COMPAT,
> 'ISO-8859-1');

1. is there any reason you're not using UTF-8 there?
2. the same kind of bug occurs for expeditor adresses

For example 
From: =?Windows-1251?B?z3Bv4uXw6ug=?= <r.trachtuldd>
results in an empty from in sm

(In reply to comment #4)
> 1. is there any reason you're not using UTF-8 there?

yes, because UTF-8 is what is breaking it. String is decoded later in the code, so it does not have to be utf-8 (yet) and you can even use different encoding. The problem is while ito-8859-1 can happily ignore utf-8 strings, the opposite is not true. htmlspecialchars changed default value for encoding in php 5.4 from iso-8859-1 to utf-8. Also default behavior for htmlspecialchars is to return empty string once it finds non-utf-8 char (if utf-8 encoding is used).

> 2. the same kind of bug occurs for expeditor adresses
> 
> For example 
> From: =?Windows-1251?B?z3Bv4uXw6ug=?= <r.trachtuldd>
> results in an empty from in sm

this is result of the test from comment #3 or situation before the test?

(In reply to comment #5)
> (In reply to comment #4)
> > 1. is there any reason you're not using UTF-8 there?
> 
> yes, because UTF-8 is what is breaking it. String is decoded later in the code,
> so it does not have to be utf-8 (yet) and you can even use different encoding.

So any 8-bit non UTF encoding will work? Will changing it to iso-8859-15 for axample matter at all in the end result?

> 
> > 2. the same kind of bug occurs for expeditor adresses
> > 
> > For example 
> > From: =?Windows-1251?B?z3Bv4uXw6ug=?= <r.trachtuldd>
> > results in an empty from in sm
> 
> this is result of the test from comment #3 or situation before the test?

This is before the test (I don't remember where I put the messages whith broken subjects, but I have plenty of messages with broken froms)

The change fixes froms at least

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > 1. is there any reason you're not using UTF-8 there?
> > 
> > yes, because UTF-8 is what is breaking it. String is decoded later in the code,
> > so it does not have to be utf-8 (yet) and you can even use different encoding.
> 
> So any 8-bit non UTF encoding will work? Will changing it to iso-8859-15 for
> axample matter at all in the end result?

If I do not miss anything, the answer is yes (well, not for your example above as encoding name is case sensitive). What htmlspecialchars does:
""""
The translations performed are:

    '&' (ampersand) becomes '&'
    '"' (double quote) becomes '"' when ENT_NOQUOTES is not set.
    "'" (single quote) becomes ''' only when ENT_QUOTES is set.
    '<' (less than) becomes '&lt;'
    '>' (greater than) becomes '&gt;'
""""
see http://php.net/manual/en/function.htmlspecialchars.php

These characters are in lower 128 bits so it should be the same.

This change just changes it back to what sm used before (ISO-8859-1 was default value in pre 5.4 php).

> This is before the test (I don't remember where I put the messages whith broken
> subjects, but I have plenty of messages with broken froms)
> 
> The change fixes froms at least

OK, thanks for testing

squirrelmail-1.4.22-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2012-2256/squirrelmail-1.4.22-7.fc17

Package squirrelmail-1.4.22-7.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing squirrelmail-1.4.22-7.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-2256/squirrelmail-1.4.22-7.fc17
then log in and leave karma (feedback).

squirrelmail-1.4.22-7.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.