I understand and support the automatic encryption of our outbound emails. In an attempt to possibly make it better, is there any method using our existing C160 email security appliance that can warn the sender that a message will be automatically encrypted prior to it going out? Doing so could allow the user to choose to have it encrypted or not. We have a subject tag "!m" that the user can type to force unsecured... but many times they have to do this after the fact they get an email from the C160 saying that the email was encrypted.
Ok. Well a few years ago we tried the Outlook plugin but we would occasionally get crashes. It would be very cryptic error messages like "Offset at (random hex address) (OK)".
Now again that was a few years ago so maybe things have changed.
Would this work on Outlook 2013? While the majority of users are 2010, there have been a few 2013 installs going out as we cannot get PC's with 2010 anymore.
I guess next thing is, I'll search the site to try to find this plugin and test it. The biggest complaint our employees have is when the IronPort just encrypts a message without warning. We do have it programmed to reply to the sender with which policy it hit on. Many times its Policy Name: abanumbers even if there are no ABA numbers (could just be a string of numbers in a file attachment for example). I guess if we use the plugin instead we would turn off all auto encryption options and then let the Outlook plugin / user decide?
Look, I don't even know why aba numbers should be encrypted. They are public information. Go to just about any financial institutions website and at some place they publicly state their ABA number.
Click here for the Plug-in downloads. You will need a CCO login to access the downloads.
As for the complaint against "encrypts a message without warning" --- that just really starts to get into end-user education of what is active in the environment. If you have DLP in play on the appliance, and one of the set defined policy is Privacy Protection -> ABA Routing Numbers, then the appliance is only doing it's job, as you have configured. If the end-users should be sending through a relay/outbound mail flow policy, and you don't want that group/end-users to be susceptible to the DLP scanning, you'll need to configure them into an outgoing mail policy that doesn't have DLP enabled... or, has DLP enabled but not ABA Routing Numbers.
Using the plug-in and allowing the end-users to decide if they want to encrypt/not encrypt is only going to be the initial reaction of that end-user. With the plug-in, you may be removing the need to use the subject line encryption flag in order to provoke encryption, but any/all mail from that end-user through the ESA will still be susceptible to the configuration and encryption actions set.
You should leave the subject line trigger in place (either via message filter or content filter) - but, be sure to re-educate the end-users that may be using the plug-in to fully understand the right/wrong as you intend encryption to be handled.
Today the thing is that a user could send a harmless email. Then they get a message back from the Ironport saying "your message was encrypted due to this policy: (policy name)." Under that it explains each policy name and what they do. So now frustrated beyond belief, the user has to go back in their Sent Items folder and forward the message back to the recipient and put a subject tag !m: in the front (eliminating the Outlook created FW:). Each encryption policy has an "out"... basically if !m: is in the front of the subject, it stops processing that encryption policy. Henceforth the second email with the proper subject tag overrides the encryption and the end user is happy again.
I see that the plugin has an encrypt message button (it's grayed out on me, but I didn't go through all the complex configuration steps yet). It would also be nice if there was an Override Encryption toggle below Encrypt Message, so the end user could be 100% certain the message going out will not be encrypted.
Were not sure why but most recipients have a hard time with opening encrypted emails. ESPECIALLY vendors. They usually come back with "I can't open that attachment" or "I don't have a password". So just to get work done we resend it with the override tag. Sometimes I'm not sure why technical vendors can't read the simple instructions how to create a CRES account. Or I don't know if some people think a CRES account is different for each organization using it. It's just a clunky solution for many end users, especially those with generic mailboxes like firstname.lastname@example.org.
So an override is nice - OR out of the box we encrypt nothing unless the end user clicks that button. That itself would be a discussion for the higher ups of the company.
Thanks, I went through that got the file signed, renamed it to config_1.xml added the accountfilenames filepath=config_1.xml in the CommonEncryptionConfig.xml and reinstalled it using this command line:
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...