Missing signed-data property when saving opaque signed email

Aspose.Email Product Family
1

Hi,
Please just test the sample to load op.msg and save it as 2.eml
The result 2.eml made by Aspose is missing a vital property: signed-data

Look for this line:
Content-Type: application/pkcs7-mime; name=“smime.p7m”

It must be:
Content-Type: application/pkcs7-mime; smime-type=“signed-data”; name=“smime.p7m”

Although Outlook or Windows Live Mail will open the 2.eml, but most SDKs and other apps will not.
CryptographicException is expected when reading 2.eml.

WindowsApplication1.zip (3.9 MB)

2

Although smime-type can be helpful, it is not always strictly necessary. Many modern email clients can identify the message type using other elements of the MIME header, such as protocol="application/pkcs7-signature" and the presence of signed data within the content. In most contemporary cases, smime-type can be left out, as email clients can accurately interpret signed messages without this parameter. You might be referring to older email applications. Can you provide examples of other applications that are unable to open 2.eml?

1 Like
3

Hello

Try this .msg with my above sample project and the result made by Aspose will have the smime-type:

ok.zip (18.2 KB)

I mean why in some conditions it will be present and, in some conditions, will not? That’s why I’ve asked if there’s some property for that in .msg. Anyway, since you add it in some cases, why not simply adding it always to make sure the result emails are all clients proof? Worth to consider?

Currently is there any workaround to force the generation of smime-type for opaque signed and encrypted emails?
Thanks :slight_smile:

4

And when signing the already signed emails, the result will be invalid/altered signatures.
Should this be fixed or checked internally? :slight_smile:

5

Hello,

The MSG object must have a named property “Content-Type,” which contains an ASCII string value of the Content-Type header field. When converting to EML, we use the value of this property as the Content-Type. In the file ok.msg, this property is present. However, in the file op.msg, this named property is missing, so during the conversion to EML, a Content-Type is generated with the minimally acceptable value.

1 Like
6

Hello and thanks for the tip,
What’s the name of that Pid? PidNameContentClass? And how do you inspect it? Using CFBBrowser I can’t check those properties.

And finally, may I request an enhancement to include the signed-data property when converting/saving? It’s totally harmless and also can be useful to prevent such errors.

Or at least include an option to force that signed-data property?
Thanks for your kind consideration.

7

Hello,
we will respond to you tomorrow, on Monday.

1 Like
8

This property is PidNameContentType.

You can also view it using CFFBrowser, as shown in the screenshot 1.png (53.7 KB).

To check it, you can use the following code:

Dim msg As MapiMessage = MapiMessage.Load("ok.msg")
For Each namedProperty As MapiNamedProperty In msg.NamedProperties.Values
    If String.Equals(namedProperty.NameId, "Content-Type", StringComparison.OrdinalIgnoreCase) Then
        Dim contentType As String = namedProperty.GetString()
    End If
Next

Additionally, I have created a ticket for your request to add smime-type="signed-data": EMAILNET-41411

1 Like