Messaging Gateway

I am having problems with some Spam messages making it through one of our SMG servers over the past several weeks, but gets properly flagged as Spam on another SMG server we have.

I am running two gateways… one gateway for inbound messages from the outside world, and the other gateway for outbound  messages going to the outside world.

The inbound gateway is at version 10.5.2-3.  The outbound gateway is at version 10.0.1-2.   Timing wise... it seems coincedental that the Spam problems started when I upgraded to the newer software versions of SMG software on the incoming gateway.

Over the past few weeks our site (including myself) have been getting an abnormally high amount of spam related messages making it through the incoming gateway into people’s inboxes (including my own).   In looking at the Message Audit Logs on the incoming gateway for these spam messages that are making it through… it says under verdict to “Deliver as Normal”.   Some of these Spam messages are not being flagged as Spam or even Suspected Spam.   Yet I know the spam filter is working on the incoming messaging gateway because if I sort incoming messages by a verdict of SPAM, I can see many in a day that are getting flagged properly as Spam, and getting deleted (the rule I have is… if a message is SPAM, delete the message).

So I don’t know why we are getting so many additional SPAM related email messages making it through our incoming gateway without being flagged as spam or even suspected spam.

YET… if I take any one of these SPAM messages that make it through our incoming gateway to my Outlook Inbox, and forward it to an external email account that I have… which then makes this same Spam message go through our Outbound gateway…. The outbound gateway sees this same message as SPAM, flags it as such, and deletes it.   That’s the verdict and action I’m looking for from our inbound email gateway.

I don’t know why our inbound email gateway (newer software version) is letting some Spam related messages go through un-flagged as Spam… yet our outbound email gateway (older software version) is flagging these very same messages as Spam and deleting them.

Is there some sort of difference in the scanning engine between the two email gateway servers / software versions, where the older version of the software is more aggressive at scanning for spam messages compared to the newer software version?

What we are seeing is that there are a few messages that will get delivered, but as soon as the Messaging Gateway gets the updated rulesets, the messages then get flagged. That is normal, since we have to have a rule for a message for it to get flagged. Sometimes the spammers happen to get to you ever so slightly faster.

We are haveing the same problem. There are large amounts of lean IPs that are able to send hundreds of messages with spam URLs to the company before being blocked. The liveupdate is not enough, as it is happening very often. I am testing out a content filteing policy that checks for messages containing URLs with certain extensions, and blocking or quarantining them based on what they are (.html and .php URLs are sometimes legit, but .rb and .cfm URLs generally are not needed in the body of an email).

Assuming these are the same emails you are getting, Here is the RegEx pattern I created to identify these them.

\b(\b(http|https).*(\b(\.rb|\.asp|\.jsp|\.link|\.pictures|\.rhtml|\.exe|\.htm|\.php|\.xhtml|\.pl|\.do|\.aspx|\.cgi|\.cfm|\.shtml)\b)\b)\b

It catches things like:

http://www.findingoices.com/excion/comt/recator/exs/coros.rhtml
https://test.rb
https://test.rb/kjhsadjs.rhtml
http://test.rb/test
etc.
and not things like http://test.com/ or http://test.company.rhtml.org. 

Still in the testing phase, and I am not a RegEx expert, but the Gateway is very picky about what is matches and doesnt match with certain expressions, and it is not easy to make it work the way you want it. Just need to create a content filtering policy to apply an action to messages with certain URLs in the BODY. You can set other policies for Marketing Mail and Newletters by bypass this content policy, since email labeled as those two are generally legit. 

We've had a support case open since August around this same exact issue. 

Since we can't get rulesets fast enough, why not try and pause the messages in the Inbound Delivery queue for 10 minutes before scanning, then delivering? Sure, the delay wouldn't be ideal, but this would allow enough time for new rulesets to be created and downloaded. Maybe only pause messages above a certain Connection Classification threshold. As far as I know, there's currently no way to implement this.