Hello,
FYI:
Dim MyMapiMessage As MapiMessage = MapiMessage.Load(str, loadopt)
MyMapiMessage.Headers.Set("X-Mailer"...
Dim SignedMessage As MapiMessage = New Email.SecureEmailManager().AttachSignature(MyMapiMessage, MyCertSigner, MySignOptions)
SignedMessage.Save(out, saveopt)
source msg:
IPM.Task
3 Categories:
Red Category
Green Category
Blue Category
Flag Request:
No Response Necessary / Not Completed
Flag Date:
12/9/2024 12:00:00 AM
resulting destination msg:
IPM.Note.SMIME.MultipartSigned
0 Categories: all lost!
Flag Request: removed!
Flag Date: removed
another one was:
IPM.Schedule.Meeting.Request > IPM.Note.SMIME.MultipartSigned
source:
3 flags:
MSGFLAG_READ
MSGFLAG_NOTIFYREAD
MSGFLAG_NOTIFYUNREAD
target:
2 flags:
MSGFLAG_READ
MSGFLAG_HASATTACH
source has a collection of 5 timestamps:
AS8P193MB1879.EURP193.PROD.OUTLOOK.COM ([fe80::ae6e:b9:aa98:e197])
AS8P193MB1879.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:3fd::14)
EUR01-VE1-obe.outbound.protection.outlook.com (40.92.66.81)
BN8NAM04FT057.eop-NAM04.prod.protection.outlook.com (2603:10b6:408:111:cafe::93)
BN9PR03CA0398.namprd03.prod.outlook.com (2603:10b6:408:111::13)
target has only one:
BN9PR03CA0398.namprd03.prod.outlook.com (2603:10b6:408:111::13)
compared some more messages before/after sign, and seems most of the times many properties of the messages are lost/changed that has no relation with the signature (beside ipm.class that is expected)
Thanks.
@australian.dev.nerds
Thank you for reporting this issue in detail.
It appears that when using SecureEmailManager.AttachSignature, several message properties—such as categories, flag request status, flag date, message flags, and received timestamps—are being lost or altered during the signing process. Additionally, the message class is being changed from IPM.Task or IPM.Schedule.Meeting.Request to IPM.Note.SMIME.MultipartSigned, which is expected for S/MIME signing, but the loss of metadata is not.
A similar behavior was previously observed with IPM.Note.SMIME.MultipartSigned messages during conversion processes, and an issue has been logged as EMAILJAVA-35031 related to improper handling of message properties in such cases . While this specific ticket references Java and EML conversion, the underlying problem of metadata loss during S/MIME operations aligns with your observations.
Additionally, there are known workarounds involving signature removal before saving , but these do not resolve the core issue of property retention during signing—only after verification or conversion. This suggests that the current S/MIME signing implementation in Aspose.Email may not fully preserve MAPI-level properties during message restructuring.
At this stage, the unintended stripping of categories, flags, and tracking data during signing appears to be a limitation or bug in the AttachSignature method when processing non-standard message classes like IPM.Task or meeting requests.
We will log your report to ensure it is linked with related investigations, including EMAILJAVA-35031, to improve property preservation during S/MIME operations.
In the meantime:
- If possible, reapply critical MAPI properties (e.g., categories, flag data) after signing but before saving.
- Avoid relying on original message flags or headers post-signing until this is resolved.
We’ll update this thread if a fix becomes available.
@australian.dev.nerds
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): EMAILNET-41692
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
Hi @australian.dev.nerds
S/MIME in Microsoft Outlook is strictly a mail-only, transport-level feature.
Outlook does not support S/MIME signing of Tasks, Appointments, or Meeting items.Only mail messages (IPM.Note) can be digitally signed.
When S/MIME is applied to a MIME message that originates from a non-mail entity (for example, when this is done programmatically), the result is always a signed mail item of class IPM.Note.SMIME.MultipartSigned.
Outlook-specific properties such as Categories, follow-up flags, notification flags, and task/meeting semantics have no representation in signed MIME mail, and therefore cannot be preserved.
This behavior is expected and is caused by how S/MIME works in Outlook and in general.