Changes have been made in Git for this ticket:

Make sure that text mime parts always return a charset (Bug #10925).

  2 files changed, 5 insertions(+), 4 deletions(-)
http://git.horde.org/horde-git/-/commit/bc92e1e0465c2bd4c77f5790b11ebdfe2ecf540b

error_reporting() not returning 0 is xdebug's fault.

Okay, this problem is two-fold and in Horde_String::_convertCharset(). 
First of all, $from is empty, which is causing iconv() and 
mb_convert_encoding() to raise errors. I'm going to further track this 
down.
But then there seems to be some problem with my PHP, or at least the 
PHP documentation. Inside the error handler, error_reporting() is 
supposed to return 0 if the command that caused the error is prefixed 
with @, which we do when calling @iconv(). error_reporting() still 
returns the error level for me though, so we don't return false from 
the error handler, thus $php_errormsg is not set in _convertCharset(), 
and we don't try mb_convert_encoding() (which would succeed if we 
tried that).
Do you use iconv at all? If yes, does calling iconv() from that 
message returns an error for you too? If yes, is it because $from is 
empty, and does error_reporting() indeed return 0 in the error handler?

That was my first thought too, but if I understand the PHP changelog 
correctly, this happend in 5.3.3 and I'm on 5.3.6 which is still 
pretty recent.
Beside that, the json extension shouldn't get invalid UTF-8 at all. 
IIUC IMP/Horde_Mime assume the default charset from my preferences, if 
none is specified, like in this message. It's then supposed to convert 
from this default charset to UTF-8 before passing it to json_encode().

Works perfectly for me - I see garbage for the unencoded characters, 
but the entire message is readable (I believe my default for unencoded 
messages is US-ASCII, which is the Horde default).

If messages are being truncated, that sounds like an issue with PHP 
json encoding.  IIRC, newer PHP versions do a better job of recovering 
from bad UTF-8 input than older versions.

I tend to get broken messages from time to time, usually sent from 
some web script by people that don't know what they are doing. They 
don't have a MIME-Version header, but still use non-ascii chars, often 
not even encoded, or text/html content types.
I don't expect those message to be rendered how the sender intended, 
because we don't know about his intentions. But at the moment, those 
message are only displayed up to the first non-ascii character, even 
though I specified the (correct) default charset for messages without 
charset information.
Attached is such a message.