Am 26.03.2013 08:50, schrieb Thomas Bruederli: > On Mon, Mar 25, 2013 at 11:14 PM, Michael Heydekamp <[email protected]> > 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 _______________________________________________ Roundcube Development discussion mailing list [email protected] http://lists.roundcube.net/mailman/listinfo/dev
