655535 - Unable to decode Content-Type: application/pkcs7-mime messages when p7m attachment is message body

Status: NEW

(MailNews Core :: MIME, defect)

Description

[David :Bienvenu]

+++ This bug was initially created as a clone of Bug #243833 +++

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.6) Gecko/20040113

When received a message with one or more file attachment of type
application/pkcs7-mime (.p7m) is impossible to see the file and to save it.
See bug 243833 for the one case that isn't fixed - when the attachment *is* the message body.

Comment 1

[Kai Engert [:KaiE:]]

Please see bug 243833 comment 89 + 90.

We actually correctly handle many p7m attachments.

This bug seems to be limited to those p7m parts, that aren't correct MIME entities, but are rather raw binary blobs lacking content-type information.

This bug might be WONTFIX to discourage the use of improper message encodings.

At most, such pieces should be labeled as binary objects of unknown type, and never rendered, at most offered for download/saving.

Comment 2

[David :Bienvenu]

I'm inclined to agree with all of Kai's analysis, but I don't know what program is creating the incorrect messages.

When TB sends a .p7m attachment, it sets the content type correctly to application/octet-stream. Aurelio, do you have any idea what's creating the incorrect content type on your sample messages?

Comment 3

[[:Aureliano Buendía]]

(In reply to comment #2)
> Aurelio, do you have any idea what's creating the
> incorrect content type on your sample messages?

no idea... :-(

Comment 4

[Kai Engert [:KaiE:]]

Could you ask the sender of those messages?

Comment 5

[Serge Gautherie (:sgautherie)]

Could you update bug summary, to differentiate bug 243833 and this bug? Thanks.

Comment 6

[Patrick Brunschwig]

(In reply to comment #1)
> Please see bug 243833 comment 89 + 90.
> 
> We actually correctly handle many p7m attachments.
> 
> This bug seems to be limited to those p7m parts, that aren't correct MIME
> entities, but are rather raw binary blobs lacking content-type information.

I'm pretty sure that it also affects correct messages -- see bug 658793.

Comment 8

[Florian J. [:FeuerFliege]]

I think this is quite the same as bug 658793 but not limited to S/MIME. A mail with the following structure won’t be decrypted as well:

Subject: ...
Content-Type: multipart/encrypted;
 protocol="application/pgp-encrypted";
 boundary="----MSGSEP"

This is an OpenPGP/MIME encrypted message (RFC 2440 and 3156)
----MSGSEP
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification

Version: 1

----MSGSEP

----MSGSEP
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"

DATA

----MSGSEP--

I am building miramars myself now with rev. 9bd80ef2728e locally backed out and they don’t show this bug.

Comment 9

[Patrick Brunschwig]

(In reply to comment #8)
The source of the problems for PGP/MIME encrypted messages (Enigmail) is a different one. It's related to but independent of the bug here: PGP/MIME initialization fails because it depends on this feature to work.

Comment 10

[David :Bienvenu]

This bug as filed was not a regression; it happened in 3.1 as well. So if there are messages that worked in 3.1 but not Miramar, that would require a different bug. Though we may simply back out the fix for bug 243833

Comment 11

[David :Bienvenu]

this attachment from bug 243833 is the one that didn't display correctly in either 3.1 or Miramar - https://bugzilla.mozilla.org/attachment.cgi?id=530588

Comment 12

[milo]

Why in 2.2 seamonkey release this problem was fixed and in the next versions it reappeared? Can someone fix the problem reappeared after 2.2 release?
At the moment if enyone have the p7m problem can install the 2.2 seamonkey version.

Comment 13

[Matilda]

In SeaMonkey 2.16.2 attachments "p7m" are stripped away, while in the contemporary version of Thunderbird (17.0.4 version) the bug has been fixed. It's not possible to adopt the same solution choosed for Thunderbird to SeaMonkey?
Please, consider this.
Thank you! :-)

Comment 14

[Matilda]

In SeaMonkey 2.17 finally the issue seems fixed!
Great 'n thank you so much!

Comment 15

[Matilda]

Forget it, unfortunately.
On a computer (OS: Windows XP Pro), SeaMonkey can manage attachments "p7m".
In another computer (the same operating system and the same configuration & addons of the browser), SeaMonkey continues to have the issue.
I will do further testing ...

Comment 16

[Wayne Mery (:wsmwk)]

Matilda, can you report results?

(In reply to Matilda from comment #15)
> Forget it, unfortunately.
> On a computer (OS: Windows XP Pro), SeaMonkey can manage attachments "p7m".
> In another computer (the same operating system and the same configuration &
> addons of the browser), SeaMonkey continues to have the issue.
> I will do further testing ...

Comment 17

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 18

[bugzilla.mozilla.org]

Hi there

I think  I'm facing the same issue with tb 38.3. In a mailing list a users uses pkcs7 to sign the emails. However when I view them, I just get a blank page and the mail is never marked as read but stays unread. Viewing the source shows the mail just file.

I have posted here the source code of one such mail: https://paste.simplylinux.ch/view/raw/4d6e6b22