Mercury supports any charset in messages, but not in IMAP SEARCH queries. In this case the query is for all messages (in the given range 1 - 64) that do not have the /deleted flag set. As there is no text part to match here I'm not sure why a CHARSET was specified at all. CHARSET is not a required part of a query according to RFC 3501, but the server is required to return a NO response if queried with a non-supported charset. It's then up to the client to adapt to that, but in this case the client simply repeats the exact same query one more time (hoping that the server is going to change its mind?).

I would suggest that you try POP3 instead of IMAP to access the mailbox, or see if there is an email client update or some alternative email client available. 

/Rolf 

I am testing a Samsung Galaxy S II smartphone with our email setup.  The phone's email client connects successfully to the mail server; I can see the login in the logs.  I can send email successfully through the client.  However, the client cannot see any emails in my Inbox or any subfolder.  The following appears in the session log:

18:06:37.043: >> 105 SELECT "INBOX"<cr><lf><br>18:06:37.063: << * 64 EXISTS<cr><lf><br>18:06:37.063: << * 0 RECENT<cr><lf><br>18:06:37.063: << * FLAGS (\Deleted \Draft \Seen \Answered)<cr><lf><br>18:06:37.063: << * OK [UIDVALIDITY 1291031822] UID Validity<cr><lf><br>18:06:37.063: << * OK [UIDNEXT 22207] Predicted next UID<cr><lf><br>18:06:37.063: << * OK [PERMANENTFLAGS (\Deleted \Draft \Seen \Answered)] Settable message flags<cr><lf><br>18:06:37.063: << 105 OK [READ-WRITE] SELECT completed.<cr><lf><br>18:06:37.073: >> 106 UID SEARCH CHARSET UTF-8 1:64 NOT DELETED<cr><lf><br>18:06:37.073: << 106 NO [BADCHARSET] Character set not supported.<cr><lf><br>18:06:37.083: >> 107 UID SEARCH CHARSET UTF-8 1:64 NOT DELETED<cr><lf><br>18:06:37.083: << 107 NO [BADCHARSET] Character set not supported.<cr><lf>

The Inbox is apparently failing to load because Mercury does not support UTF-8?  Am I reading that right?