If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Multiple level embedded message not correctly supported [IMAP copy problem?]

VERIFIED WORKSFORME

Status

MailNews Core
MIME
P3
normal
VERIFIED WORKSFORME
17 years ago
9 years ago

People

(Reporter: stephend@netscape.com (gone - use stephen.donner@gmail.com instead), Assigned: Jean-Francois Ducarroz)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Build ID: Fresh CVS pull @ 1pm on April 3rd, 2001 using Windows 2000 with IMAP.

Summary: Attachment with MIME Content-Type: application/octet-stream; isn't 
recognized.

Steps to Reproduce:

1.  Save the attached .eml file and view it in Mozilla.

Expected Results:

The message should contain the MADCOW12.doc attachment and should have the 
attachment UI.

Actual Results:

Just the message is displayed.  If you didn't view the source, you'd never know 
an attachment existed.

Note:  
Content-Type: application/octet-stream;
        name="MADCOW12.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="MADCOW12.doc"

is the content type for the attachment that won't display.

Content-Type: application/msword;
        name="Springboard Info Sheet.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="Springboard Info Sheet.doc"

is the content type for a similar attachment that displays correctly.

I should note, my Dad used X-Mailer: Novell GroupWise 5.5.2 to attach the 
message (but this displays fine in 4.x).
Created attachment 29651 [details]
The message with the attachment you can't see.
Created attachment 29652 [details]
The MADCOW12.doc
Is this a networking/helper apps bug?
Keywords: nsbeta1, nsdogfood

Updated

17 years ago
Whiteboard: [nsbeta1+]

Updated

17 years ago
Priority: -- → P2
Target Milestone: --- → mozilla0.9.1

Comment 4

17 years ago
Stephen, could you try this again? I downloaded your message, put it in a folder
and was able to see the attachments and actually opened it up in Word.
Tried this again, and it's still not working for me with build 2001042404, yet
OE 5.5 displays it fine.  OE 5.5 displays the message as a multi-nested
attachment.  That is, to get to madcow12.doc, I have to:
[1] Open the original e-mail.
[2] Open a 211KB attachment called "Steak or Fish?" 
[3] And then open the 209KB "MADCOW12.doc" attachment.

This is pretty involved and to guarantee I'm not missing something, we should
troubleshoot in my cube ;-)

Much thanks goes to Scott Putterman for reducing this to a 100% bullet-proof
testcase.  This is an IMAP bug.  Here's the best way to repro:

1.  Save the first attachment    
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=29651) into your
profile's Local Folders directory. (if it has *.txt attachments, strip the
extensions).
2.  Verify that the message is correct (in Local Folder, it will have 2
attachments, the MADCOW12.doc file and the Steak or Fish? eml file as an
attachment (but is displayed inline).
3.  Move or copy this message to an IMAP folder.

Notice now that you lost the Word attachment, but the e-mail is preserved
otherwise (and viewing source still shows the e-mail as containing a word
attachment.)

Thanks, again.
(Assignee)

Comment 7

17 years ago
This is not an IMAP problem. For some reason, when the message is copied from 
the local folder over to the IMAP folder, the first part of the message is 
duplicated. If I duplicated the first part on my local copy, I cannot display 
the attachment anymore.

This is a very stange message in which the main part is itself another message! 
normally, when you forward a message (apparently as attachment), the message is 
part of a multipart mixed message! Also, this message, once moved to the 
imap folder contains a message inside a message inside a message. Looks like we 
are not very well supporting multiple level embedded message.

Here is the structure of the message on IMAP:

content-type=message/rfc822
  content-type=message/rfc822
    content-type=text/plain
    content-type=application/octet-stream

I don't think this kind of message are very common and therefore I am proposing 
to move to to next millestone.
Severity: major → normal
Priority: P2 → P3
Summary: Attachment with MIME Content-Type: application/octet-stream; isn't recognized. → Multiple level embedded message not correctly supported
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Created attachment 35835 [details]
Another message with an invisible attachment
(Assignee)

Comment 9

17 years ago
Accepting. This want be an easy one...
Status: NEW → ASSIGNED

Comment 10

17 years ago
It looks like Stephen's 2nd message is multipart/mixed so perhaps this will be
easier to solve?

Comment 11

17 years ago
http://bugzilla.mozilla.org/show_bug.cgi?id=76323 also has a multipart/mixed
attachment that's not showing up.  

Comment 12

17 years ago
adding PDT+
Whiteboard: [nsbeta1+] → [nsbeta1+][PDT+]

Comment 13

17 years ago
Jean-Francois,

Does Scott's fix in http://bugzilla.mozilla.org/show_bug.cgi?id=83547 fix the
invisible attachment problems mentioned in this bug? If so, then I think we can
push the rest of this off.
(Assignee)

Comment 14

17 years ago
no that doesn't fix the problem. We still mofying the message when we move it
over  IMAP!!!
(Assignee)

Comment 15

17 years ago
However, moving the message over to a pop3 folder is fine, I can still see the
attachment. Definitivly something wrong going on during the IMAP copy!

Comment 16

17 years ago
moving to 0.9.3 and cc'ing naving.

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Updated

17 years ago
Whiteboard: [nsbeta1+][PDT+] → [nsbeta1+]
(Assignee)

Comment 17

16 years ago
The problem about the message headers getting duplicated while copying the message to an IMAP folder comes form 
our Mail server! I did the same test using 4.x and hit the problem too. CC'ing jgmyers in case he has any idea?

Comment 18

16 years ago
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Keywords: nsBranch

Comment 19

16 years ago
Mail news triage meeting --> .9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Updated

16 years ago
Blocks: 99230

Comment 20

16 years ago
cleaning up nsbranch keywords. 
Keywords: nsbeta1, nsbranch → nsbranch-
Whiteboard: [nsbeta1+]

Updated

16 years ago
No longer blocks: 99230

Comment 21

16 years ago
moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Updated

16 years ago
Target Milestone: mozilla0.9.6 → mozilla1.0

Updated

16 years ago
Blocks: 107067

Updated

16 years ago
Keywords: nsbranch-

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla1.2

Comment 22

14 years ago
I integrated the two messages attached to this bug into my email, then copied 
them over to an IMAP folder.  Opening those messages, I was able to 
view/download the attachment (.doc or .ppt) from the attachment panel in 
top-level window, and also in the message windows obtained by opening the .eml 
attachments.  (Mozilla 1.6)

I'm not 100% sure that what I did corresponded to the problem described here, 
but someone who knows the bug better might want to see if this has been fixed 
somewhere along the way.
Summary: Multiple level embedded message not correctly supported → Multiple level embedded message not correctly supported [IMAP copy problem?]
Target Milestone: mozilla1.2alpha → ---
Product: MailNews → Core

Comment 23

12 years ago
Stephen Donner, any need to keep this bug open?
Mike, thanks for the reminder.  I just tested with build SeaMonkey 1.1a;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051101 Mozilla/1.0, and both moving and copying these from Local Folders under IMAP retained all attachments just fine.  No patch in this bug itself, but obviously *something* in the past 4 years has fixed this, but since I can't put my finger on it, marking as WFM.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME

Updated

12 years ago
Status: RESOLVED → VERIFIED
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.