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).
Is this a networking/helper apps bug?
Keywords: nsbeta1, nsdogfood
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:  Open the original e-mail.  Open a 211KB attachment called "Steak or Fish?"  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.
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
Accepting. This want be an easy one...
Status: NEW → ASSIGNED
It looks like Stephen's 2nd message is multipart/mixed so perhaps this will be easier to solve?
http://bugzilla.mozilla.org/show_bug.cgi?id=76323 also has a multipart/mixed attachment that's not showing up.
Whiteboard: [nsbeta1+] → [nsbeta1+][PDT+]
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.
no that doesn't fix the problem. We still mofying the message when we move it over IMAP!!!
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!
moving to 0.9.3 and cc'ing naving.
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?
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
18 years ago
Mail news triage meeting --> .9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
cleaning up nsbranch keywords.
Keywords: nsbeta1, nsbranch → nsbranch-
moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
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 → ---
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: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.