You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In bbottema/outlook-message-parser#40, we've encountered scenarios where signed messages are stored in a non-standard configuration by Outlook. Specifically, Outlook may store a signed message as a .p7m attachment with a Content-Type of "multipart/signed", but then omit the essential protocol parameter. This omission complicates the identification process, as the lack of a protocol parameter leaves us uncertain whether the content was signed using S/MIME or something else, or if it was both signed and encrypted.
To address this, the library should be updated to return a 'maybe signed' status. This change will allow users of the library to attempt to unwrap the content, with the understanding that they should continue processing if unwrapping fails. This approach inherently means we cannot definitively distinguish between invalid signatures and content that is not actually signed. However, it's a necessary compromise to handle such cases, especially considering that these messages are most likely properly signed but simply missing the protocol parameter. A special thanks to Outlook for this unique challenge!
The text was updated successfully, but these errors were encountered:
In bbottema/outlook-message-parser#40, we've encountered scenarios where signed messages are stored in a non-standard configuration by Outlook. Specifically, Outlook may store a signed message as a .p7m attachment with a Content-Type of "multipart/signed", but then omit the essential protocol parameter. This omission complicates the identification process, as the lack of a protocol parameter leaves us uncertain whether the content was signed using S/MIME or something else, or if it was both signed and encrypted.
To address this, the library should be updated to return a 'maybe signed' status. This change will allow users of the library to attempt to unwrap the content, with the understanding that they should continue processing if unwrapping fails. This approach inherently means we cannot definitively distinguish between invalid signatures and content that is not actually signed. However, it's a necessary compromise to handle such cases, especially considering that these messages are most likely properly signed but simply missing the protocol parameter. A special thanks to Outlook for this unique challenge!
The text was updated successfully, but these errors were encountered: