Closed Bug 101719 Opened 21 years ago Closed 6 years ago

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


(MailNews Core :: MIME, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: robert.peacock, Unassigned)


(Blocks 2 open bugs)



(1 file)

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: <>
From: "Mike Johnson" <>
To: "Robert Peacock" <>
Subject: RE: REMINDER: 401k Enrollment
Date: Wed, 26 Sep 2001 09:16:49 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/alternative;
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: <>
X-Sanitized: True

This is a multi-part message in MIME format.

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit


Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<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"
content=3D"text/html; charset=3Diso-8859-1"
content=3D"text/html; charset=3Diso-8859-1"
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>


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 ]
Rewrote HTML tag:
	_META http-equiv=Content-Type content="text/html; charset=iso-8859-1"_
_DEFANGED_META http-equiv=Content-Type content="text/html; charset=iso-8859-1"_

[ score: 2 ]
Rewrote HTML tag:
	_META content="MSHTML 5.50.4807.2300" name=GENERATOR_
_DEFANGED_META content="MSHTML 5.50.4807.2300" name=GENERATOR_

Anomy 0.0.0 :
$Id:,v 1.35 2001/02/01 00:10:46 bre Exp $

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.
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.
Target Milestone: --- → mozilla0.9.9
Attached file test message
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 (
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: nsbeta1nsbeta1-
*** 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 (

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:

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:
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.
The source of that new message, as posted in the thread, appears to have two 
terminal separators:


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
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 ( ), 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.
Closed: 6 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:

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.