We have a small number of users who digitally sign (but don't encrypt) their email. When they send attachments, it usually works fine. However, when the recipient is using Outlook Mobile, all attachments disappear for them leaving behind only the S/MIME p7m file. Is this a known problem, and is there a solution besides not signing the message? What we suspect so far is that the sending client is bundling the other attachments inside the p7m, ignoring the facts that 1) the message is signed but not encrypted, and 2) some clients might not be able to extract them again.
This is not a known problem. Sounds like a configuration issue with the client and/or server. What that configuration error, I could not determine, based on only the information provided. I assume the certificates were installed on the device?
Commented Jun 21, 2018 at 22:09 You state "when using Outlook Mobile" - do you mean on the sending or the receiving end, or both? Commented Jun 22, 2018 at 13:30 On the receiving end. Commented Jun 22, 2018 at 14:44Not sure, if this could be connected, but there is an older known issue with encrypted emails sent from Outlook, but there is also a fix available: Some email clients unable to decrypt email sent from Outlook 2010
Commented Jul 9, 2018 at 11:46Updated answer now includes opaque signatures
The p7m usually is an encrypted email message (including all attachments), but it is required to know the Content-type to definitely know it. If you can see only a p7m attachment in the receiving mail client, this may mean that the mail has been encrypted in whole and the receiving client hasn’t been able to decrypt the S/MIME message.
The reasons can vary, and it‘s hard to say without further details. The most obvious cause would be that the recipient‘s private key ist not available or not associated with the email address configured in the receiving client.
To verify if the message is signed or encrypted, take a look at the raw email message.
In an encrypted email, you will find headers like:
Content-Type: application/pkcs7-mime; name="smime.p7m"; smime-type=enveloped-data Content-Disposition: attachment; filename="smime.p7m" Followed by the encoded encrypted email.
Signed emails, however, can come in two different flavors. Quoted from RFC 8551:
So-called detached signatures are the most common signatures. The mail contents is kept in clear-text, and the signatures is attached to the email. For such a signed email, you should find a Content-type headers like:
Content-Type: multipart/signed; boundary="BC5E686BA36"; protocol="application/pkcs7-signature"; micalg=sha1 And probably near the end of the same message:
Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Followed by the encoded signature. If it‘s only signed, you should be able to see the message text.
However, there are also so-called opaque signatures, which encode the full contents in the signature, so the email does not contain clear-text any more. In this case, you should find these headers:
Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m" Content-Disposition: attachment; filename="smime.p7m" Note that the filename looks like in an encrypted email, but the MIME type is different.
Again quoted from RFC 8551:
Messages signed using the multipart/signed format can always be viewed by the receiver whether or not they have S/MIME software. They can also be viewed whether they are using a MIME-native user agent or they have messages translated by a gateway. In this context, "be viewed" means the ability to process the message essentially as if it were not a signed message, including any other MIME structure the message might have.
Messages signed using the SignedData format cannot be viewed by a recipient unless they have S/MIME facilities. However, the SignedData format protects the message content from being changed by benign intermediate agents. Such agents might do line wrapping or content-transfer encoding changes that would break the signature.
So if you see only p7m-Attachments in the email client, possible causes are
The latter was the case with Outlook Web App (OWA), but I don't know if it still is.