Closed Bug 149771 Opened 22 years ago Closed 6 years ago

Multipart/mixed MIME messages may not display body (IMAP / Exchange server)

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: derek.millar, Unassigned)

References

Details

(Keywords: testcase, Whiteboard: [fixed in v3.1?])

Attachments

(4 files)

edited source of email message that exhibits the bug.
1.27 KB, text/plain
Details
Examples of correctly and incorrectly displayed message source
1.58 KB, text/plain
Details
Saved eml message with empty message body in "plain text" view
3.06 KB, text/plain
Details
IMAP log showing problem
102.05 KB, text/plain
Details 
Multipart/mixed format MIME messages sometimes display as completely blank aside
from the headers, though they are readable with the "Message Source" command. 
If I forward a message which exhibits the problem to myself, the attachments are
visible.  In all cases I know of, affected messages were originally sent from
Outlook and retrieved via IMAP from an Exchange server.  The problem does not
occur for all messages, and I haven't been able to find anything that
distinguishes the messages which will display from the ones which won't.

Saving an affected message as a "Mail Files" file allows it to be opened
properly by Outlook Express.  Saving the file as a text file and viewing it in a
text editor only gives me the message headers.

Relevant parts of the original message (which may not display) look like:

> Content-Type: multipart/mixed;
>
boundary="----_=_NextPart_000_01C202AE.85BA2850"
> 
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_000_01C202AE.85BA2850
> Content-Type: text/plain;
>
charset="iso-8859-1"

Note that the leading whitespace for wrapped Content-Type lines is a tab character.

Relevant parts of the forwarded message (which does display) look like:

> Content-Type: multipart/mixed;
>  boundary="------------080104060409070805050203"
>
> This is a multi-part message in MIME format.
> --------------080104060409070805050203
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit

Aside from those bits (well, and the "Received:" lines and such), the original
and forwarded messages look identical.  I've prepended "> " to each quoted line
in this description to distinguish the quotes from the rest of the text.  I will
try to provide an example of a message which exhibits the problem as soon as I
can find one which does not contain confidential information.

I'm currently seeing this error on the 1.0 release (build 2002053012), but I
have also seen it on earlier versions going back to 0.9.9.  Have not tested on
other platforms.

May be related to bug 92111.
QA Contact: olgam → trix
I get the same behavior on Linux (Red Hat 7.3).
The message is received from an Exchange server.

Oddly enough, there are multipart/mixed messages that I CAN read.
I'm unsure but may be it is related with the location of the Content type header.

The message I can't read has the following format:

> Message-ID: <35F87783B600D411A1430060943F469A02768674@EXCHANGE>
> From: <snippety>
> To: <snippety>
> Subject: <snippety>
> Date: Mon, 1 Jul 2002 09:19:46 +0200
> Return-Receipt-To: <snippety>
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
> 	boundary="----_=_NextPart_000_01C220CF.AE1D90CC"
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.


The message that I can read has the following:

> Content-Type: multipart/mixed;
> 	boundary="----=_NextPart_000_0001_01C21EB6.D50A2C10"
> Date: Fri, 28 Jun 2002 15:16:52 +0200
> From: <snippety>
> Message-ID: <000001c21ea6$11815c10$b47ba8c0@PC>
> MIME-Version: 1.0
> Subject: <snippety>
> To: <snippety>
>
> This is a multi-part message in MIME format.


Several users at our site experience this using Mozilla 1.2.1 on Solaris.
I believe this bug is the same as #190905.  The offending line of header in the
previous example:

> 	boundary="----=_NextPart_000_0001_01C21EB6.D50A2C10"

Note that the boundary= section is in double quotes.  As a test, if you see this
on a message, put it into a mail folder and edit the raw message source to
remove the double quotes.  The problem will go away.

Also noticed in Mozilla 1.1 (Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1)
Gecko/20020827) on SunOS 5.8.

I did think that it was triggered by CRLF+tab before the boundary attribute; but
I still couldn't tickle the bug. I do see it in the wild now and then...

Fwiw, RFC 2046 does permit double-quotes around the boundary value (and if
unsafe characters are used, the quotes are needed). Also, RFC 822 does allow the
tab-continuation.


Is this bug still an issue with current builds (1.3 or 1.4)?
If so, does anyone have a sample message that exhibits the problem that they 
could attach to this bug?
Following up on that attachment, it's blank in 1.3 as well as earlier releases.
 Works fine if I forward the message to myself, as described earlier in the bug.
 I had to edit the message to remove confidential information; I hope that
doesn't affect the behavior.

After I added an initial "From" line to that sample message, it was recognized 
as an email, which displayed properly in Moz 1.3 -- not blank.

What mail program is generating the bad messages?
The sample message was created by copying and pasting from Mozilla's "View
Source" window, which never seems to display a "From " line (with no colon after
the From).  As I stated in the original bug report, problem messages in my
experience are all generated by MS Outlook and served to Mozilla over IMAP from
MS Exchange.  The problem does not appear with all messages from those programs
and I haven't figured out a way to reliably cause it to occur, though it's
consistent if it appears for a given message.

At least one problem message was probably sent from the Outlook Web Access
program rather than the Windows client.

I have experienced the same behavior on XP, Solaris, and Linux, in every version
of Mozilla since 1.1, up through 1.4, and continue to experience the same issue
with Thunderbird 0.1 on XP and Mac OS X.

As the original reporter notes, the attachment only becomes visible once you
click the forward button.
got the same problem here.
this is a pain.
does somebody know how to debug this ?
I mean something like a debug flag to set to produce debug log of the mime
parser in a file. (I can test on linux or NT)
might be of interest for this bug :
http://mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
please somebody confirm this bug and change it's status to new
I think this is the same problem as bug 215313 which is for thunderbird
Araman,

I'm pretty sure that this bug (at least the version I saw) comes from odd or
malformed MIME headers and structures in the message.  This is set up by the
email client, so the first step to debugging it is determining what client sends
the annoying mail.  When I saw it, it appeared to be a particular version of
Outlook Express.

Debugging then is just watching the parse on the headers.

Part of the problem with this bug is that clients that cause the problem appear
to be pretty rare.  But since people tend to communicate with the same people
over time, if one of your friends has a bad client, you see the problem all the
time.

So what client is generating your bad MIME?
mail was sent via outlook.
this is a weird problem
I restarted my pc today and trying to debug the problem, it has disappeared.
I can now read the same mail correctly with mozilla (I didn't change anything)
I tried to resend similar mail from outlook to myself (this was a mail with text
and a doc attached) and each time I can read it.
Using Moz 1.5. A few days ago rcvd a multipart-MIME email (text + xls) from
Exchange IMAP and could read the body fine. Now today I cannot for some reason.
Restarting win2k did not fix it. Then I forwarded to myself (as others
suggested) and I can read it and save the attachment in the forwarded message.
Also, after doing the forward I can also now read the original message. 
Something definitely wrong here!
I'll add my observations to the growing list of strange behaviors...

My experiences suggest that the problem is not so much a consequence of faulty
formatting by the sending client (Eudora, etc), but with interactions between
Mozilla and an MSE IMAP server during the storage, moving, and retrieval of
messages.

I'm running

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316
under Mac OS X 10.3.3 with an IMAP server hosted by Microsoft Exchange 2000 on
Windows 2000 Server. 

In an effort to diagnose the problem, I've used a test message that is a bit of
text, plus two PDF attachments.  Sent from either Mozilla or OS X Mail, the
message (see attachment for the source) is correctly displayed by Mozilla upon
arrival in my Inbox.

However, when I move this message from the Inbox to another folder on the IMAP
server, the message is displayed as empty.  The header shows an appropriately
sized file, but neither the body nor the attachments are shown. After the move,
the source of the message (see attachment) looks very much like that in the
original bug post, only with a nested multipart/alternative apparently added by
the MSE Server to provide HTML formatting.

Interestingly, if I perform the send and folder move within another client
(I've tried OS X Mail and MS Entourage), the problem does not occur.  But it's
not even that simple.  The end result appears to depend on the Send Client and
Folder Move Client pairing.  My observations...

Send Mozilla, Folder Move Mozilla	-> Fail
Send Mozilla, Folder Move Mail		-> Fail
Send Mail, Folder Move Mozilla		-> Fail
Send Mail, Folder Move Mail		-> Pass

Note that in all cases above, Pass or Fail is based on viewing in Mozilla, not
the Move client. 

Strangely, the source resulting from a send and move in OS X Mail, while
successfully displayed in Mozilla, appears "structurally" identical to the
source resulting from a send and move in Mozilla.  As suggested in the original
post, inspection of the source offers (to my newbie eyes, anyway) few clues.

I too note that the attachments "reappear" if I initiate a forward of the
message. Furthermore, the message is displayed correctly if I move it from the
IMAP folder to a local folder on my machine.  A diff of the message source
before and after this latter move shows only the addition of the following two
lines:

> X-Mozilla-Status: 1001
> X-Mozilla-Status2: 10000000

To do this diff, however, I had to "unmac" the message source, removing the Mac
line break characters.	So it's perhaps possible that subtle differences such
as the tabbed whitespace mentioned in the initial post would be lost prior to
the diff?  Could things of this nature could be important as suggested by (the
possibly related) bug 87653?

Not sure what all this means, but I do have one half-baked thought... Is it
possible that the problem isn't due to a difference in the source that makes a
message "unrenderable", but rather that Mozilla (for some other reason) isn't
even _trying_ to display the message body and attachments?
I have the same problem using Mozilla 1.6 under Solaris, what I've found is that
most of the messages (maybe all) that are experiencing this problem are all
originally created as RTF formatted messages on Outlook. When accessing an RTF
message using IMAP to Exchange, Exchange will autoconvert the message to either
HTML or Plain text. Our Exchange server is setup to convert to plain text and
all the messages I see this problem on (I think, at least I have not seen this
problem on any pure HTML messages) are converted to plain text and the original
RTF message contained one or more attachments.

I have also seen that moving a message from a subfolder back to the INBOX seems
to cure this problem. This is strange to me, will the message source delivered
to mozilla over IMAP actually be different when retrieved in the INBOX compared
to a subfolder ? I would assume that the message source is identical even though
it's retrieved from a subfolder. Could this bug exist somewhere in the IMAP
layer where the actual IMAP url causes trouble ? Just a thought, don't know how
to debug this any further. I have been running with debugging turned on and I
can see the whole message being retrieved in the IMAP logfile, but nothing is
diplayed...

I think this bug should be changed to status NEW.
I experimented some more with this problem, if I view the message source of a
message that won't display when fetched over IMAP from the exchange server and
append the message source to the INBOX of the Local Folders the message will
then display correctly. This seems to indicate that there isn't something wrong
with the message source at all, any thoughts on this ?
OK, there are enough well-described reports of this issue that I think it's 
worth confirming, even tho I can't see it myself.  Switching component, hoping 
I'm choosing the right one.
Assignee: sspitzer → bienvenu
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → Networking: IMAP
Ever confirmed: true
QA Contact: stephend → grylchan
Summary: Multipart/mixed MIME messages may not display body → Multipart/mixed MIME messages may not display body (IMAP / Exchange server)
I've had some more interesting experiences with this bug.

First, switching from Mozilla to 

Thunderbird version 0.6 (20040502) under Mac OS X 10.3.3

did not change the behavior, as far as I can tell.

However, this week our IT staff decided to ditch our Exchange server.  We were
running an IMAP server using

Microsoft Exchange 2000 on Windows 2000 Server.

but now we're using

CommuniGate Pro 4.2b3 06-May-04 

This _did_ change the behavior.  All of the test messages I'd sent myself that
previously exhibited the "invisible body and attachments" problem now properly
display a body and attachments.  The very same message shows no body or
attachments when served by the Exchange server but does show a body and
attachments when served by CommuniGate.  Even stranger, a diff of the source
served by the two servers shows no difference whatsoever.

So I'm sticking with the speculation that this is not an issue of properly
formatted message source.  I think it's something more subtle... as if
Thunderbird is confused by the manner in which the Exchange server serves
multi-part messages.
(In reply to comment #19)
> OK, there are enough well-described reports of this issue that I think it's 
> worth confirming, even tho I can't see it myself.  Switching component, hoping 
> I'm choosing the right one.

I also experience this bug with mozilla 1.7rc3. I saved the messages (from
ms-exchange server through IMAP) as .eml type files and ran a diff between
multipart messages that I could and could not open from the same person running
ms-outlook. The difference I found was, a space after the Date field in the header!

Kind regards,

All,

I also experience this bug with mozilla 1.7rc3 on windows 2000 (and also earlier
versions). I saved the messages (from ms-exchange server through IMAP) as .eml
type files and ran a diff between multipart messages that I could and could not
open from the same person running ms-outlook. The only real difference I found
was, *a space character after the Date field in the header*!

Mozilla mail cannot read this message with a space after Date: field:

Received: <snip>
Message-ID: <snip>
From: <snip>
To: <snip>
Subject: <snip>
Date: Fri, 7 May 2004 09:06:48 +0200 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C4340A.EA577DFA"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C4340A.EA577DFA
Content-Type: text/plain;
	charset="iso-8859-1"
...

And it can read this:

Received: <snip>
Message-ID: <snip>
From: <snip>
To: <snip>
Cc: <snip>
Subject: <snip>
Date: Fri, 26 Mar 2004 13:43:32 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C427A7.7383A7EA"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C427A7.7383A7EA
Content-Type: text/plain;
	charset="iso-8859-1"

Kind regards,
              Dennis
Flags: blocking1.8a2?
Flags: blocking1.7?
Flags: blocking1.7? → blocking1.7-
Flags: blocking1.8a2? → blocking1.8a2-
I have confirmed this bug in Linux Mozilla 1.6 and Windows Mozilla 1.6 and
1.7.1.  It seems to be some sort of parsing issue based on the workaround below.

************
Workaround is to use "View->Message Body As->(Simple or Original) HTML"
************

Due to spam, of course, I always have "View->Message Body As->Plain Text" on.

By the way, this was not a problem with Exchange 5.5, only with Exchange 2000
(and probably higher).

I attached a saved (and slightly doctored) eml message to chew on...
Attached file IMAP log showing problem — 
A "me too," with some more details.  I sent myself a couple emails using
outlook.  In each case, I attached a binary file and put a single "x" into the
text body.  The only difference was in the sizes of the binary files (16K and
32K).  The mails appear in my inbox, and I can see the attachment.  I then move
the files to a folder test, and the attachment can be seen on the smaller
message, but I see nothing (body or attachment) on the second message.
I've attached an IMAP log, which was produced by first removing test.msf, then
running mozilla (1.7.2), and selecting the two messages in succession.
Note that the RFC822.SIZE is wrong for both: if I save the messages directly
from mozilla, I get sizes of 22980 and 45111 respectively.
Thus, I suspect that "enable fast message retrieval" is set on the exchange
server, resulting in the bogus sizes.  I'm guessing that mozilla relies on this
information somehow?  I've asked our administrator to change that setting, but
I can't guarantee that she will: anyone out there with this bug that can do the
test more directly?
re jsberg@bnl.gov's log, it looks to me like we're fetching the body here:

12 UID fetch 18 (BODY[1])
 * 2 FETCH (BODY[1] {5}
x

UID 18)

so I'm not sure why we wouldn't display it...

One mistake in my report, the message sizes reported by the server are exactly
correct.  I forgot to change the end-of-line convention in the saved files to be
cr-lf.  So the problem is unlikely to be the "enable fast message retrieval"
setting.
Found something in the logs: first, note that the bodystructure is only
requested for the second message (UID 18).  Second, note that the boundary
returned by BODYSTRUCTURE is different from the one given in BODY[HEADER].  For
cultural interest, the boundary value given by BODYSTRUCTURE matches the
boundary value of the copy sitting in the inbox.

So I suppose that mozilla doesn't do BODYSTRUCTURE unless the message is beyond
a certain size, and then freaks when what's in BODYSTRUCTURE doesn't match
what's in BODY[HEADER]?

right, we don't do a body structure unless the message is greater than certain
size (25k, maybe?). Re the boundary value freaking, empirically, that would seem
to be the case, but it's not obvious to me why or where that would be - maybe in
the mime parsing code...
OK, I think I see what's happening here.  in
mailnews/imap/src/nsIMAPBodyShell.cpp, in nsIMAPBodypart::GenerateBoundary, it
sends a fake boundary using the value returned by BODYSTRUCTURE.  However, in
mailnews/mime/src, this is checked in MimeMultipart_check_boundary against the
boundary member of the the MimeObject passed to that, which was set in
MimeMultipart_initialize to be the value that came with BODY[HEADER].  Since
they don't match, mozilla gets bamboozled.

I suppose the optimal solution is that when we're letting the server get the
MIME parts for us, we should avoid the fake boundary business and find another
way to tell the MIME parser that we're moving on to the next part.
Here's the workaround: in prefs.js, 

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

where server1 is the appropriate server.

Consider me satisfied.
I can no longer reproduce this problem after setting the above mentioned
preference, thanks !

It does slow things down though, would be great with a permanent fix...


yes, turning off mpod will fix your problem. However, it will make clicking on
messages with large non-inline attachments much slower.

Re the fake boundary problem, I didn't write the original code but I know it was
very difficult to get mpod working with mime. Remember we're just streaming data
to mime; we're not calling methods in mime. Mime doesn't really know it's
dealing with incomplete data, as I understand it.
Product: MailNews → Core
*** Bug 215313 has been marked as a duplicate of this bug. ***
I came across this bug (not exactly the same). When I tried to read a daily
digest of the web standard group mailing list (with almost 100 attachments most
of which are text/plain with some of them in text/html or
multipart/alternative), I was shown the list of attachments (part 1.2, part 1.3,
.... part 1.85). I could read a few messages(parts) at the top when I opened the
message for the first time (or I turned off and then turned on again 'View
Attachment inline') , but  the whole thing suddenly turned to the attachment
list after I scrolled further down to read more message parts. 

When I clicked on one of message parts (which is in 'Content-Type: text/plain;
charset=us-ascii'), I was prompted as to what to do with an 'ASC' file (the mime
type detection/mime handler is apparently broken, which should be a separate bug)
OS: Windows 2000 → All
Hardware: PC → All
I'm seeing this with 1.7.11, IMAP to Netscape Mail Server 4.16, on an email
containing a forwarded email with 3 excel files.  The odd thing is that I was
able to open the email, see the text portion, get the first attachment, but
after that, all parts of the email say that the attachment will be downloaded on
demand, including the text portion.  Clearing cache, setting to view->plain
text, disabling view inline, does not enable access to the last two attachments.
 View source and forwarding to myself both show an email that has the text "This
body part will be downloaded on demand.", and as the contents of the last two
attachments (see below):
------------8<---------------------

Date: Tue, 06 Sep 2005 09:03:23 -0700
From: [snipped]
Organization: AeroVironment, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Baffoni@aerovironment.com,
	  "[snipped]" <[snipped]@[snipped]>
Subject: [Fwd: Quotes for 181 and 1960]
Content-Type: multipart/mixed;
 boundary="------------060107060900080407090600"

--------------060107060900080407090600
X-Mozilla-IMAP-Part: 1
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This body part will be downloaded on demand.
--------------060107060900080407090600
Content-Type: message/rfc822;
 name="Quotes for 181 and 1960"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Quotes for 181 and 1960"

[snipped]
Date: Tue, 6 Sep 2005 08:56:12 -0700
From: [snipped]
Subject: Quotes for 181 and 1960
To: [snipped]
Mime-Version: 1.0
X-Mailer: GoldMine [5.00.402]
Content-Type: multipart/mixed; boundary="nqp=nb64=()p1KaLmIg2"
[snipped]

--nqp=nb64=()p1KaLmIg2
X-Mozilla-IMAP-Part: 2.1
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This body part will be downloaded on demand.
--nqp=nb64=()p1KaLmIg2
Content-Type: application/vnd.ms-excel; name="Quote Voice & Data Cable, 1960.xls"
Content-Disposition: attachment; filename="Quote Voice & Data Cable, 1960.xls"
Content-Transfer-Encoding: base64

[snipped base64 content]

--nqp=nb64=()p1KaLmIg2
X-Mozilla-IMAP-Part: 2.3
Content-Type: application/vnd.ms-excel; name="Quote Valcom Commercial Page
System.xls"
Content-Disposition: attachment; filename="Quote Valcom Commercial Page System.xls"
Content-Transfer-Encoding: base64

This body part will be downloaded on demand.
--nqp=nb64=()p1KaLmIg2
X-Mozilla-IMAP-Part: 2.4
Content-Type: application/vnd.ms-excel; name="Quote Voice & Data Cable, 181.xls"
Content-Disposition: attachment; filename="Quote Voice & Data Cable, 181.xls"
Content-Transfer-Encoding: base64

This body part will be downloaded on demand.
--nqp=nb64=()p1KaLmIg2--
--------------060107060900080407090600--
*** Bug 304952 has been marked as a duplicate of this bug. ***
The problem here seems to be a misunderstanding of the IMAP protocol.

For short messages, Thunderbird fetches the whole body, using the FETCH specifier "BODY[]".  For longer messages, Thunderbird first fetches the BODYSTRUCTURE, then fetches one or more of the parts of the message, depending on its analysis of the structure.  But it uses the IMAP FETCH specifier "BODY[n.MIME]" to fetch the part "n".  And this specifier, according to the IMAP protocol spec, only returns the *headers* for that part, not the whole part.  It should be sending either (most probably) "BODY[n]", to fetch the entire part including its headers, or "BODY[n.TEXT]" to fetch the part without its headers.  I haven't looked at the code to figure out which.

There are probably a few other bugs related to this misunderstanding.  I've verified this behavior with Tbird 1.5.0.10 on Mac OS X.
Here's another issue:

in /tmp/mozilla/mailnews/imap/src/nsImapProtocol.cpp, we find this code in nsImapProtocol::FetchMessage:

  case kMIMEPart:
    commandString.Append(" %s (BODY.PEEK[%s]");
    if (endByte > 0)
    {
      // if we are retrieving chunks
      char *byterangeString = PR_smprintf("<%ld.%ld>",startByte,endByte);
      if (byterangeString)
      {
        commandString.Append(byterangeString);
        PR_Free(byterangeString);
      }
    }
    commandString.Append(")");
    break;

Unfortunately, the line which uses "startByte" and "endByte" gets the protocol wrong.  The protocol uses "startByte" and "lengthInBytes", not "startByte" and "endByte".  So the correct line would be

      char *byterangeString = PR_smprintf("<%ld.%ld>",startByte,endByte - startByte + 1);

Looking further at the code, it seems like callers of FetchMessage are ignoring the documented (in nsImapProtocol.h) C++ protocol, and sending appropriate values to FetchMessage.  So I guess the correct fix would be to change the nsImapProtocol.h specification of FetchMessage to rename the "endBytes" parameter to "numberOfBytes".
I think my original diagnosis of a misunderstanding of the IMAP protocol is a bit simplistic.  The code in nsImapProtocol.cpp seems to be doing the right thing.  I think a higher level must be confusing kMIMEHeader and kMIMEPart.
I could be wrong, but this code has worked for about 8 years now w/o any complaints that we were issuing the wrong protocol or incorrect byte ranges. So either something has changed in the code, or your diagnoses are not quite right.
Clearly there are some problems, or this bug wouldn't exist.  I'm watching a server log, and seeing Thunderbird issue a BODYSTRUCTURE fetch, followed by just BODY[n.MIME] fetches (which is nonsensical on the face of it: there should be no need to fetch the headers if you have the BODYSTRUCTURE in-hand.  This may be required by the protocol transducer (nsIMAPBodyShell.cpp), but it's a red flag.).  The lowest level of Thunderbird code (nsImapProtocol.cpp) looks pretty good to me, so I'm guessing the issue is higher up in the abstraction layers.  I'll keep poking around.
For one thing, we need to know if you can display the parts inline - that's why we fetch the headers. If we can display all the parts inline, we fallback to fetching the whole message body. Otherwise, we fetch the bodies of the parts.
Blocks: 265739
Product: Core → MailNews Core
QA Contact: grylchan → networking.imap
Similar problem here in Win XP, first occured with Thunderbird 3.0b1 - a message with a 50k PDF attachment. But with a strange variant:
TB first shows the message text, but once I downloaded the attachment the msg text gets _replaced_ by this error msg:
"This body part will be downloaded on demand."

Now even with a different mail client and a webmailer the message text will not show up again - so it seems TB actually _destroyed_ it.
This is really ugly, IMO.
Bernd, actually, your experience is no different from mine.  TB actually did destroy the mail/attachment her, too.  Increasing importance to critical, because this bug induces data loss.  Unfortunately, I don't think we have a clear-cut test case, yet.  It only happened to me once so far during the many years I've used TB.
Severity: normal → critical
Is this fixed in 3.1 beta1 pre builds? We fixed some mime part bugs in those builds.
(In reply to comment #48)
> Is this fixed in 3.1 beta1 pre builds? We fixed some mime part bugs in those
> builds.

Dear bug participant's - your response to the above question will be helpful, because reporter's address is dead - "Invalid recipient".

v3.1 Beta 2 is available at http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.1b2-candidates/build2/
Keywords: testcase
Whiteboard: [fixed in v3.1?]
well, it's going to be almost impossible to say this is indeed fixed.  It happened to me, but it happened only once.  It's been a while.  We don't have a test case, do we?
I lately experienced something that sounds "like this" using thunderbird 3.0.4 under Linux with messages received from an "X-Mailer: Microsoft Outlook, Build 10.0.6856". This was/is reproducible with every email I receive from that person. The fix was to enable "View > Display Attachments Inline" from the message-menu.
when cache is off and empty

attachment 122896 [details] displays body in plain or html mode. Attachment downloads to word but word can't open it, it may be just sample garbage filler for test email.

attachment 154124 [details] fails to display in plain view. The text/calendar attachment in the message is not available for view or download. The text/plain failure is a dupe I believe and the attachment failure is not applicable to this bug so I'll resolve this if I find a dupe and we can open another one on the attachment or maybe re-describe the bug.  I don't know anything about text/calendar content-type
Assignee: dbienvenu → nobody
This bug is still around, and isn't limited to Mozilla. 

I'm having this issue with MS Outlook 2010, where the mail sender is sending a report from Sendmail (determining the version now) in Red Hat Enterprise 5.6. The messages originally had a TIF embedded in them, but when we saw the problem, we switched to PDF: No change.  I get exactly the same message headers as everyone else.
sendmail-8.13.8-8.el5 is the version for the above comment (#53)
(trying to move this issue forward, or conclude that it is gone - especially given the lack of recent activity, the last CC being in 2012)

Do you still see this problem?
Flags: needinfo?(mozilla)
Flags: needinfo?(mail)
I haven't seen this problem since quite a while. I'm using updated thunderbird-versions as provided by my distri (Fedora).
Flags: needinfo?(mozilla)
Thanks for the update!
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(mail)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: