User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 In many of my messages imported from Outlook the main text has somehow become a text only attachment named "Part 1.1". This attachment is not displayed even when Display Attachments Inline is checked. See also my recent comment on bug 207156. Here is part of the source of one of the messages affected (names replaced by ?'s for privacy). I received this in Outlook 2002 and imported it into Mozilla (using 1.4 RC1 at the time): MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------040202010502090307010902" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 This is a multi-part message in MIME format. --------------040202010502090307010902 Content-Type: Content-Transfer-Encoding: 8bit Dear friends Please find our latest newsletter attached ???? & ?????? --------------040202010502090307010902 Content-Type: application/x-zip-compressed; name="news0306.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="news0306.zip" Reproducible: Always Steps to Reproduce: 1. Check "Display Attachments Inline" 2. Select a message with no text but an attachment named Part 1.1. 3. Attempt to display it Actual Results: Part 1.1 text not displayed Expected Results: Part 1.1 text displayed as an inline attachment

Comfirmed. If original mail in Outlook has no attached file, imported mail body becomes "Content-Type:" header with no parameter only, and no problem occurs. (In this sample, main text is kept in Shift_JIS in Outlook) >Content-Type: > >=83c=81[=83=8B=93=B1=93=FC=82v=82f=83=81=83=93=83o=81[=8Ae=88=CA However, if original mail in Outlook has an attachemnt file, imported mail body becomes multipart/mixed and main text(Shift_JIS) part is imported as a part of combination of "Content-Type:" header with no parameter and "Content-Transfer-Encoding:" header(quoted-printable in this sample). The main text is showed as an attachment named "Part 1.1" in this case and this attachment is not displayed even when Display Attachments Inline is checked. >Mime-Version: 1.0 >Content-Type: multipart/mixed; > boundary="------------050409040608060603090902" >(Snip) >This is a multi-part message in MIME format. >--------------050409040608060603090902 >Content-Type: >Content-Transfer-Encoding: quoted-printable > >=83c=81[=83=8B=93=B1=93=FC=82v=82f=83=81=83=93=83o=81[=8Ae=88=CA >--------------050409040608060603090902 >Content-Type: application/octet-stream; > name="=?Shift_JIS?B?g2OBW4OLk7EuZG9j?=" >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; > filename="=?Shift_JIS?B?g2OBW4OLk7EuZG9j?=" > >(Snip) --------------050409040608060603090902-- > If "text/plain;charset=shift_jis" parameters were added on "Content-Type:" header manually, the main text part was showed as an attachment named "Part 1.1" again, but main text was displayed inline in both "Display Attachment Inline=checked" and "Display Attachment Inline=unchecked" cases. >Content-Type: text/plain; charset=shift_jis >Content-Transfer-Encoding: quoted-printable > >=83c=81[=83=8B=93=B1=93=FC=82v=82f=83=81=83=93=83o=81[=8Ae=88=CA

Additional information. An Outlook/Mozilla user in Japan reported workaround. Import mails of Outlook to Outlook Express, then import mails of Outlook Express to Mozilla.

Isn't this a DUPE of bug 199298?

To some extent, yes. This bug is actually two bugs: 1) Main text sometimes becomes Part 1.1 = bug 199298; 2) Part 1.1 is not displayed even when Display Attachments Inline is checked. My "expected results" as below imply that bug 2) is fixed. Better still, bug 1) = bug 199298 should be fixed as well.

The fact that the main body of the posted message excerpt has a blank Content-Type header is what clued me to the dupe. *** This bug has been marked as a duplicate of 155537 ***

To Comment #5 From Mike Cowperthwaite : Some problems are included in this bug as Peter Kirk says. 1) Main text sometimes becomes Part 1.1 = summary of bug 199298; 2) Part 1.1 is not displayed even when Display Attachments Inline is checked = Bug 155537 (Blank display problem when blank Content-Type) In addition, 3) Import from Outlook generates mail causes abobe two problems. Since Outlook->Outlook Exprees->Mozilla imports mail properly, something is wrong in import from Outlook. Further, Bug 199298 has three problem. (A) Import from Outlook generated blank Content-Type header - folded header indicatior(space or TAB follows CR+LF) missing. (B) (A) causes "msg body as Part 1.1 attachment" problem (= summary of Bug 199298) (C) (A) also causes problem of Bug 155537 (Blank display problem when blank Content-Type). So closing this bug as DUPE of bug 155537 is not appropriate, I think. (Bug-1) Bug 15537 : Blank display problem when blank Content-Type (This problem caused by received mail instead of imported mail) (Bug-2) New bug : "msg body as Part 1.1 attachment" problem when blank Content-Type and/or other conditions (Bug-3) Bug 199928 - Problem in importing from Outlook #1 Insufficient or invalid handling of special Outlook mail data - folded header indicatior(space or TAB follows CR+LF) missing (Bug-4) Bug 210606 (This bug) - Problem in importing from Outlook #2 Insufficient or invalid handling of special Outlook mail data - Blank Content-Type header is created (Probably same cause as Bug 199928) I believe too that almost all problems of this bug will disappear if (Bug-1) and (Bug-2) will be closed. However, no charset parameter on Content-Type for body sometimes causes diaply problem when non-ascii character set is used, although auto-detect of character coding usualy reliefs the problem. Therefore I think keeping this bug open is appropriate. What do you think?

Sorry for typo and spam Bug 155537 (<-Bug 15537) Bug 199298 (<-Bug 199928)

I think bug 199298 comment 1 may be the solution behind that bug, this bug, and bug 155537. Comments in bug 155537 indicate that the blank Content-Type symptom is not necessarily the problem. I might have marked this as a dupe prematurely, but there is no one bug that consistently describes the problem.

I agree with WADA in comment 6 that there are several bugs here. I don't think his/her Bug-2 is really a bug, as this seems to be a sensible response when a message part is found with blank content type. In such cases the message part should also be displayed (with a default or auto-detected encoding), but that is bug 155537, at least as WADA has described it. If bug 155537 is fixed, these message parts will be viewable in a sensible way, and so the main problem is fixed. But the problem of incorrect handling of such message parts is logically distinct from the problem that they are generated. And so it is certainly a separate bug, not a duplicate, although fixing it is less urgent if bug 155537 is fixed. So I would suggest leaving this bug 210606 open, and clarified as relating to Outlook import only (e.g. description shortened to "Main text of message imported from Outlook treated as attachment"); but to give higher priroity to fixing bug 155537.

First: my comment 8 is misguided, and that information from bug 199298 appears unrelated to this problem. I'm not sure what it comes from. Second: If the Content-Type is blank, then Mozilla will not display the body *and* will show a "Part 1.1" attachment. These two symptoms are both part of the same problem and the same bug, comment 4 notwithstanding. I've attached a testcase to bug 155537. There are likely other cases where "Part 1.1" will be displayed (see the old symptom at bug 95266, and the following point). Third: the "folded header missing leading blank" noted in bug 199298 is not part of the original report. That commentor put his information into several of these related bugs (just as I did, so I assume he was as confused as I was :) So, it is unclear that that issue pertains to this one. Fourth: WADA's test case with "Content-Type: text/plain;charset=shift_jis" does not seem to be entirely the same bug, despite the appearance of a "Part 1.1". I guess the encoding must have something to do with it: - As noted in bug 155537, a single-part ASCII message with blank Content-Type often, if not always, appears as empty with an attachment called "attachment" -- this is inconsistent with the first example in comment 1. - A multi-part ASCII message with a typical "Content-Type: text/plain" header on the body does not show an attachment entry for the body -- this is inconsistent with the third example in comment 1. Fifth: I can't tell from any of these reports if it makes a difference whether the message was imported or was received. It is possible that the import process is somehow screwing up the messages; if so, then that is probably what bug 199298 should be devoted to. Peter Kirk, if you think this might be the case, please do the following: Create a message in Outlook with a (small!) attachment. Send it to an account that is read by Outlook and an account that is read by Mozilla. Save the message from Outlook into a .EML (or .MSG or whatever Outlook uses) Save the message read by Mozilla into a .EML Import the Outlook folder into Mozilla, then save the message AGAIN into a .EML. With these three forms of the message (as received by Outlook, as received by Mozilla, as imported by Mozilla), we can determine if importing is a problem. I suggest attaching those files to bug 199298; but please wait until the reporter of that bug (Sam Hulick) has had a chance to respond. (I would do this myself, but I do not have access to a system with Outlook on it.)

Unfortunately I no longer have Outlook available and so cannot do what Mike requests in comment 10. Let me rephrase the main part of comment 4 as there was some confusion between Mike and me over it: This bug is actually two bugs: 1) Main text sometimes becomes an attachment with blank Content-Type and is listed as Part 1.1 (now we think not = bug 199298; so this should be the reopened bug 210606); 2) Attachment with blank Content-Type is not displayed even when Display Attachments Inline is checked (= bug 155537). (There is a third bug mentioned by WADA in comment 6 = bug 199298, but this is not directly related to this bug.)

To Comment #10 From Mike Cowperthwaite : > Fourth: WADA's test case with "Content-Type: text/plain;charset=shift_jis" does not seem to be entirely the same bug Sorry for my confusing description. My case is real case of blank Content-Type generated by import from Outlook. "adding text/plain;charset=..." is only the evidence that cause of non-display text problem is "blank Content-Type". This is same case as commnet #0 and can be a example of bug 155537. > Fifth: I can't tell from any of these reports if it makes a difference whether the message was imported or was received. If Outlook does not keep any information related to "text/plain" or "text/plain; charset=xxxx" in his mail DB, avoiding blank Content-Type header on import is very difficult, I think. This is very possible becasue there is another bug you mentioned in Bug 199298 Comment #3, Bug 166646. But Outlook->Outlook Express->Mozilla can generate non blank Content-Type header properly. This is the reason why I suspect something wrong in Mozilla in importing Outlook mail. Please note that bug 199298 is already found. Therefore I agree with Comment #11 From Peter Kirk.

Verified dup.

Stephen, I am confused. If this bug is a duplicate, which bug deals with the issue that on import from Outlook "Main text sometimes becomes an attachment with blank Content-Type and is listed as Part 1.1"? This is not part of bug 155537, which deals with the problem that such text is not displayed, although that is the bug of which this one is officially a duplicate. It does seem to be the issue described in the name and original report of bug 199298. But the separate issue raised in bug 199298 comment 1 is unrelated. Is this a fair summary of how we all see things now? I just want to make sure that neither of the two significant issues fall between the cracks.

Peter Kirk, I just added a comment to bug 199298 -- I was informed in email by Roberto Salomon that the issue in bug 199298 comment 1 is unlikely to have anything to do with that bug, or with the import-from-Outlook function at all. In our earlier email exchange, I failed to understand that you were concerned about that particular problem; sorry!

Bug 219181(and DUPE Bug 224278) says that attachment portion was not imported when import form Outlook.

(In reply to comment #16) > Bug 219181(and DUPE Bug 224278) says that attachment portion was not imported > when import form Outlook. Bug 219181 is in fact three quite separate bugs. As originally reported, and concerning an unspecified version of Outlook, it is 1) a dupe of this one and 2) a report that attachments are renamed. Then bug 219181 comment 1 is bug 3) relating to Outlook *2003* (then newly released), stating that attachments are not imported.

Peter Kirk, Bug 235159 has been reported as import problem from Outlook 2003. Reporter of the bug has both Ooulook and Outlook Express. So Bug 235159 seems to be the appropriate bug for discussion on Outlook Mail import problem. Let's give up discussion in this bug and let's try to analyze the problem in Bug 235159.

(In reply to comment #18) > Peter Kirk, Bug 235159 has been reported as import problem from Outlook 2003. > Reporter of the bug has both Ooulook and Outlook Express. > So Bug 235159 seems to be the appropriate bug for discussion on Outlook Mail > import problem. > Let's give up discussion in this bug and let's try to analyze the problem in Bug > 235159. No. Bug 235159 is a separate issue with Outlook 2003, not Outlook 2002, with separate (and much more serious) symptoms. While I can see an argument for not fixing a bug importing from Outlook 2002 when it has been superseded by Outlook 2003, that does not impact the fact that this bug is a different bug from bug 235159. Bug 235159 is also a duplicate of bug 219181 comment 1.