That message is completely broken - the To field is a UTF-8 string (as 
opposed to ASCII MIME encoded string).  I think the issue is that IMAP 
servers are inconsistent in how they return this data.  I'm using 
Dovecot 2 and it returns the To string in UTF-8, but there is no 
requirement (or expectation) to do so.  The string could just as 
easily be ISO-8859-1, for example.

So your solution is probably the best - sanity checking is about all 
we can really do in this case.

Changes have been made in Git for this ticket:

Bug #9691: Sanity checking for completely broken address fields

  1 files changed, 1 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/eadf8580b6bad126fa5205314f52030e36cecfeb

Hi Michael.

First of all, sorry, because once again i made a mistake..somehow the 
patch i committed has way to many code in it..I only wanted to change 
the /imp/js/dimpcore.js.
Now, i've debugged the code again, and found that the actual problem 
comes from PHP, because IMP_Views_ShowMessage::showMessage around the 
lines you told me is storing non valid UTF-8 string on the to field.

When it goes to json_encode, it blows up, and to.inner becomes null

Any clue where i might look deeper?

Nope - I get the same results as before.

So what is the contents of o in dimpcore.js (in buildAddressLinks)?   
It can't be empty or else the code in IMP_Views_ShowMessage would have 
created an object with the 'raw' property (see line 157-161).

Sorry Michael, actually the message i sent you was opening has you 
told.. I attached a new message, and this one does has o.inner with a 
null value.
I also send you the IMAP log of the message attached


(1300895544,7698) S: * 13 FETCH (UID 47 ENVELOPE ("Tue, 15 Mar 2011 
19:50:06 +0100" "Fwd: FW: A cabra do Pobre e a cabra do Rico" 
(("carlos santos" NIL "sender" "example.com")) (("carlos santos" NIL 
"sender" "example.com")) (("carlos santos" NIL "sender" 
"example.com")) ((NIL NIL {28}
(1300895544,7705) S: [LITERAL DATA - 28 bytes]
(1300895544,7705) S:  NIL)(NIL NIL NIL NIL)) NIL NIL NIL 
"<4D7FB4DE.4060207@gmail.com>") BODY[HEADER] {2945}
(1300895544,7708) S: [LITERAL DATA - 2945 bytes]
(1300895544,7709) S: )

That shouldn't be needed - whatever information we have in the address 
should be in inner.  That's what happens for me (inner for me contains 
""Destinatários não divulgados"@").

I'd like to make sure this is not a Horde parsing error (it sort of 
sounds like a parse problem on the IMAP server).  Is there any way you 
can attach the IMAP debug output for the envelope call for this message?

Sorry Michael, its seems that it was some sort of cache :-/

Still, i couldn't open the message because of a javascript error 
(attached a patch to fix that). Although is trange that you could open 
the message without that javascript fix (yes, i cleared all cache now 
:-D )

Also:

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 see exactly the opposite - without the recent changes, the message 
does not display correctly.  I can verify I see the message just fine. 
  And sure enough, the IMAP server is returning a literal for the To 
data:

(1300761514.1162) S: * 8 FETCH (UID 17017 FLAGS (\Seen) RFC822.SIZE 
1125 ENVELOPE ("Mon, 21 Mar 2011 19:58:48 +0000" "jhgh j" ((NIL NIL 
"=?ISO-8859-1?Q?Gon=E7alo_Queir=F3s?=" "MISSING_DOMAIN")) ((NIL NIL 
"=?ISO-8859-1?Q?Gon=E7alo_Queir=F3s?=" "MISSING_DOMAIN")) ((NIL NIL 
"=?ISO-8859-1?Q?Gon=E7alo_Queir=F3s?=" "MISSING_DOMAIN")) ((NIL NIL {30}
(1300761514.1166) S: [LITERAL DATA - 30 bytes]
(1300761514.1166) S:  NIL)(NIL NIL NIL NIL)) NIL NIL NIL 
"<4D87ADF8.8090500@example.com>") BODY[HEADER.FIELDS (IMPORTANCE 
LIST-POST X-PRIORITY CONTENT-TYPE)] {40}
(1300761514.1168) S: [LITERAL DATA - 40 bytes]
(1300761514.1168) S: )

Make sure your cache has been cleared.

If you send a message from Thunderbird Pt with Bcc, it won't open on Imp.

I attached an example message. I think the problem is because of the 
"To: Destinatários não divulgados:;" part..

Before the commit 8eab8ddaa4dee001bc03f8c06c780f5dfdc94dcf this 
message could be opened fine.