Description of problem: An update to 1.4.7-2 brings a new file /etc/squirrelmail/config_local.php Only that file looks like follows: <?php ..... ?> $default_folder_prefix = ''; Logging to squirrelmail with such configuration immediately produces: Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /etc/squirrelmail/config_local.php:19) in /usr/share/squirrelmail/functions/global.php on line 374 Warning: Cannot modify header information - headers already sent by (output started at /etc/squirrelmail/config_local.php:19) in /usr/share/squirrelmail/functions/i18n.php on line 335 Warning: Cannot modify header information - headers already sent by (output started at /etc/squirrelmail/config_local.php:19) in /usr/share/squirrelmail/functions/global.php on line 346 Warning: Cannot modify header information - headers already sent by (output started at /etc/squirrelmail/config_local.php:19) in /usr/share/squirrelmail/src/login.php on line 53 and much more of the same if you will try to continue, making the whole thing really unusable. With a configuration which is not sending warning to a screen this is a bit better but not much. "$default_folder_prefix = '';" gets printed on a screen and this is enough to kill a mail display. Switching the last two lines in /etc/squirrelmail/config_local.php fixes that immediately. Users can obviously edit that file, if they figure out what is going on, and this is config so maybe even it will not clobbered on subsequent updates. OTOH if this file ends gets included this makes web server quite unhappy. Version-Release number of selected component (if applicable): squirrelmail-1.4.7-2.fc5.noarch.rpm
Downgrading to 1.4.6-7.fc5 is currently the fastest fix.
> Downgrading to 1.4.6-7.fc5 is currently the fastest fix. Don't overdo it. :-) Changing an order of two lines in /etc/squirrelmail/config_local.php is surely faster; especially when you were told which two lines.
squirrelmail-1.4.7-4* has been pushed to updates solving this issue. The trouble with this is that my testing didn't show any problem because my config_local.php was modified, and %config(noreplace) hid the problem. Meanwhile I wanted to get the security update out. I screwed up and take responsibility for this mistake.
*** Bug 198340 has been marked as a duplicate of this bug. ***
*** Bug 198334 has been marked as a duplicate of this bug. ***
*** Bug 198521 has been marked as a duplicate of this bug. ***
*** Bug 198559 has been marked as a duplicate of this bug. ***
*** Bug 198792 has been marked as a duplicate of this bug. ***