Closed Bug 101719 Opened 23 years ago Closed 9 years ago

multipart/alternative messages do not display properly ( multipart/alternative[ text/plain+text/html+text/sanitizer-log ] server added third part )

Categories

(MailNews Core :: MIME, defect)

Product:
MailNews Core
Component:
MIME
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.2alpha

People

(Reporter: robert.peacock, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

test message
(deleted), message/rfc822
Details
This is quite similar to 76323 but occurs with multipart/alterantive messages. We have an IMAP server with security (procmail I think) that defangs html formated email messages sent through it, producing multipart/alternative messages like the one following. Only the last part of the message (the one that says it has been sanitized) is visible. Theres no way to navigate to the other parts. This renders Mozilla mail unusable to me, as everyone else in the company is using outlook and html formatting. Return-Path: <mike.johnson@transacttools.net> Delivered-To: robert.peacock@transacttools.net From: "Mike Johnson" <mike.johnson@transacttools.net> To: "Robert Peacock" <robert.peacock@transacttools.net> Subject: RE: REMINDER: 401k Enrollment Date: Wed, 26 Sep 2001 09:16:49 -0400 Message-ID: <NHEFLIHIAFEKOHLKBMDDEEIJDDAA.mike.johnson@transacttools.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0771_01C1466B.F8E13BC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <FMECIOCIHDEIGODIEJCCAEOMCAAA.robert.peacock@transacttools.net> X-Sanitized: True This is a multi-part message in MIME format. ------=_NextPart_000_0771_01C1466B.F8E13BC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit (...SNIP...) ------=_NextPart_000_0771_01C1466B.F8E13BC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <DEFANGED_META http-equiv=3DContent-Type=20 content=3D"text/html; charset=3Diso-8859-1"><DEFANGED_META=20 content=3D"text/html; charset=3Diso-8859-1" http-equiv=3D"Content-Type"><DEFANGED_META=20 content=3D"text/html; charset=3Diso-8859-1" http-equiv=3D"Content-Type"><DEFANGED_META=20 content=3D"text/html; charset=3Diso-8859-1" http-equiv=3D"Content-Type"><DEFANGED_META=20 content=3D"MSHTML 5.50.4807.2300" name=3D"GENERATOR"><DEFANGED_META=20 content=3D"MSHTML 5.50.4807.2300" name=3D"GENERATOR"><DEFANGED_META=20 content=3D"MSHTML 5.50.4807.2300" name=3D"GENERATOR"> <DEFANGED_META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD> <BODY> (...SNIP...) ------=_NextPart_000_0771_01C1466B.F8E13BC0 Content-Type: text/sanitizer-log; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="sanitizer.log" This message has been 'sanitized'. This means that potentially dangerous content has been rewritten or removed. The following log describes which actions were taken. [ score: 1 ] 00135 Rewrote HTML tag: _META http-equiv=Content-Type content="text/html; charset=iso-8859-1"_ as _DEFANGED_META http-equiv=Content-Type content="text/html; charset=iso-8859-1"_ [ score: 2 ] 00136 Rewrote HTML tag: _META content="MSHTML 5.50.4807.2300" name=GENERATOR_ as _DEFANGED_META content="MSHTML 5.50.4807.2300" name=GENERATOR_ Anomy 0.0.0 : sanitizer.pl $Id: sanitizer.pl,v 1.35 2001/02/01 00:10:46 bre Exp $ ------=_NextPart_000_0771_01C1466B.F8E13BC0--
Two things here: 1) The server should be producing multipart/mixed, not multipart/alternative. multipart/alternative means all the parts contain the same info in alternative content types and it's up to the useragent to pick which content type it wants to deal with. The message started as multipart/alternative. But the server breaks that. 2) Looks like we're taking text/sanitizer-log in preference to text/html and text/plain. We should weight the parts by how much we want to deal with them, not take the last one that we can handle... confirming based on point #2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
How about a method for navigating between parts? Seems best to allow the user to choose what to see. Possibly make it configurable which alternative to show?
There is two problems here: 1) We should use the text/html part and not the text/sanitizer-log one (I am not 100% sure if we should really do that) 2) We should offert a way to the user to view another alterative part. I'll try to fix the first problem soon, the second one should be filed as a separate bug as enhancement.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
Attached file test message (deleted) —
This is definitively a bug, Netscape 4.x display correctly the HTML part.
nominating nsbeta1. We should be able to display the correct alternative part. Currently looks like we always display the last one.
Keywords: nsbeta1
Target Milestone: mozilla0.9.9 → mozilla0.9.8
Just thought I'd mention that I poked around in the code and saw a comment there where the logic is to just display the last one saying basically that the MIME RFC says to show the last displayable one, so I guess this is technically correct behavior. Also, just FYI the sanitizer is from the anomy package (mailtools.anomy.net)
From RFC 1341: 7.2.3 The Multipart/alternative subtype The multipart/alternative type is syntactically identical to multipart/mixed, but the semantics are different. In particular, each of the parts is an "alternative" version of the same information. User agents should recognize that the content of the various parts are interchangeable. The user agent should either choose the "best" type based on the user's environment and preferences, or offer the user the available alternatives. In general, choosing the best type means displaying only the LAST part that can be displayed. If I correctly understand it, that doesn't mean we must display the last part but rather the last one we are able to display.
We display only the last part we are able to display inline. In the case of text/sanitizer-log, we don't regonize the subtype sanitizer-log therefore we interpret it as text/plain which we are able to display inline. to fully repect the RFC, the text/sanitizer-log part should not be the last one but rather the first one. Therfore is not realy a Mozilla bug but rather a problem generated by the anomy package. I am willing to figure out a solution by either setting a pref with predefined content/type we should not display inline or maybe give the user the option to choose which part to display. Anyway, that will not append for 0.9.8...
Severity: major → normal
Target Milestone: mozilla0.9.8 → mozilla1.2
Keywords: nsbeta1 → nsbeta1-
*** Bug 121539 has been marked as a duplicate of this bug. ***
I second the request for the ability, as a user, to select which alternative part to look at. The standard might require that the alternatives are just different versions of the same content, but in the real world sometimes the alternatives differ.
Bug 130119 requests a means to select which 'alternative' part is displayed.
Summary: multipart/alterative messages do not display properly → multipart/alternative messages do not display properly
*** Bug 174043 has been marked as a duplicate of this bug. ***
The problem also shows with mailing lists that add a subscription info footer. Just subscribe to the Apache-SSL Mailing list (apache-ssl@lists.aldigital.co.uk). As a suggestion: In case of multipart/alternative if there are more parts of the same mime type, e.g. text/plain, don't display only the last part but concatenate all of these parts.
*** Bug 270188 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Bug 184869 comment 11 complains of a similar problem from AVG's anti-virus certification, viz: http://forums.mozillazine.org/viewtopic.php?t=211394 The message is slightly malformed -- I don't know if AVG is causing the problem or not. The MIME structure of the message is as followed: Content-Type: multipart/mixed Part 1: multipart/alternative Part 1.1: text/plain Part 1.2: text/html Part 1.3: text/plain <-- this part is empty Part 2: text/plain; x-avg=cert; TB and Moz always handle multipart/alternative per the spec: it shows the last of the alternatives that it knows how to handle. Since the last, empty part is text/plain, that's what gets shown as the body. Then the AV certification is shown -- but I'll bet if the View|Display Attachments Inline option is turned off, the message will appear as completely blank. If AVG is responsible for adding that third part, then the problem is AVG's, not Mozilla's. That said, providing a solution for bug 130119 would address this problem as well.
FWIW, another complaint just appeared regarding the same problem with the same combination: AVG & 'watch list' e-mails from eBay. The post is here, but has nothing to add: http://forums.mozillazine.org/viewtopic.php?t=212274
AFAIK, as the AVG mail parser author, the part 1.3 is not added by AVG. If they come from eBay only that would explain why the problem is only visible on the eBay messages. Can someone confirm this ?
The reporter on Mozillazine has posted an update, including source of an eBay e-mail without an AVG cert message. He says the e-mail now displays properly. http://forums.mozillazine.org/viewtopic.php?p=1202435
The source of that new message, as posted in the thread, appears to have two terminal separators: --3163241.1107445981868.JavaMail.ebba.smfbat02-- --3163241.1107445981868.JavaMail.ebba.smfbat02-- appears at the very end. Assuming the poster of the message didn't inadvertantly copy that line in somehow, this could be tripping up AVG's conversion of the original message to a MIME part of the new message.
Assignee: ducarroz → nobody
Status: ASSIGNED → NEW
QA Contact: esther → mime
Product: Core → MailNews Core
Robert this might have been fixed by bug 351224. Could you take a few minutes and download the latest nightly ( http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ ), backup your profile and test and let us know if this is fixed or not ?
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Adding mail structure in bug summary for ease of search.
Summary: multipart/alternative messages do not display properly → multipart/alternative messages do not display properly ( multipart/alternative[ text/plain+text/html+text/sanitizer-log ] server added third part )
This bug : multipart/alternative{ text/plain + text/html + text/sanitizer-log } Why followng can be dup of this bug? Bug 121539 : multipart/mixed Bug 174043 : multipart/alternative{ text/html + text/plain #1 + text/plain #2 + applcation/octet-strem } Bug 270188 : multipart/alternative{ text/plain #1 + text/html + text/plain #2 + text/plain #3 } All mail display problems with multipart is same problem? All mail display problems with multipart/altetnative is same problem? Even if excess part is added to multipart/alternative by server or anti-virus software, diferent issues, isn't it? This bug : text/sanitizer-log should be ignord by Tb because unknown subpart. text/html should be used. Bug 174043 : applcation/octet-stream should be ignored by Tb, text/plain #2 should be used by Tb. Bug 270188 : text/plain #3 should be used according to RFC. No fault in Tb in this case. Or this bug is collection of "excess part is added to multipart/alternative by server or anti-virus software"? Even if so, why Bug 121539 is dup of this bug? I searched relevant bugs to phenomenon of Bug 568574, and reached this bug, and was aware of hard-to-understand duping...
(In reply to Jean-Francois Ducarroz from comment #3) > 2) We should offert a way to the user to view another alterative part. mailnews.display.show_all_body_parts_menu=true(default is false) is already imlemented. If All Body Parts is requested, any multipart part is shown as if multipart/mixed, ao user can access/view/save all sub part.
Viewing the message with TB 9.0a1 (2016-05-17) I see the HTML part displayed. That works as it should. Preference mailnews.display.show_all_body_parts_menu=true shows more body parts.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Of course this was meant to read: Viewing the message with TB 49.0a1 (2016-05-17). Terje, can you please take a look at attachment 62015 [details]. The message has: multipart/alternative text/plain text/html text/sanitizer-log That already displays plain text and HTML parts correctly, even in TB 45, so without your change in bug 253830 or bug 574989. So the "three part test" that you added in bug 574989 was not to show new behaviour that now works but just a test to pin down pre-existing good behaviour, right?
Flags: needinfo?(bugzilla)
The above case works only because thunderbird by default do not know how to display "text/sanitizer-log". On the other hand thunderbird internals knows how to handle "text" (with no slash), so if you run my "three part test" on an existing thunderbird build it will fail.
Got it. Thanks!
Flags: needinfo?(bugzilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: