cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Cisco Secure Email Support Community

Product Support Talos Support Cisco Support Reference + Current Release
Gateway Reputation Lookup Open a support case Secure Email Guided Setup
Gateway: 14.0.0-698
Cloud Gateway Email Status Portal Support & Downloads docs.ces.cisco.com
Email and Web Manager: 14.0.0-404
Email and Web Manager Web & Email Reputation Worldwide Contacts Product Naming Quick Reference
Reporting Plug-in: 1.1.0.136
Encryption Bug Search
Encryption Plug-in: 1.2.1.167
Cloud Mailbox Notification Service
Outlook Add-in(s): More info

1011
Views
0
Helpful
2
Replies
johnsmith1000
Beginner

Encryption Content Filter: Enc & Deliver Now vs. Enc on Delivery

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?

Thanks.

2 REPLIES 2
Andreas Mueller
Enthusiast

Hello John,

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

or

- 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.

Hope that helps,

Andreas

Thanks Andreas for your comprehensive response. Yes, you answered my last question too

Content for Community-Ad