imap accounts on myrealbox.com assert when loading message (you can get free imap accounts on myrealbox.com) I'm not sure if it is a IMAP4rev1 server or not. a related issue is that we don't seem to fetch the message by parts like we do with other servers on message display. if the message has an attachment, we go get it on message display. NTDLL! 77f9f9df() nsDebug::Assertion(const char * 0x0409143c, const char * 0x04091430, const char * 0x040913f4, int 158) line 290 + 13 bytes nsIMAPGenericParser::SetSyntaxError(int 1) line 158 + 35 bytes nsIMAPGenericParser::CreateString() line 412 nsIMAPGenericParser::CreateNilString() line 389 nsIMAPBodypartMultipart::ParseIntoObjects() line 1344 + 11 bytes nsIMAPBodypartMultipart::nsIMAPBodypartMultipart(nsIMAPBodyShell * 0x04d7a230, char * 0x04d7c2d0, const char * 0x04d7c160, nsIMAPBodypart * 0x04d7c230) line 1195 + 8 bytes nsIMAPBodypart::CreatePart(nsIMAPBodyShell * 0x04d7a230, char * 0x04d7c2d0, const char * 0x04d7c160, nsIMAPBodypart * 0x04d7c230) line 363 + 43 bytes nsIMAPBodypartMultipart::ParseIntoObjects() line 1281 + 24 bytes nsIMAPBodypartMultipart::nsIMAPBodypartMultipart(nsIMAPBodyShell * 0x04d7a230, char * 0x04d7c2d0, const char * 0x04d7c320, nsIMAPBodypart * 0x04d7a140) line 1195 + 8 bytes nsIMAPBodypart::CreatePart(nsIMAPBodyShell * 0x04d7a230, char * 0x04d7c2d0, const char * 0x04d7c320, nsIMAPBodypart * 0x04d7a140) line 363 + 43 bytes nsIMAPBodypartMessage::ParseIntoObjects() line 1070 + 24 bytes nsIMAPBodypartMessage::nsIMAPBodypartMessage(nsIMAPBodyShell * 0x04d7a230, char * 0x00000000, const char * 0x04d7c8f0, nsIMAPBodypart * 0x00000000, int 1) line 1002 + 8 bytes nsIMAPBodyShell::nsIMAPBodyShell(nsImapProtocol * 0x03b85690, const char * 0x04d7a2b0, unsigned int 752945, const char * 0x046da0e0) line 107 + 41 bytes nsImapServerResponseParser::bodystructure_data() line 2350 + 59 bytes nsImapServerResponseParser::msg_fetch() line 1192 nsImapServerResponseParser::numeric_mailbox_data() line 947 nsImapServerResponseParser::response_data() line 689 nsImapServerResponseParser::ParseIMAPServerResponse(const char * 0x04cb9e30, int 0) line 212 nsImapProtocol::ParseIMAPandCheckForNewMail(const char * 0x04cb9e30, int 0) line 1216 nsImapProtocol::Bodystructure(const char * 0x04cbe090, int 1) line 2399 nsImapProtocol::ProcessSelectedStateURL() line 1878 nsImapProtocol::ProcessCurrentURL() line 1129 nsImapProtocol::ImapThreadMainLoop() line 978 nsImapProtocol::Run(nsImapProtocol * const 0x03b85694) line 744 nsThread::Main(void * 0x05398400) line 105 + 26 bytes _PR_NativeRunThread(void * 0x053a5040) line 413 + 13 bytes _threadstartex(void * 0x053a09b0) line 212 + 13 bytes KERNEL32! 77e92ca8()

my guess is that this server is generating invalid protocol. A protocol log would probably tell us.

Cavin, did you see the assert that Seth saw? My guess is not, in which case the log doesn't exhibit the problem Seth saw.

I think david is right about the protocol error from the server. Here is the response for the "8 UID fetch 752944 (BODYSTRUCTURE)" cmd from the server: * 2 FETCH (UID 752944 BODYSTRUCTURE ( ("text" "html" ("CHARSET" "us-ascii") NIL NIL "7bit" 170 12) ("application" "octet-stream" ("NAME" "hyatt.doc") NIL NIL "base64" 39294) "mixed" ) ) The second attachment (ie, "application" "octet-stream" ...) is missing a parameter for the number of lines in the attachment. It should have been something like: ("application" "octet-stream" ("NAME" "hyatt.doc") NIL NIL "base64" 39294 59) That's why the assertion was produced. I'll run the debugger to confirm the cause later.

david, yes, I did see the assertion.

cool, I thought we logged syntax errors in the protocol log - did I just miss it? Your analysis seems right on. We've had problems with myrealbox.com before - I can't remember if we ever contacted someone there before.

never mind, I see the syntax error in the log. Surprisingly, we just continue on. We used to drop the connection and bail!

For the body part fetching issue here is what I found from reading msgs with samll and large attachments. For msgs with small attachments (< 15 KB), we issue the following cmds to server: 8 UID fetch 752944 (BODYSTRUCTURE) 9 UID fetch 752944 (XSENDER UID RFC822.SIZE BODY[]<0.10240>) The second fetch cmd will load in the entire msg to the client. For msgs with large attachments (> 1 MB), we issue the following cmds to server: 14 UID fetch 455 (BODYSTRUCTURE) 15 UID fetch 455 (BODY[HEADER] BODY[1.MIME] BODY[2.MIME]) Here we only fetch the structure of the body and not the body conent itself. Again, I'm not in debugger to investigate the issue. david, any comments about the above?

right, for a small message, we fetch the whole thing. That's by design. That's what you're seeing, right?

Right.

So, is there anything we have to do here? If not then we should close it.

Resolving as duplicate. If this is not a duplicate, reopen. *** This bug has been marked as a duplicate of 57102 ***