FYI: i contacted the Courier IMAP author and here is his response:
http://sourceforge.net/mailarchive/message.php?msg_id=30382228

i'm very sorry, problem is fixed! thank you again

I tried to apply the patch on my installation and it looks like it 
didn't resolve the problem - headers are still not displayed :(

thank you!

Changes have been made in Git (master):

commit c249bac9500df86d05e5789c53a38dde9dd2da4c
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Mon Jan 21 14:57:01 2013 -0700

     [mms] Ignore fetch data returned from an UID FETCH command if it 
doesn't include UID information (Bug #11946).

  .../Imap_Client/lib/Horde/Imap/Client/Socket.php   |   12 +++++++++++-
  framework/Imap_Client/package.xml                  |    2 ++
  2 files changed, 13 insertions(+), 1 deletions(-)

http://git.horde.org/horde-git/-/commit/c249bac9500df86d05e5789c53a38dde9dd2da4c

Although not a bug... I have tweaked Imap_Client to ignore this kind 
of broken data (UID fetch results that do not contain UID information).

I provided software name and version in comment #13:
Courier IMAP version 4.8.0-3 (Debian 6.0.6)

Yes... my mistake.  Copy/paste error.

So now it is verified - your IMAP server is badly broken.  It is 
explicitly breaking the IMAP RFC spec.  I don't see any need to 
workaround this, because it is blatantly broken (you haven't provided 
your software/version).

isn't the command on the very first line of both files?

C: 7 UID FETCH 9 (BODY[HEADER])

Ahh... this is a broken IMAP response.  You did not provide the entire 
IMAP log but I am guessing that this response:

S: * 1 FETCH (UID 9 BODY[HEADER] {1409}
S: <<<FULL HEADERS>>>
S: )
S: * 1 FETCH (FLAGS (\Seen))

Was caused by this command:

a UID FETCH 9 (BODY[HEADER])

A correct response would look like:

S: * 1 FETCH (UID 9 BODY[HEADER] {1409}
S: <<<FULL HEADERS>>>
S: ) FLAGS (\Seen))

--or--

S: * 1 FETCH (UID 9 BODY[HEADER] {1409}
S: <<<FULL HEADERS>>>
S: )
S: * 1 FETCH (UID 9 FLAGS (\Seen))

So the problem is that we are asking for UID fetch results, but the 
server is throwing in some sequence-only results instead.  And this is 
not allowed if, in fact, this is called from a UID FETCH command.   
From RFC 3501 [6.8]:

       However, server implementations MUST implicitly
       include the UID message data item as part of any FETCH response
       caused by a UID command, regardless of whether a UID was specified
       as a message data item to the FETCH.

Can you verify the command that caused these responses and the IMAP 
software version used?

What other feedback do you need? I already uploaded raw IMAP 
communication yesterday. Thnks.

Attaching two files (headers are censored):

error.log
-----------
Part of IMAP communication when no headers are displayed



ok.log
--------
Part of IMAP communication where everything is ok.



As you can see, additional line 'S: * 1 FETCH (FLAGS (\Seen))' is in 
error.log. I'm using Courier IMAP version 4.8.0-3 (Debian 6.0.6).

Except I (nor anybody else) can reproduce this.  Sounds like a 
potentially broken IMAP server.  You will need to post the IMAP logs 
of a successful view vs. an unsuccesful view.



To further debug this issue, we need details of the IMP -> IMAP/POP 
communication.

To enable debugging, see instructions contained in 
imp/config/backends.php (the 'debug' config parameter).

Debugging should not be enabled on a production server,   Attach/post 
only the portion of the log that directly deals with the problem 
reported (it may be simplest to clear the log file and then perform 
the event that causes the error).

I believe that problem is doing the second 
'Horde_Imap_Client_Data_Fetch Object' right after the section with 
headers. IMP is probably considering it as a section with headers and, 
cos it's empty, is displaying no headers.

I found out that function _getHeader (from imp/lib/Contents.php) is 
returning empty headers when parameter $seen is true and when opening 
unseen message. I'm attaching two files (i censored headers and 
message text from both of them), it is the output from file 
Imap/Client/Base.php function fetch():

seen-message-headers-ok.txt
---
Already seen message, headers were displayed ok.



unseen-message-missing-headers.txt
---
Unseen message, all headers were missing as i describe the problem earlier.

Can't reproduce this either.

You need to trace the code locally and determine *why/where* the 
header data is becoming invalid on your system.

I noticed that also Bacis view is, partially, affected by this. When 
opening _unred_ message, no subject is displayed.

I also tried to completely remove my 'prefs.local.php' so it's not 
related to my configuration.

Any suggestions how? I'm able to reproduce this on two separated 
servers (but they have almost the same SW). I tried Firefox 18 and 
Chrome 24. Will it help if i create you an account so you can see it 
by yourself?

You need to debug locally then.

Do the following:
  - login into dynamic view
  - click (at the right) Other - Hide preview
  - send yourself a new email
  - double click on new email
See attachment. Everything is showing ok after reload or when 
displaying already read message. Always reproduceable for me.

Can't reproduce.

When using dynamic view with _disabled_ preview of message, try to 
open any _new_ and _unread_ message (double click on it). There will 
be no headers displayed (no subject, no sender etc.).