01-09-2011 10:41 AM
I have setup an encryption content filter on my appiance to encrypt messages that are outbound, and have a subject header that begin with the keyword Secure inside brackets. [Secure]. My intent was to eliminate some fals positives by including the brackets. What ended up happening was for some reason ALL outbound messages were being encrypted.
After some more testing it seems like the content filter is ignoring the brackets as a requirement, but I can seem to find anything in the online help to back this up.
Can someone assist with verification of the requirements around using a keywork in the subject to allow users to encrypt oubound messages voluntarily?
Best practices around achieving this if anyone has them would also be greatly appreciated.
Thanks,
Chris
Solved! Go to Solution.
01-09-2011 11:14 AM
Hi Chris,
While I would have to see the syntax of the filter in question to be 100% sure , it sounds as if your conditional variable is being treated literally. The content filters will except regular expressions so what this means is something like [Secure] could be seen as look for anything that contains
an S, or a
e or a
c or a
u or a
r or a
e
Since you said begins with we would be looking for anything in the subject that begins with of of these letters. This is due to the fact that the brackets [ ] are special characters in regular expressions, thus they need to be escaped. That being said [Secure] would become \\[Secure\\], we use the \\ to escape the brackets. In content filters however, you can get by with using just one escape as the filter is smart enough to go ahead an enter the additional escape for you. So in the filter it would be something like begins with \[Secure\]
Once you enter this in the condition for you filter it will display like the following,
subject == "^\\[Secure\\]"
I hope that helps.
Christopher C Smith
CSE
Cisco IronPort Customer Support
01-09-2011 11:14 AM
Hi Chris,
While I would have to see the syntax of the filter in question to be 100% sure , it sounds as if your conditional variable is being treated literally. The content filters will except regular expressions so what this means is something like [Secure] could be seen as look for anything that contains
an S, or a
e or a
c or a
u or a
r or a
e
Since you said begins with we would be looking for anything in the subject that begins with of of these letters. This is due to the fact that the brackets [ ] are special characters in regular expressions, thus they need to be escaped. That being said [Secure] would become \\[Secure\\], we use the \\ to escape the brackets. In content filters however, you can get by with using just one escape as the filter is smart enough to go ahead an enter the additional escape for you. So in the filter it would be something like begins with \[Secure\]
Once you enter this in the condition for you filter it will display like the following,
subject == "^\\[Secure\\]"
I hope that helps.
Christopher C Smith
CSE
Cisco IronPort Customer Support
01-10-2011 05:58 AM
Christopher,
Thanks for the quick response and detailed explanation. Your explanation has seemed to have helped me resolve the issue and I will be testing it thoroughly throught the day.
Two questions I do have though are,
1. Did I miss this somewhere in the online documentation?
2. Does this hold true for using brackets in ALL regular expression fields or only in this instance on the IronPort appliance?
Thanks again for the help!
Chris
01-10-2011 06:24 AM
Nevermind, I found the answer to both of my questions.
1. Online help in the configuration guide I found the section, "Regular Expressions for Content Matching Classifiers"
2. The style of regular expressions used for content matching is the POSIX Basic Regular Expression style.
Chris
01-10-2011 11:49 AM
Great discussion. One of the issues that we have discovered with using [Send Secure] for encryp
ting e-mails is that users will miss type this information. Yes, we have deployed the plug in to type in the information for the users but some are still going to attempt to type it in manually, and get it wrong. I've seen (send secure), {send secure}, and [secure send] all used. I haven't setup filters to bounce these e-mails back as of yet but just thought I would mention it as something to think about on the Engineering side of things.
As a side note, our organization is starting to make a committment to BPOS --> Office 365 and currently their encryption solution doesn't touch the IronPort IEA solution, but they are gaining.
Jason
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide