With per-message S/MIME enabled, the default action when replying to an encrypted message is to send that reply unencrypted. Causes users to accidentally send originally encrypted content, back unencrypted.

Question

This seems counter-intuitive, are we doing something wrong or is this working as expected?
When we have per-message S/MIME enabled on an iOS 8 device.  Everything works as expected and we have the ability to select when you are sending an email whether that email should be encrypted or not, but i've noticed that, when you receive an email encrypted with your S/MIME cert, read that email on your iOS8 device with per-message S/MIME enabled, and reply to, or forward, that message, the default action is to send that reply, or forward, unencrypted UNLESS you manually re-tap the little padlock button to re-encrypt the message.
This seems broken.  I would imagine we would want the default action when replying or forwarding that encrypted message to be an encrypted reply or forward so as to keep the encryption intact.  I can't think of a time when you would actually want to send an unencrypted reply to an encrypted message, as doing so would send the originally encrypted content back, as unencrypted text therefore negating the point of ever encrypting it in the first place.
I know we can set the iOS device to by default send ALL email as encrypted, but that's overkill.  Our users probably only get 1 or 2 encrypted emails a week, but when they do get those encrypted email we would want their replies and forwards to those email to also remain encrypted, and not open up the chance of one of these users forgetting to re-check the padlock button thus accidentally sending the originally encrypted content, out as an unencrypted message.
Is this working as expected or are we doing something wrong?

Answer 1

Hi,
Thank you for your clarification.
Yes, it seems you have installed all the updates for the Outlook.
“Testing on a good computer” is a method to narrow down whether the cause is related a specific computer.
For debugging tool, I think we can take a look at:
1. RPCTrace log
2. Process Monitor
For RPCTrace log, it’s not that easy to capture. You must firstly replace some Outlook dll files before you can capture the log. Even more, the dll files can vary if the Outlook
SP versions are different. So, It’s recommend to contact a Microsoft Support to capture and analyze the trace log.
Thanks,
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact
[email protected]
Simon Wu
TechNet Community Support