Squirrelmail does not display the subject of some messages (maybe due to rawhide's php bump?). For example (looking at the headers of subject-less messages in SM) Subject: =?windows-1252?Q?Pepe_jeans,_Collection_MGallery,_une_offre_vente-privee-voyage.com,_Floressance_et_Natessance,_B=E9b=E9_de_Remond_pu=E9riculture,_Oncle_Edouard_chaussures_enfants,_Fran=E7oise_Saget_et_Richard_Ginori_1735_art_de_la_table_mardi_24_janvier_chez_vente-privee.com?= Subject: =?iso-8859-1?B?x2EgY29udGludWUgIQ==?=
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 '<' '>' (greater than) becomes '>' """" 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.