Am 26.03.2013 08:50, schrieb Thomas Bruederli:
On Mon, Mar 25, 2013 at 11:14 PM, Michael Heydekamp listuser@freexp.de wrote:
Am 19.02.2013 22:24, schrieb Reindl Harald:
PHP 5.4?
No, 5.3.3-7+squeeze14 with Suhosin-Patch (cli)
Works for me with PHP 5.4.
default behavior starting with 5.4 is idiotically return an empty string if the inout is not a valid UTF8 string and do not log any warning [...]
Well, but then this can't be the cause, right?
It could, because the Subject indeed contains latin1 characters which are not correctly encoded.
True (except that they're not encoded at all ather than being incorrectly encoded), but: If Harald is correct that PHP starting with 5.4 is returning an empty string, then PHP 5.3.3-7 can't be the cause, that's what I mean. And 5.3.3-7 can even be less the cause, if it works for you even with PHP 5.4.
It's a typical example of crappy email messages sent around from PHP scripts tackled together by stupid programmers.
Full ACK. The question still is how Roundcube should handle such broken messages.
The message doesn't specify a Content-Type and no charset at all. And it nonetheless contains plain Latin1 characters in both the body and the subject.
In this case, Roundcube falls back to default_charset config option. The message renders correctly for me with $rcmail_config['default_charset'] = 'ISO-8859-1'; and also replying works fine in that case.
Hmm, funny! Here it does still behave different, although 'default_charset' is set to 'ISO-8859-1' as well.
8bit chars are still deleted in the display, subject keeps empty upon replying.
Needs investigation... What can I do?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany