[EMSX] - Blank Sender Spam emails escaping Quarantine in Exchange (Solution!)

[Mike 8]

We have been having the most annoying spam problem for the last week with "Eset Mail Security for Exchange" (EMSX from here onwards) and Exchange 2007 (on an SBS2008 server).

The spams started last Friday, and are typified by having a "Return-Path" in the header as: "<>".

EMSX correctly identifies all these emails as spam, and says it has shifted them to the Quarantine as we have configured it to do. However the offending emails with a blank return path sender are actually being delivered to the end user's mailboxes instead of the quarantine!

I spent several days faffing with various of my own fix attempts, before finally reporting it to Eset NZ (Chilisoft). Eset were aware of the problem, and had been attempting various fixes themselves for another site.

In the end ESET's devs have discovered it was an Exchange problem, where Exchange was stopping ESET or itself from writing anything to the headers of the emails. Their offered work-around today was:

You can use the following workarounds for the time being (use one or the other):

1) Configure EMSX to delete spam instead of quarantining it. This works correctly but there is a risk of deleting a valid message.

2) Enable Sender Filtering and "Block messages that don't have sender information". This is an Exchange option (see here: hxxp://technet.microsoft.com/en-us/library/bb125179(v=exchg.141).aspx)

Since we get too many false positives to make me happy to use the first suggestion, that only left the second.

I tried creating the Sender Filtering for an email address called "<>" and set it to "Stamp Message as Blocked Sender" (since I also wasn't keen to reject these messages without knowing what effect it would have). However, it soon became apparent that this wasn't working, presumably because Exchange isn't writing to the headers, so of course it doesn't write the Blocked Sender message on the message. DOH! Should have realised that would be the case!

Since ESET narrowed down the problem and issued their work-around earlier today, I've tried various other fixes in an attempt to find one that is acceptable for my environment until a long term fix can be put in place. I finally cracked it tonight with the following "Transport Rule" in Exchange.

This method is flexible and powerful enough to allow you to process these spams in pretty much any way that suits you and is totally safe too!

• Open “Exchange Management Console”

  .

• Go to: Organization Configuration > Hub Transport > Transport Rules

  .

• Choose create a new Rule.

  .

• Give it a name: I chose “Blank Sender Spam Filter Rule”

  .

• Give it a helpfully descriptive comment to remind you what the rule is for in future. I chose:

  “Spam Processing rule for Blank Sender in the "Return Path" (displays as "<>") with SCL above 7 (to let OutOfOffice messages through untouched). This rule is created to overcome a problem where spam with no return path gets corrected detected and marked as being sent to Quarantine, however the mail actually passes through to the mailbox untouched, and not marked as spam or removed. This is an Exchange Problem, but it also affects "Eset Mail Security for Exchange", since Exchange2007 blocks writing to the headers of these emails.”

  .

• The most important bit is on the “Conditions” page, you tick:
  • “When a message Header contains specific words”. Then click the underlined “message header” at the bottom and type “Return-Path” and click the underlined “Specific Words” and type “<>” (both without the speech marks).
  • “When a Spam Confidence Level (SCL) rating is greater or equal to a limit”. At the bottom choose something like 7 or 8 for this limit. This will hopefully allow Out Of Office replies from external sources (which also often have an empty Return Path) to pass through to the intended recipient untouched by this rule. Before I added this extra condition, OoO replies were being quarantined too.
  

  figure 1 : screen grab summary of the “conditions” page

  .

• For the Actions page you can choose your own actions as suits your needs. I have chosen for now to tick:
  • “log an event with message” so I can track how often the rule is being triggered, it also helps with testing.
  • “prepend the subject with string“ to add a distinctive spam label so I know where the message is coming from. I chose: [spam-TransportRule]
  • “redirect the message to addresses” and send it to your quarantine mailbox address for monitoring.
  

  figure 2 : screen grab summary of the “actions” page.

  .

• When you know the rule is working safely to your liking and not capturing any false positives, you could choose to delete or reject the message on this action page instead of redirecting and labelling as spam.

  .

Hopefully this simple Transport Rule creation wizard will help others to be rid of this Blank Sender spam until a more permanent fix can be found by ESET or Microsoft, and will save a few of you some hair-pulling frustration!

Hope this helps a few other people...

Mike

Edited May 17, 2013 by Mike

[Guest Jon Gibbins]

Hi there

 

Just to confirm, this has worked for us. We didn't want to enable the Exchange Antispam as we've had issues with it in the past with it.

All works exactly as expected without the need for Exchange Antispam and does not interfere with read or delivery receipts like some other methods did.

 

Many thanks!

[C4JG 0]

Tried, tested, approved!

Thank you!

[Guest Sebastiaan]

Thanks, works great!

[Mike 8]

Glad this has helped others too.

Just to report back, that I've had mails slipping through with a SCL of 3 which seems pretty low to me. Of course the ESET scoring isn't available since it can't write to the headers, so we'll have to live with that.

Fortunately most "Out Of Office" messages appear to have a confidence level of "-1" so it would appear we can set this rule down that low without causing any OoO messages to be lost.

I'll be testing that new low value from today. Other than this most recent spam that slipped through, the rule has been owrking perfectly for me.

Mike

[Mike 8]

I'm getting some of them with a SCL of 1 now. That seems ridiculous! Looks like my rule is now picking up some genuine delivery failure messages too, which is a pain as the user doesn't know their email failed to get through.

Will need to tweak the rules if I can to allow them through, or I'll have to manually pass delivery failure messages back to the intended recipients.

Ideally ESET would have their own solution in place by now, any news on this? This was meant to just be a temporary bandaid solution...

Mike

[Mike 8]

I've checked with ESET, and their solution is basically a rehash of mine:

hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3346

They suggest text filters for keeping hold of Out of Office, and delivery failure notices. I might still keep my SCL=1 in there, as at least this will allow any SCL=-1 entries to pass through unblocked (which seemingly many Out of Office messages are).

So it looks like no further progress has been made on this, however I am guessing the problem lies with Exchange, so ESET might not be able to do much about this other than offer workarounds.

I'll try some text rules with "SCL=1 and above" and see how it works...

Mike

Edited June 16, 2013 by Mike

[Guest Rescue]

I am more than grateful for this although I have not tried it, it looks like something that will work out of the box. Thanks

[Mike 8]

I just heard (in this thread) that ESET have supposedly fixed this issue in the latest release version of EMSX (4.5.10015).

 

I haven't tried installing this update yet, but maybe the first person who gets it installed, and confirms it has indeed solved the problem, can report back here for everyone. I will certainly be glad to be able to strip out my transport rules as I never managed to tweak them to get exactly what I wanted without some unintended implications!

 

Thank you ESET. I was starting to think that with the Microsoft aspect to the problem, it might never get fixed!

 

Mike