In https://github.com/bbottema/outlook-message-parser/issues/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!
bbottema
commented
10 months ago
In https://github.com/bbottema/outlook-message-parser/issues/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!