Hello,
Using sgn As MapiMessage = New Email.SecureEmailManager().AttachSignature(msg, CmsSigner, New SignatureOptions With {.Detached = True})
sgn.Save(SaveTextBoxX.Text, ASPSaveSetOFT)
End Using
Here source msg can be a Mapi message or Mapi item in Msg, Oft or Tnef format.
The signed sgn will be always message, I mean if source msg is a Mapi item like contact, the signed one is always message.
Can you please be kind and consider this improvement:
If .AttachSignature(msg is MapiMessage, evaluate its message class and return the proper signed message type, if also the return type is MapiMessage 
Thanks.
Hello,
The AttachSignature method can take either a MailMessage object or a MapiMessage object as input. Correspondingly, it returns signed objects of the same type—either MailMessage or MapiMessage.
Therefore, the method already returns the appropriate signed message type based on the input.
If you provide a MapiMessage as the source, the signed output will be a MapiMessage as well.
1 Like
Hello and thanks,
Yes, I mean if we pass a MapiMessage and expect to get back a signed MapiMessage there’s a problem:
It always returns the MapiMessage with message class: Message or IPM.Note.
If we pass a Mapi contact for example, we will get back a IPM.Note message.
I mean the source message class is always disregarded in the resulting signed MapiMessage.
I’ve asked for that improvement to honor the source message class.
Thanks
The Message Class of signed messages is always IPM.Note with the SMIME suffix and cannot be otherwise. S/MIME encryption is generally not applied to Outlook items; it is typically used only for emails.
1 Like
Not so sure, check this sample:
Sharing request_ People.zip (845.4 KB)
However, some message classes like Exception Recurrencev : IPM.OLE.CLASS is still not supported, so no idea what happens there.
Not so sure, check this sample:
Sharing request_ People.zip (845.4 KB)
However, some message classes like Exception Recurrence : IPM.OLE.CLASS is still not supported, so no idea what happens there.
I mean Smime signing and not encryption.
SecureEmailManager().AttachSignature signs or encrypts?
Thanks
Ok, we’ll take a look and respond later.
1 Like
Hello,
Searching my storages, I’ve found other signed items too, seems that many message classes support Smime signing, perhaps encrypting too, so it seems very wise that when signing a MapiMessage, just pass the original MessageClass to the target message with the trailing smime extension, based on Clear/Opaque signature (attached/detached) :: SMIME.MultipartSigned or SMIME.
How’s that?
Thanks for consideration
Hello,
Could you please provide evidence or examples showing that other message classes can have signed counterparts? Without clear confirmation, we won’t be able to add support for additional SMIME classes.
Currently, we are only aware of the following SMIME classes:
IPM.Sharing.SMIME.MultipartSignedIPM.Note.SMIME.MultipartSigned
1 Like
Hello,
2 more items, I will send more
ITEMS.zip (47.9 KB)
Thank you for the examples.
That’s unusual that you have an MSG file with the class IPM.Contact.SMIME. Could you let us know how you obtained it?
As we known there is no specific message class named IPM.Contact.SMIME in the standard messaging classes.
In Outlook and Exchange, SMIME is commonly used for secure email messages.
If you need to associate SMIME with contacts, you would typically do so in the context of storing certificates or encryption information within a contact, not by changing the message class to IPM.Contact.SMIME.
1 Like
Hello,
I just extracted all items containing MessageClass SMIME from my sample storages!
I don’t remember how this item was made, but unless I’m greatly mistaken, I didn’t change its message class.
Let me ask an MVP about it and will get back
Thank you. Please let us know what you find out after checking with the MVP.
1 Like
Hello,
ok, thanks. We will look into it.