We are using SMIME certificates to sign and encrypt out emails.
Encrypted emails are working normally... As are non-encrypted emails to recipients who we do not have a key for.
The desktop Outlook app also successfully intercepts attempts to send an encrypted email to a recipient without a public key... Most of the time... Successfully.
The edge case scenario where this appears to fails is as follows.
- By default, all emails and replies we author start out as encrypted and signed.
- To email a recipient without an SMIME key we need to untick/unselect the encrypted button.
- If we happen to CTRL + S, or allow the draft to auto save at 3 minutes before unticking encrypted... The email is saved to the drafts folder as message class "IPM.Note.SMIME".
- If we then try to send as encrypted, Outlook will correctly warn us that we are missing key infromation and direct us to send as unencrypted.
- So we deselect the encryption button and send the email.
- The result of this workflow is that neither the sender, not recipient, of this email is able to open the email. Attempts to open the email result in various messages about a missing digital ID.
- Opening the .msg file in notepad allows us to see the plain text components of the email. So its clear that the message is not a properly encrypted file as this shouldnt be possible.
Attempts to resave a "IPM.Note.SMIME" affected draft as a "IPM.Note" message by unselecting encryption and CTRL + S result in no change to the message class.
However the reverse of this does work. It is possible to convert an existing draft "IPM.Note" to "IPM.Note.SMIME" by selecting encryption and then resaving the email. The message class is automatically updated as you would expect.
If we get in before step 3 and unselect encryption and save it as a draft, as "IPM.Note", then the issue is averted. The email will send to the nonencrypted recipient without complication.
At no point does Outlook:
- Attempt to warn the user that the email being sent to a non-encrypted (missing key) recipient is broken, malformed, or in any kind of error state. The email goes out as normal.
- Attempt to convert the IPM.Note.SMIME object into one of IPM.Note prior to sending.
- Attempt to recreate and copy the content from the potentially faulty email object into a fresh new working object prior to sending.
- Any other actions to prevent this situation occurring.
The result of this is that a user will send emails into a virtual black hole and the only time they become aware of this failure is when the recipient eventually replies to inform them that they received some kind of broken email.
The sender is then left to wonder, what on earth it was that they had sent and subsequently attempt to reauthor a whole new email. For longer and more complex correspondance this can be a right pain. Whilst yes I did eventually discover that the sent item is readable in note pad... This is sans all formatting and proper white spacing used. End of lines are in the wrong places and so the author will have to spend significant time correcting the formatting prior to resending.
I raised this with O365 support who seemed to consider this situation "A OKAY!" and that Outlook was working as designed and that this was the users fault for creating this situation. They claimed to not have any communication channels available to them to escalate a formal bug report and advised me to simply supply feedback through the built in feedback menu within the help menu in Outlook itself.
As I have come to expect, the support I get for every single ticket I raise to MS leaves me disappointed, angry and frustrated at how useless the support teams are. Virtually every single ticket I raise, with multiple different support teams, ends up a disappointing mess. I am truly shocked that a helpdesk would not have a communication channel to formally report bugs. But instead all I was directed to do was drop my "feedback" into what I can only assume is a black hole where the issue will never see the light of day.
I did do this, out of desperation, but I truly dont expect anything to come of it.
I have also looked at ways to try to alert my users that they might have borked something up with mailbox rules etc. But I cant seem to find anything that would help prevent the issue from occurring.
Nothing short of us making a custom plugin that would intercept all outbox emails, validate them, and then send them.
If anyone else has experience with this issue, and has suggestions on how to manage it?
Or alternatively contacts at MS that may actually be helpful?
