Spam Blocking & Operation Gemstone

Those of you who manage email servers at a similar level to myself will have noticed a huge increase in malware-infected spam during 2013.

In fact it has got to such a level that it was becoming unmanageable without a recognised Spam filtering application. And with no plans to venture into the realms of SpamFighter, GFI MailEssentials, Baracudda or others I decided it was time to go all on an all out spam war.

Part 1 started earlier this year with a number of emails being received relating to Stock Market purchases and “upcoming targets”, these were obviously spam, and so started “Operation Gemstone”, so-called due to the first set being related to a Gemstone Mining Company. This was becoming a nuisance for all staff and so we started blocking emails by familiar key words, i.e once we had 3 or 4 of a similar nature we were able to deduce a keyword that we could block and that wouldn’t block (too much) valid email. We started with a transport rule “Gemstone” and we now have 5 of these! The Gemstone rule set blocks key words found in either the subject or body, it excludes emails sent to the boss (who manages his own spam) or from an internal address, and rather than deleting, it redirects the message to a holding account as a quarantine where we can forward on false-positives if necessary.

Part 2 came about after analysing hundreds and thousands of spam emails collected over a number of months and actually looking at the message headers to find more similarities between emails of a seemingly different subject matter. Naturally, the first thought was the source IP, and in some cases we found multiple occurrences of the same IPs, however on the whole they were different every time. (Where we found similar entries we blocked them at firewall level) So the one area we found similarities was in the “Return-Path” message header, with a huge number coming from addresses pretending to be American Express related ( etc.) so then came our second rule set “Return Path Block”, this again was a transport rule with a redirect to a holding account, the difference this time was to set the rule to read the message headers and look for a “Return-Path” containing various phrases. This rule was so successful that we could turn off Gemstone’s 1-3 meaning less load on the Exchange Transport servers.

But then, another realisation hit, as the months have gone on this year, the spam was becoming more and more convincing, apart from one thing… Zip attachments! On instructions from above I blocked all incoming Zip attachments (by redirect, again). Since 9.05 Monday 18th November 2013 (7 Days) 1208 emails have contained zip files and have been redirected to the quarantine account. Of these only 4 have been genuine files meant for our staff! so our “Zippy” rule sits at the top of our transport rule set and does its job admirably.

Sure these methods may seem a little archaic, but I see a couple of advantages:

  • By redirecting rather than deleting at source it gives a chance to filter through emails to ensure nothing is missed
  • By using built in Exchange rules instead of a 3rd party tool adds less overall load to the Exchange servers (from our experience)
  • We can add new keywords, return-path sources or attachment types instantly
  • The transport rules allow us to TAG the emails, by pre-pending with for example: <BLOCKED – Gemstone Rule> or <.zip file attachment> allowing us to filter emails within Outlook

If anyone has any comments about all this I would love to see them, please feel free to contact me.



Windows Server Backup with DAG

Following on from the Exchange 2010 issues I’ve been having, my last hurdle has been backups. I couldn’t figure out for the life of me why the daily backups of my Exchange installations were failing. So I followed a couple of YouTube videos and made minor changes. This still didn’t work, so after a day of not thinking about it, and clearing my mind I finally found this solution, which worked a treat:

Using Windows Server Backup on Database Availability Group Members

If a server hosting the data being backed up is a member of a database availability group (DAG) and hosts both active and passive database copies, you must disable the Microsoft Exchange Replication service VSS writer. If the Microsoft Exchange Replication service VSS writer is enabled, the backup operation will fail.

To disable the Microsoft Exchange Replication service VSS writer, perform the following steps:

Log on to the server by using an account that has local administrator access, and then start Registry Editor (regedit).
Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\ExchangeServer\v14\Replay\Parameters.
Add a new DWORD value named EnableVSSWriter, and set its value to 0.
Exit Registry Editor and then restart the Microsoft Exchange Replication service.

This solution is found here:

Exchange 2010 Failure


It seems that after I’ve finally built a redundant Exchange 2010 cluster with DAG that I needed a reboot on one of the servers (due to some other reconfiguration) – unfortunately I had forgotten the server hadn’t been rebooted since before AVG Business Edition was installed, oops, this appears to interfere with the WinRM service which just wouldn’t work, this meant I couldn’t use anything powered by powershell through the IIS – in other words I had no Exchange Management Console (EMC) or shell commands. The problem wasn’t so much emails as the DAG implementation ensured my other server took care of that with the passive database copy becoming active at the server fail, it was my primary public folder database which had the most problems, it just wouldn’t mount, so a quick scheduled reboot (during the lunch hour) and within 20 minutes (after 2 1/2 hours diagnosis and testing) I had the public folders back, this was also partially affected by the Replication service on the healthy server being stuck in a “stopping” state, I had to kill the process in task manager to fix this and manually start it.

So, what have I learnt today?
Exchange works, now leave it alone!


somewhere along the line this reboot etc enabled SSL on the pop3 service, this affected a few of our remote users, but I managed to fix that quickly enough once I knew the issue!