cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2048
Views
0
Helpful
4
Replies

Best practice using keyword in subject for encryption

chmeehan0421
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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  

View solution in original post

4 Replies 4

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  

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

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

Jason Meyer
Level 1
Level 1

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