Unfortunately at this point, you need to trace the code to find 
exactly where the issue is.  Rendering of an HTML part in IMP occurs 
in the IMP_Mime_Viewer_Html class, so that's a good place to start 
tracing the code.

nope:

[root@mail ~]# locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_GB.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=

anything else I could check?

That's probably because we are actually parsing the DOM structure of 
the HTML data using the php DOM functions (using underlying libxml2 
library) and they aren't.  I'm still guessing that's the issue in your 
case, although it must be tied to some local configuration of yours 
since I'm not seeing it on my test server.  (Granted, your server 
locale is probably set to DE by default while mine is set to EN so 
that is a fairly significant difference that might be one of the 
issues).

very interesting! good to know there is no fundamental problem running 
horde on CentOS.
cannot promise anything here - it will take time to set up a separate 
IMAP server and client is not sure they want to pursue the horde 
evaluation further.

anyway, I can report that Open-Xchange running on the same machine / 
displaying the same message from the same IMAP server displays the 
EMail correctly.

I have tested this message on a fresh CentOS 6.5 install on a VM, with 
brand new install of horde-webmail 5.1.6.  The data displays fine.

It's possible that it is your IMAP server that is causing the issue - 
providing garbage data.  If there is any way to connect to a different 
IMAP server and view that same message on the CentOS installation, 
that would be helpful.

I think typically RHEL will prefer backporting fixes instead of 
updating to new versions. it will be hard to push for a fix unless we 
know specifically what the problem could be.

Not really.  I just know from experience/hearsay from the list that 
updating one/other solves this kind of issue almost every time.  PHP 
5.3.3 is all sorts of ancient and there have been numerous bug fixes 
since then that have directly affected Horde functionality.

uh, that will be a problem since the server is running on RHEL/CentOS 
so the version of the system packages is pretty fixed. we have

php-5.3.3
libxml2-2.7.6

here is there any reference you could point me to where I could find 
more information about this? I could then look into building our own 
php/libxml packages or seek other repositories that have never, but 
unofficial versions. it would make things easier if I knew what fix 
exactly I am looking for, that's why I'm asking. Something charset / 
unicode detection related maybe?

IIRC, this is most likely due to an old version of PHP, and old 
version of libxml, or both.  Try upgrading one/both.  (I'm testing on 
PHP 5.4.26 with libxml 2.9.1)

thanks for the quick reply. attached is a screenshot of the message 
display on my machine - maybe this is something browser/default 
charset related? but if so, is this a client or server setting? 
behavior on our side looks pretty consistent across various browsers 
and machines (windows, linux, firefox, chrome).

Displays perfectly fine here.

In the body text I see a short message in German followed by a quoted 
message (also in German).  And 1 PDF attachment is displayed.