99682 - trouble retrieving large attachments from IMAP server (GroupWise)

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[Adam Ambrose]

At my company, we have a GroupWise 5.2 email server running an IMAP front-end. 
 I am accessing my mail using Mozilla using this IMAP interface.

When I attempt to read an email containing an attachment that is around 1 MB or
more in size, Mozilla's progress meter runs & runs, but the email and its
attachment are never displayed.  In addition, I can no longer interact with this
folder in the email program - selecting other emails will cause the summary
highlight to move, but will not bring them up, no matter if they have large
attachments or not.  I can access local folders, but I can no longer interact
with my INBOX.

Note that I've found a work-around:  as long as I do not cause the email with
the large attachment to be displayed, I can move it to a local folder, which
then allows me access to the large attachment(s).  For instance, if I select the
email prior to the one with the large attachment, then Shift-Click or Ctrl-Click
on the attachment email, I can move both to a local folder.  Of course, I then
may need to move that initial email back!

Comment 1

[Karen Huang]

GroupWise 5.2 email server....IMAP interop bug?
Can you attach a IMAP log here? So we can know what kind of the IMAP server are 
you running?

Setup as following for generate an IMAP log:
-----------------------------------------------------------
For C Shell:
Add a line to  ~/.cshrc file of the csh shell as following: 
Set NSPR_LOG_MODULES IMAP:5 
Set NSPR_LOG_FILE /u/[unix userlogin]/tmp/[filename] 
(filename can be defined by you) 
                              
Add a line to  ~/.bashrc file of the csh shell as following: 
NSPR_LOG_MODULES="IMAP:5" 
NSPR_LOG_FILE="/u/[unix userlogin]/tmp/[filename] 
export NSPR_LOG_MODULES 
export NSPR_LOG_FILE 
(filename can be defined by you) 

Please Note: /u/[unix userlogin] is just Netscape setup UNIX environment for 
each user. 
It could be /home/[unix userlogin] or  /[unix userlogin] depend on how your 
users environment setup. 
------------------------------------------------------------------------------

Comment 2

[Adam Ambrose]

Attachment: Generated IMAP log, following [e-mail]'s directions. Edited out the large attachments.

Comment 3

[Keyser Sose]

Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.

Comment 4

[Christopher Hoess (gone)]

reopening.

Comment 5

[Daniel Kasak]

Attachment: IMAP log leading up to Mozilla hanging / crashing

I also am having problems with Mozilla accessing my IMAP server.
Mine is whatever came with Slackware 8.0 (sorry I have tried to find out what
it is, but can't. It's just called imapd... It's an MBOX imap server.
The size of attachments doesn't seem to be the problem. It's the NUMBER of
attachments that causes the bug.
Also, under Netscape, the same bug exists, and Netscape returns the error "The
IMAP server responded: excessively complex command" or something like that.
After the attachment is clicked on, Mozilla Mail locks until you exit Mozilla,
at which point it crashes.
A workaround is to turn off the preview window and drag the message out of the
IMAP folder into a local folder.

Comment 6

[(not reading, please use [e-mail] instead)]

over to david

Comment 7

[David :Bienvenu]

yes, it's the number of attachments that's causing the problem. 

One workaround is to add the following pref to your prefs.js

user_pref("mail.server.server1.mime_parts_on_demand, false);

where "server1" is replaced with the name of your imap server in prefs.js.

It seems like we should just punt on fetching the body structure if we think
it's too complicated. But if it were that easy, I'm sure 4.x would have done that.

Comment 8

[David :Bienvenu]

d'uh, this is a problem with a really large body structure response coming back,
so we don't know in advance how big it will be. I wonder if it would be possible
for me to either get the test message, or access to the server.

Comment 9

[Jesse Houwing]

I'm seeing the same with the WorkgroupMail 7.5.1 (Enterprise International) Mail
server.

This happens only if a message has attachments with content-disposition:
attachment added to them. It has nothing to fdo with the size of the attachment
or anything. A simple java class file of less than 1 KB will cause the same
problem as a word document of 900Kb. Messages with inline attachments will show
up fine.

As I'm seeing this with Mozilla Thunderbird 0.3 (20031013)/win32 I've set the OS
to all. I can provide a IMAP log, if somone can explain how I make such a thing
in windows with Thunderbird. You can test for yourself by downloading the trial
version of this server at the following address:
http://www.workgroupmail.com/download.asp

View-source and copying the message to a different folder still allow access to
the attachments as mentioned before. Also the mime_parts_on_demand setting
by-pass the issue altogether.

Comment 10

[David :Bienvenu]

Here are instructions for generating an imap protocol log:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Can you try with a 1.7 build? I did fix a problem in the parsing of some body
structure responses that might be responsible for some of the problems reported.

Comment 11

[Peter 'vt100' Schwindt]

Log not attached (too large) - but working as designed for an about 3MB attachment

see http://marwin.ba-loerrach.de/~schwindt/imap-log.zip for complete log

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040119

GroupWise 6.0

Comment 12

[David :Bienvenu]

So, it's working for Peter. Can anyone who it's not working for try generating a
log?

Comment 13

[Peter 'vt100' Schwindt]

--> WFM since no one answered for about 3 months.

please reopen, if the problem still exists