[EMSX] Improving Quarantine / Tagging options?

[Mike 8]

Hi,

I have been frustrated by the limited options for dealing with Spam in Eset Mail Security for Exchange for a long time.

(I outlined my frustrations a couple of years ago in this thread).

 

The summary of my frustration is that ESET Mail Security allows us to define really accurately levels for Spam, Probably Spam, Probably Clean, and Clean with a granularity of 1 to 99 scoring. However the Quarantine/Deleting/Tagging module is very crude in only allowing us to deal with only the "Spam" category defined above - the others being ignored! This seems daft to me....

 

The suggested work-around is to use ESET to write to the SCL, and then filter and quarantine in Exchange Transport. This is not very useful, because the high granularity that ESET provides in 1 to 99 scoring, is reduced to a crude 1 to 9. In our case, most spams arrive in the 9 category (including some false positives), so no chance to divide between them intelligently and therefore I might as well use ESET Quarantine for finer adjustment.

 

This is where I have got to in the past on this subject, and I had accordingly left ESET doing the Quarantining for me, and suffered the one hit nature of the Quarantining action as being better than the crude SCL alternative because of the ability to trigger at 92 (for example) rather than a simple SCL=9.

 

However, ideally I'd be able to trigger a range of different actions to happen at different levels (like available in Exchange), but to use the ESET 1 to 99 range instead of the crude SCL that the Exchange route demands. (ie Delete at one score, Quarantine at a different score, Tag at yet another score etc).

 

I think I might have stumbled across a potential fix for this, but it is still at the ideas stage.... so I wanted to bounce it off a few more knowledgeable heads before I do a test run (and risk upsetting my users!)

 

The idea came from my solution to solve the blank sender spam problems as discussed here. Because these Exchange Transport Rules can use the headers, they can be triggered by any text match, I was wondering if I could set up some rules to trigger some more granular processing. They can potentially respond to the "X-ESET-AS: SCORE=99" type line in the header.

 

However, whilst I feel like it is probably possible to achieve what I want, I don't want to create a separate rule for each spam score number to be actioned, i.e. one rule for 99, one rule for 98, one rule for 97 etc etc.

 

Ideally I want to split out my own higher category of "Blatant Spam" as I define it (probably just 99 for now), and quarantine these in a separate quarantine location that needs less thorough checking - but maybe ultimately delete/reject these outright if the rules works well with no false positives.

 

Then I would Quarantine say 93 - 98 and keep for easy checking by an admin.

 

I would then deliver but tagged as [spam], maybe scores of 88 - 92 (so the user sees and deals with these)

 

Below that I might deliver untagged, or possibly have a [spam?] tag for another range.

 

 

Any ideas if what I am hoping for might be achievable using transport rules?

 

Mike

 

 

[WilliamT 21]

Hello Mike,

 

I just wanted to let you know we have seen your post and we are looking into the rules you want to create. I also wanted to let you know that the blank sender issue has been resolved in our latest version of ESET Security for Microsoft Exchange (4.5.10015). This was released yesterday and can be downloaded here. We will be testing these ideas and should be able to give you an answer early next week.

[Mike 8]

Awesome! It always struck me as a little bit odd that ESET went to the trouble of defining all the categories of spam, probably spam, probably clean, and clean, BUT then to only allow treatment and tagging of the SPAM category. If there is a way to allow treatment at all those the different levels, that would be great.

 

If you want to talk it through some more, then feel free to get in touch.

 

I'll look into the 4.5.10015 update as have a proper solution to the BLANK SENDER issue will be great!

 

Thanks

 

Mike

[Mike 8]

WilliamT,

 

Is there any news on these more flexible processing rules? Has anyone managed to look into this yet?

 

I'm more than happy to talk to someone if they need more info.

 

Thanks

 

Mike