595798 - Access to large message (>29.6kb) causes reset of imap connection

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: IMAP, defect)

Description

[Roman Fiedler]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre SeaMonkey/2.1b1pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre SeaMonkey/2.1b1pre

When clicking on imap message with more than 29.6kb size (size from message list), seamonkey will remove the "unread" tagging in the message list and show a blank message. The error causes a drop of the open imap tcp connection.

When clicking on another message, status bar displays "connecting to [servername] ... Sending login info ...", seamonkey sets the large message to "unread" again and displays the other message as normal. Imap tcp connection stays open.

I observed, that in nighly build ~20100908, the attribute

mail.server.default.limit_offline_message_size

changed from type "boolean" to "string" and now with 20100912 back to "boolean" again. Perhaps there was some mistake in that code.

Perhaps the change is related to fetching messages from an MS exchange server, older versions failed to report correct message sizes.

The "mail.server.default.fetch_by_chunks" = "false" workaround is still in place, but might not be working any more. (see https://bugzilla.mozilla.org/show_bug.cgi?id=92111)

Reproducible: Always

Steps to Reproduce:
1. Click on large message
2. Wait for white message display
3. Check that tcp connection is dead
Actual Results:  
Connection teardown

Expected Results:  
Display of message

Comment 1

[Roman Fiedler]

Found one strange additional condition to trigger this result: The message has to be read first with Outlook (via internal mapi protocol) and then via imap.

So it is rather likely, that it is  independent of #92111 and might also be present before 2010-09-08 nightly build, since I am not 100% sure that I have used seamonkey in exactly that settings.

So I guess, it is not worth to invest huge amount of time, since it is likely, that no one else is affected by this bug and the workaround is to use just one of the two clients for a given mailbox.

Comment 2

[Wayne Mery (:wsmwk)]

Roman, do you still see this problem when using a recent version?

Comment 3

[Joshua Cranmer [:jcranmer]]

RESOLVED INCOMPLETE due to lack of response to the previous comment. If you feel this change was made in error, please respond to this bug with your reasons why.