Interoperability with IP*Works! Encrypt

[Peperud]

I have an nSoftware subscription at work and it includes an smime/encrypt component. In the context of an upcoming project for "encrypting/signing" files, I tried to see whether files signed/encrypted by nSoftware will be decrypted/verified by MimeKit and vice versa.

It's very possible that this one will be entirely on the nSoftware's side (and I'm going to ping them too) or...well...me, but in the odd chance it isn't, here's the issue:

1. nSoftware always has the content as text/plain; charset="iso-8859-1" and 7bit encoding. This does not sound right (for binary files).
2. MimeKit fails to verify the signature of an nSoftware signed message, when the content came from a binary file. nSoftware does not have this issue.
   Not sure who’s right and who’s wrong here.

Project that shows this
nsoft.zip

Output
files.zip

Trial version of IP*Works! Encrypt can be downloaded here. https://www.nsoftware.com/ipworks/encrypt/download.aspx

[jstedfast]

1. You are correct. Treating binary files as text/plain is invalid.
2. Verification fails in MimeKit because the proper way to verify text is different from verification of binary blobs. For text, the text must be canonicalized into the CRLF form (as opposed to LF which is used by Linux and Mac). To do this, MimeKit makes sure that bare newline characters are replaced with \r\n sequences.

I'm going to close this bug report because of this but that doesn't mean I will not revisit this report if/when you add further updates as you hear back from IP*Works developers.

I would love to interoperate, I just don't know what can be done right now if they are mistagging content because there's no easy way for MimeKit to toggle itself into a "oh, hey, this is from IP*Works so we need to use different verification rules to work around their bugs" mode.

[Peperud]

Just FYI - nSoftware fixed their component. I haven't fully tested it, but my sample test project passes (at least on Windows).

[jstedfast]

Awesome!