Fedora Account System
Red Hat Associate
Red Hat Customer
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.