Ironport Tuning

[corey.burden]

Does anyone know of a way to tune the Ironports so that the content and language filter does not quarantine legitimate emails because a word may contain part of a word that is to be filter.  IE, the word  "classified" causes emails to be quarantined because of the 3-5 characters.  I checked the box to match whole words and that helped a bit but we are still having that issue.

[Mathew Huynh]

Hey Corey,

Match whole words should correct most of the mis-matched behaviour unless someone is actually sending out profanity words like 'ass' within the email somewhere causing the match.

Else you can attempt to add boundaries to the terms as well with \b 

However generally it should not match an email where you have the word as classified when the Match whole words is enabled.

I would also suggest to add an extra action of -> Add Log Entry -> $MatchedContent

Just so you know what word matched and to skim the email for the actual word.

Weighting may also need to be implement to stop a very strict or some false positive matches.

Regards,

Matthew

[exMSW4319]

Regular expressions are relatively expensive in terms of CPU, but if you really have to go for short phrases that are false-positive city then ^ass$ will do. It won't catch ass-qualifier but just going for ^ass will still give you lots of false positives. You might have more luck including some of the more common or offensive qualifiers as separate phrases, as a clutch of phrases is cheaper than a regular expression.

As Matthew says, dropping the weighting is probably the first step unless you're filtering for a church congregation.

On the subject of weighting I still prefer the way certain other gateway products work, counting a phrase once no matter how many further times it appeared in the message. This was far better at avoiding false positives, and I use weighting much less now than then.

[corey.burden]

Thanks for the information. It appears most of everything is being caught by the Match Whole Words.  But I have these for example that didn't:  an ip address with 38.xxx as the last 2 octects or an attachment with scripts that has file\xxx in it. Do you think that the ^xxx$ script will not recognize these as false positives?

[Mathew Huynh · Accepted solution]

Hey Corey,

file\xxx or 38.xxx will not be caught under ^xxx$ type of regex filter.

Also it will depend on the filter condition as well.

For any dictionary, or body/string matching I always suggest to add the "Add Log Entry" action with $MatchedContent for ease of auditing as well so you can see in the mail_logs/tracking logs what string was triggered.

Regards,

Matthew

[corey.burden]

Thanks for you help guys.  It seems like things have slowed down for all of the false positives now.   I'm down to only a hand full of emails being quarantined per day now vice several hundred.  And they mostly seem to be legitimate catches with the exception of one or two.