Yes it is an IMAP issue.

Thunderbird is downloading the raw source of EVERY message.  Not super 
efficient, but that's their design choice.  And one they can make when 
the client computer has GBs of memory, TBs of drive space, exclusive 
use of all CPU cores on the local machine, and the ability to download 
(and parse) the mail messages in the background.

Horde has none of those luxuries.  As such, we need to use IMAP 
summary FETCH commands - like ENVELOPE - for performance reasons.   
Which is also a perfectly valid choice.  And the *IMAP server* is 
responsible for parsing addresses in this scenario, as I mentioned 
before.

Example from Dovecot 2.2 - the From address for this message is the 
invalid string "Test : Foo <foo@example.com>":

S: * 181 FETCH (UID 189 FLAGS (\Seen) RFC822.SIZE 492 ENVELOPE ("Sat, 
26 Jul 2008 21:10:00 -0500 (CDT)" "Test e-mail 1" ((NIL NIL "Test" 
NIL)(NIL NIL "MISSING_MAILBOX" "MISSING_DOMAIN")(NIL NIL NIL NIL)) 
((NIL NIL "Test" NIL)(NIL NIL "MISSING_MAILBOX" "MISSING_DOMAIN")(NIL 
NIL NIL NIL)) ((NIL NIL "Test" NIL)(NIL NIL "MISSING_MAILBOX" 
"MISSING_DOMAIN")(NIL NIL NIL NIL)) ((NIL NIL "foo" "example.com")) 
NIL NIL NIL "<abcd1234efgh5678@test1.example.com>") BODY[HEADER.FIELDS 
(IMPORTANCE LIST-POST X-PRIORITY CONTENT-TYPE)] {28}
S: [LITERAL DATA: 28 bytes]
S: )

Sure enough, Dovecot is choking on that message.

As even you admit, that e-mail address is invalid. We need to make 
sure these kind of addresses don't cause a DoS or other crash.  But we 
shouldn't go out of our way to try to parse these broken e-mails.   
(That's not just my conclusion - Dovecot works under the same 
conclusion and it is used on more than half of the mail servers in the 
world).

Not to mention that there are potential privacy/security issues if you 
start to try to "guess" or "repair" broken e-mail messages.

Some parsing is done by IMAP server, I agree. But this does not matter 
here. I used Thunderbird to view this email and it showed sender's 
name and address correctly. I also see it in email source, so this is 
not an IMAP server issue. This header was sent incorrectly by email's 
author, and IMAP did not modify it in any way. I would be surprised if 
it did so.

IMP uses Horde/Imap_Client Library to connect to server using IMAP, so 
most probably bug is somewhere in this library. It might be also in 
code which uses this lib to get and display selected headers, but this 
is less likely. Please look on this again.

Addresses are parsed by the IMAP server, not IMP.

I received few emails with following header:

From: :: company <contact@company.com>

In such case IMP does not display sender at all. I googled a bit about 
this and found that such header is invalid per RFC 2822. Please make 
your software less restrictive and accept such headers too.