Closed Bug 705059 Opened 8 years ago Closed 5 years ago

attachment with individual PKCS7 signature is hidden in received email (subpart of Content-Type:application/pkcs7-mime need to be shown as attachment if Content-Disposion: header is also specified)


(MailNews Core :: Security, defect)

Not set


(Not tracked)



(Reporter: devotip, Unassigned)



(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

Received an email with a digitally signed attachment following are snippets of the email source, I can't provide the whole

header cut
Content-Type: multipart/mixed;
MIME-Version: 1.0

Content-Type: multipart/alternative;

Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

email body one

Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

email body two


Content-Type: application/pkcs7-mime; name="ModuloAdesione[1].pdf.p7m"
Content-Description: ModuloAdesione[1].pdf.p7m
Content-Disposition: attachment; filename="ModuloAdesione[1].pdf.p7m";
	size=107921; creation-date="Wed, 23 Nov 2011 10:44:25 GMT";
	modification-date="Wed, 23 Nov 2011 10:44:25 GMT"
Content-Transfer-Encoding: base64

encoded file


email end

Actual results:

the attachment was not accessible within the email and there was no clip on side of email to tell "attachment inside" but it showed up when forwarding the email

Expected results:

just having the attachment handled as an attachment
I can confirm this one using TB8 on Win7 / 64bit. I'll add an attachment with such a disbehaving mail.
Ever confirmed: true
Setting platform to All/All as this does also happen on MacOS 10.6
OS: Windows Vista → All
Hardware: x86 → All
Component: General → Mail Window Front End
QA Contact: general → front-end
It may be on purpose that pkcs7 attachments aren't shown as they are technically just the signature but not an attachment. However, ModuloAdesione[1].pdf.p7m in your case may be something else - it appears that the PDF attachment was signed individually and not the whole message, is this what you are seeing?

(In reply to Peter 'vt100' Schwindt from comment #2)
> Created attachment 576705 [details]
> (censored) message where we cannot see an attachment

That example is a completely different case since it shows that the message itself has just a single MIME part which is audio content. Thus, this isn't an attachment either (no multipart/mixed construct) and doesn't have any signature.

Moving to MailNews/Security for the time being to establish whether or not the testcase provided in the original description is valid in this way.
Component: Mail Window Front End → Security
Product: Thunderbird → MailNews Core
QA Contact: front-end → security
Comment on attachment 576705 [details]
(censored) message where we cannot see an attachment

This part is bug 701261, I'm marking the attachment as obsolete to avoid confusion with the originally reported issue.
Attachment #576705 - Attachment is obsolete: true
Yes, the signature is on the pdf file and not on the email, it was intended to be a signed attachment to an unsigned email
Thanks for the clarification.
Summary: attachment is hidden in received email → attachment with individual PKCS7 signature is hidden in received email
MIME type of Application/Pkcs7-mime is defined like next.
> S/MIME specifies the MIME type application/pkcs7-mime (smime-type "enveloped-data")
> for data enveloping (encrypting) where the whole (prepared) MIME entity to be enveloped
> is encrypted and packed into an object which subsequently is inserted into an application/pkcs7-mime MIME entity.

However, following document refers to "render MIME Application/Pkcs7-mime content", "view content embedded in MIME Application/Pkcs7-mime format", and browser/plug-in for it.
This indicates that some applications use mime-type of application/pkcs7-mime for "encrypted/signed data generated by encryption mechanism used in PKCS #7", even though PKCS #7 is "Cryptographic Message Syntax Standard".

If mail data stream in comment #0 is not by bug of mailer/application used by mail sender, and if many applications use application/pkcs7-mime for such data, I think application/pkcs7-mime part is better shown as if attachment when Content-Disposition header is also specified.
In this case, attachment or inline in Content-Disposition: should be ignored, and "filename(and name) is specified or not" shouldn't be used for decision of showing or not showing as attachment(see bug 705431 for current treatment of filename).
Summary: attachment with individual PKCS7 signature is hidden in received email → attachment with individual PKCS7 signature is hidden in received email (subpart of Content-Type:application/pkcs7-mime need to be shown as attachment if Content-Disposion: header is also specified)
"A way to save such part as file" is available from Tb 8.
(1) Tools/Options/Advanced/General, Config Editor,
    mailnews.display.show_all_body_parts_menu = true
(2) View/Message Body As/All Body Parts
You can save any part of multipart mail(or message body of non-multipart mail) as file, and can detach/delete any part in multipart mail including message body part.
Please note that this workaround is not suitable for daily use, because multipart/related is also shown as if multipart/mixed and embed images in HTML is shown separately.
in the cut header part there is 
X-MS-Has-Attach: yes
the sender probably is using msoutlook
same behavior with a different context, now with thunderbird 12.0.1

From - Wed May 09 15:34:02 2012
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
Message-ID: <>
Date: Wed, 09 May 2012 15:33:59 +0200
From: Paolo Devoti <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
Subject: Annotazioni_specifica_TPT2020.xls
Content-Type: multipart/mixed;

This is a multi-part message in MIME format.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Allegato un riepilogo con annotazioni, nuovi parametri TPT e qualche domanda

Cordiali saluti


--- cut cut cut cut cut ---

Content-Type: application/;
Content-Transfer-Encoding: base64
Content-Disposition: attachment;


--- cut cut cut cut cut ---

I am experiencing this bug too, an individually signed attached file with P7M extension is not decoded or shown, and the paperclip is not shown, too.
In the next days I will attach a sample message, the one I have now contains sensible data.
I am attaching an eml file with the following considerations:
I manually modified the message: I created this message with Thunderbird: the attachment is then marked as:
Content-Type: application/octet-stream;
I triggered the bug changing the header in:
Content-Type: application/pkcs7-mime;
With this content type, the attachment is hidden (and, as noted above, reappears in forwarding the message).
The application sending the original failing message was Outlook Express.
Attachment #755352 - Attachment description: This enmail contains a p7m file as attachment not shown on UI → This e-mail contains a p7m file as attachment not shown on UI
I forgot to say that I am using the latest version of Thunderbird, 17.0.6 at the time being.
This e-mail is sent from Outlook Express with an attached signed file (p7m extension) and in Thunderbird the paperclip does not appear.
Still open with TB 24.4.0

It is possible to see the attachment by attempting to forward the email without actually sending it.
But then another strange effect, if you try to open the now visible attachment, the suggested name is "nsmail.p7c" while should be "originalname.pdf.p7m"
This bug is a duplicate of #243833 , that has a solution.
Can someone close this big as a duplicate?
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 243833
You need to log in before you can comment on or make changes to this bug.