Skip to content

[Enhancement] Handle Outlook's Non-Standard S/MIME Signed Messages #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bbottema opened this issue Dec 15, 2023 · 1 comment
Closed

Comments

@bbottema
Copy link
Member

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!

bbottema added a commit that referenced this issue Dec 15, 2023
…ges, as the content-type is "multipart/signed", but the (S/MIME) protocol parameter is missing.
@bbottema
Copy link
Member Author

Released in 2.2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant