My understanding is that the difference between "Encrypt & Deliver Now" vs. "Encrypt on Delivery" is that former encrypts and sends the message immediately whereas the latter continues with the message processing and encrypts the message later prior to send.
What are some of the pratical examples for processing that can happen in the message pipeline which may require "Enc on Delivery"? What is the best pratice and the guidance for selecting the right option?
If I misconfigure and set the "Enc & Deliver Now" when some processing is short circuited, would IronPort detect the condition and notify the admin via logging or other methods?
your explanation is correct, a common scenario for both of this cases would be an outbound setup that uses DLP and filters. In this setup, senders could actively flag their messages to be encrypted, i.e. using the secure plugin to add a header, or to put "Encrypt" in the subject. Now we have two possible cases, or requirements:
- All sensitive data must be encrypted
- Sensitive data leaving the company reqires further inspection or approval
In the first case, any message flagged for encryption won't need further inspection, and the message may just go directly to the delivery queue. This saves resources that DLP would need to scan the message, which is not really nessesary. Yet still DLP would take care of any sensitve date if the user "forgets" to flag it appropriatiely
The second case would be something where certain content may not leave the company at all, so we still want DLP to check on that, and delete or bounce the message. Also for anything where the message is sent to a quarantine (Filter, DLP), depending on the action on the quarantine, the message will be either delayed, or will be encrypted when released from the quarantine.
Of course, in many cases there may be a combined setup of both kind of filter actions, applied to different policies, where the action is depending on the sender or recipient. Regarding your last question about possible misconfiguration, if I understand you correctly if there is a warning in the logs when a filter action flags a message to bypasssome further processing. There is no such thing by default, so you would add a "Log Entry" to the filter if you want to have the action documented in the logs.