190905 - [MIME] "This body part will be downloaded on demand"

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[ramin rezaii]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030125
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030125

Since I switched from POP3 to IMAP, I get the following message in the body of
the some of the email messages:
"This body part will be downloaded on demand".

I cannot figure out a common attribute amongst email messages that cause this
message.

My solution has been to forward the message to myself in order to view the body
of the message.  

I would be great if someone can take a look at this problem.

Reproducible: Sometimes

Steps to Reproduce:
1. receive a message (I think all of them that cause the problem have attachments)
2.
3.

Actual Results:  
Only displays "This body part will be downloaded on demand" in the body of the
message

Expected Results:  
Show the body of the message.

Comment 1

[David :Bienvenu]

can you attach a message that exhibits this problem, or send it to me? Also,
what view | message body as setting do you have? I've never seen this.

Comment 2

[Chris Sims]

I have been finding this problem with IMAP mail also.  It seems to be possible,
at least usually, to get the message body to display by cycling among the "view
|message body as" options.  Once the message body does display, it stays there
for all the "view | message body as" choices.

I originally thought this problem began when I checked the "Mail & Newsgroup
Account Settings|<acct name>|Offline and Disk Space| Do not download locally
messges that are larger than 50KB" option.  With that option checked, it may
happen even when there is no attachment.  But today it has been happening (using
build 2003020608) without the 50KB option checked on some emails that have
attachments.  (Mine is an NT 4.0, SP6, system.)

Comment 3

[Rob Thorne]

I get this frequently.  Reading message source, I'm seeing two patterns:

1) Messages sent from Outlook Express 6.0 seem to get this frequently.

2) The text section is mostly (always?) quotable-printable.

3) The mime headers are set up different from those used by Mozilla Messenger

I'm guessing that the quoteable/printable piece is what's screwing up MM 1.3b. 
If  a setting for this still exists in MM, I'll see if I can reproduce this that
way.

Comment 4

[Rob Thorne]

I think I've got it.  It's one of the mail headers.

The following fragment of a header is from a message that exhibits the problem:

Subject: Fw: Columbia Astronaut, Ilan Ramon defeated Saddam Hussein's first
att\empt to acquire Nuclear Weapons in 1981
Date: Wed, 26 Feb 2003 09:55:46 -0500
MIME-Version: 1.0
Content-Type: multipart/related;
        type="multipart/alternative";
        boundary=----="_NextPart_000_0006_01C2DD7D.3C0D4BB0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106


Note that the boundary line puts the MIME label ("_NextPart...") in double quotes.

That appears to be what's tripping up Messenger.  If I edit the message and
removed the double quotes, *the message renders correctly*.

Hopefully this explains the problem.

Comment 5

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

from rob's last comment, this might be a mime bug.

gail (and lori) have started seeing this with messages sent with attachments.

it sounds like she[s see it from messages from mailers like:

"X-Mailer: Apple Mail (2.552)"
"X-Mailer: 9.0 for Windows sub 270" (maybe AOL 9.0?)

Even if this turns out to be a problem with other mailers, we might want to fix
our MIME code (if possible) to handle it.

Comment 6

[Kai Engert (:KaiE:)]

I can't reproduce trying to construct a message myself.
Ramin, can you please forward a defective message to our email addresses?

You might also want to try a newer build. You have tested with Mozilla 1.3 beta.
Could you please try with 1.3.1 or 1.4?

Comment 7

[Rob Thorne]

I'm also not able to duplicate my old results with 1.4RC3; moreover, I haven't
seen any messages that misbehave this way since at least 1.4beta.

At least some of the old examples (although not all) were virus payloads where
I'm guessing the virus author got the MIME headers wrong.

But the current code does not seem to be sensitive to quoting the 'boundary='
portion of the mail header.  I tried recreating a bad header according the old
recipe, and recent builds still extract the MIME fields just fine.

If any of the QA people are still seeing this, I recommend that they look at the
source of the message, and see if there is any quoting of MIME-related portions
of the headers.  If they do, then they are looking at a variant of the bug I
saw; if they don't, you may be looking at something new.

Comment 8

[Henry Avetisyan]

This issue seems to be with the message structure and not the boundary header.
It can be reproduced with using only Mozilla 1.4 client. The problem seems to be
with the multipart/alternative bodypart. For example, if the message has a
content type of multipart/mixed and the first body part is of
multipart/alternative (with text/plain and text/html) and the second body part
is just a binary attachment (for example, application/zip), then the mail client
is not able to show the text of the message and shows instead "This body part
will be downloaded on demand."

Steps to reproduce:
a) Configure your mail client to compose messages in html format
b) Configure your mail client to send messages in both plain and html formats
c) Send a message to yourself that contains html text (e.g. change the
background color) with a zip attachment that's over 50K.

Comment 9

[Bill Bache]

I'm using Mozilla 1.5b and IMAP, and I still get this bug. This differs from Rob
Thorne's report in Comment #7. 

If I change "view | message body as" to Plain Text, then the message body
appears.  If I change it back to Original HTML or Simple HTML, then it goes back
to "This body part will be loaded on demand."  (This differs from Chris Sims's
report in Comment #2.)

I could not reproduce the bug using Henry Avetisyan's directions in Comment #8.

Comment 10

[Jason Clinton]

I am experiencing the exact same behavior describe in comment #9. However, this
is on Thunderbird 0.3. It seems to only affect messages coming from Outlook or
Outlook Express that have attachements.

Comment 11

[Steve Roth]

For what it's worth, I'm seeing this same problem on Thunderbird 0.4a (031110
build), on a message that was sent from Eudora 5.2.1.  It too has a quoted
boundary= string.  I see it only when viewing message as HTML (simple or
original); the message appears normally when viewed as plain text.

Comment 12

[coen]

Related to, or the same as bug 45790?

Comment 13

[David :Bienvenu]

can I get an imap protocol log of a session where this imap message is selected,
by following these instructions?
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Or, better yet, can anyone get me access to a test account with a mail message
that shows this problem? Also, can you try this with tomorrow's build? I fixed a
problem that occurred in the parsing of body structure responses when the quoted
literals contained escape characters - that's almost certainly not the issue
here, but it's worth a try.

Comment 14

[Wayne Coulby]

Attachment: Message with "This body part will be downloaded on demand"

Here is a message that causes this to occur. The behavior is the same as
described in comment #9.

Comment 15

[David :Bienvenu]

I put the attached message on three different imap servers and didn't have any
problem reading it on any of them...I tried this with my tip debug mozilla
build, a recent debug thunderbird build, and a 1.6a mozilla release build. It
looks to me like the message source was the same on the imap server as the
attached message. Can I get an imap protocol log of a session selecting this
message? thx.

Comment 16

[Wayne Coulby]

Attachment: Imap log

Here is the log of a session selecting the message and it not showing.

I discovered an interesting thing however: if the message is in the Inbox imap
folder, it appears normally and this bug doesn't apply. If the message is in
any folder other than Inbox, this bug applies.

Comment 17

[David :Bienvenu]

can you attach a log of trying this in the inbox so I can see the difference?
From the log, it looks like we're only fetching the plain text part, which is
surprising, unless it's just that we pick the first part - you do have it set to
display html, right?

Comment 18

[coen]

Attachment: Imap log from thunderbird

Imap log from thunderbird.
Complete message comming up.

Comment 19

[coen]

Attachment: Problem message from inbox

Comment 20

[David :Bienvenu]

in my testing, Mozilla downloads the whole message, and not just a single part.
Will debug further.

Comment 21

[Wayne Coulby]

Attachment: Imap log (message in Inbox)

Here is the log when viewing the same message in the Inbox where the bug
doesn't occur. And yes, it is set to view HTML.

Comment 22

[David :Bienvenu]

I see how to reproduce this - you must have "show attachments inline" turned
off. If I turn that off, then I can reproduce this.

Comment 23

[David :Bienvenu]

we're not fetching the message in that last log, which leads me to think that
you have your inbox configured for offline use, which removes the imap body
structure handling from the picture.

Comment 24

[David :Bienvenu]

so the quick workaround is to pick the view | display attachments inline menu
item. I'll try to figure out how to fix the code to display the correct part.

Comment 25

[David :Bienvenu]

4.x also just fetches the first part in this situation. I think the same
protocol gets run in 4.x and Mozilla, so the problem is either in mime, or in
the cache code - we're streaming the part into mime, but it still has the "this
part will be downloaded..." content.

Comment 26

[coen]

My imap account is not configured for offline use.
When I enable 'show attachments inline' the complete message is displayed.

Display message as is configured for 'simple html'. When set to 'plain text' I
can see the plain text part of the message.

Comment 27

[David :Bienvenu]

Attachment: potential fix

The problem was that we were chosing to fetch the first imap part in case of
multi-part alternative messages, and left the other parts as "load on demand".
But, the mime code picks the last part in multi-part alternative messages (as
it's supposed to).

this patch fixes the problem by making imap mpod load the last text part, not
the first one - since that's what mime is going to display, that works a lot
better. The one glitch is that is you chose viewing the message body as plain
text, you'll get this bug again. Not quite sure how I'll fix that.

Comment 28

[David :Bienvenu]

Attachment: proposed fix

this fixes the aforementioned problem when the user is displaying messages as
plain text with view attachments inline off

Comment 29

[Scott MacGregor]

checked into the M4 branch of tbird

Comment 30

[David :Bienvenu]

fix checked into trunk. I think this should go into 1.6 as well.

Comment 31

[David :Bienvenu]

really marking fixed.

Comment 32

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 137576 [details] [diff] [review]
proposed fix

I'm guessing you meant to request approval, although it may be too late.

Comment 33

[David :Bienvenu]

d'oh, yeah. It's not crucial. We've lived with this bug for a long time now.

Comment 34

[Simon Paquet [:sipaq]]

Comment on attachment 137576 [details] [diff] [review]
proposed fix

Removing obsolete review requests.

Comment 35

[David :Bienvenu]

Comment on attachment 137576 [details] [diff] [review]
proposed fix

this fix has been on the trunk and in thunderbird for a while with no reports
of problems. The code change only affects the previously broken case.

Comment 36

[Mike Kaply [:mkaply]]

Comment on attachment 137576 [details] [diff] [review]
proposed fix

a=mkaply
Please get in fast and mark "fixed1.4.2"
Is the spacing off on this patch?

Comment 37

[David :Bienvenu]

yes, this is a -uw diff, so it doesn't show the whitespace cleanup I did with
the initial trunk checkin.

Comment 38

[David :Bienvenu]

*** Bug 45790 has been marked as a duplicate of this bug. ***

Comment 39

[Bill Bache]

(In reply to comment #38)
> *** Bug 45790 has been marked as a duplicate of this bug. ***

(In reply to comment #37)
> yes, this is a -uw diff, so it doesn't show the whitespace cleanup I did with
> the initial trunk checkin.

What version of Mozilla will include the fix to this bug?  I'm using
1.6.20040.11308 -- downloaded 1/28 -- and it still happens.


-- 
Bill Bache
[e-mail]
Cell ph.: 503-358-5556
Home fax: [phone]

Comment 40

[Michael Lefevre]

Bill - the build you have is a 1.6 branch build.  Seeing as 1.6 is out, what you
have is the 1.6 release code with a new build date on it (i.e. there's no point
in getting newer 1.6 builds any more)

This fix didn't make it in time for 1.6. To get a build with the fix you'll need
a trunk nightly build (i.e. a pre-1.7alpha build) from
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/

Comment 41

[Anton R. Ivanov]

We are observing this with 1.7 so it is not fixed yet   
   
Server software: courier-imap 0.42.2-10 rebuilt for debian stable   
Client software: mozilla 1.7 on Windows XP   
Mail triggering the problem is a 125669 message containing 3 pdfs and an html   
part. The headers look OK and render correctly in kmail (from kde 3.2),   
outlook and evolution (1.4).   
   
Trying to change view as does not change a thing. Trying to change the headers   
on the server does not change anything either.    
   
Message headers look ok except the boundary line which is a bit strange. It   
is: boundary="=====================_113006344==_"   
   

Comment 42

[Mike Cowperthwaite]

Bug 246415 has been opened about the persistence of this problem into 1.7.