Windows anti-spam & anti-virus server on AWS


In house we run an Exchange server which is great but the anti-virus and anti-spam tools are limited or relatively expensive. To date we’ve addressed this issue by using a front-end server running a combination of PostFix, SpamAssassin and ClamAV on Ubuntu. It’s been effective and inexpensive. However, we can no longer update ClamAV because [at the time of writing] there is no back port of Clam for Ubuntu 10.04 LTS.

Our solution is to use a Windows anti-spam & anti-virus server alternative using hMailServer with SpamAssassin and ClamAV.

My gripe

Not interested in my whining? Move on to the next header.

The anti-Microsoft fundamentalists exclaim the benefits of Linux but it has a major weakness when compared to Windows: no backward compatibility. A 20 year-old product written to run on Windows ME will probably still run on Windows 8. And that’s to Microsoft’s credit. It takes a lot of effort to maintain backward compatibility and the benefit is that old software keeps running while new software is going to work. That is, our existing investment in software is not expired by Microsoft. By contrast the Linux policy of not maintaining backward compatibility means each new kernel update forces software to be re-installed and, most likely, require that application source code is updated and re-compiled. Not supporting backwards compatibility makes the development of the Linux platform more flexible and keeps the costs down but at the expense of increasing the TCO of everyone else. It is interesting that this issue doesn’t appear in TCO discussions.

Our problem is that although Ubuntu will support 10.04 LTS there is no guarantee that providers of software will be so compliant. An example is that a couple of months ago ClamAV released 0.98. However there is no back port for Ubuntu 10.04 at the time of writing. At the moment it’s not important because 0.97.8 just keeps ticking along. But for how long? Back in the days of 0.95 it, too, kept ticking along – until it didn’t and virus checking stopped abruptly. It was then necessary to update the Clam binaries and, fortunately, there was a back port. I do not want to be in that situation again.

So why not upgrade to a later version of Ubuntu? Tried that, it was a disaster.

Why AWS?

Why AWS? Why not install a front end server locally? The answer is reliability. We’ve been using AWS since 2007 to run our web server, PBX and mail front end. In that time we’ve not lost any up time except through our own actions. As a result I have confidence that a mail server front end will be available all the time and able to store then forward messages if (when) our local servers are not accessible from the public internet.

This post is not about setting up an EC2 instance on AWS as there are many resources to explain how to accomplish that goal. It turns out we have spare capacity on our servers running in AWS. These are instances of Windows Server 2008 R2 so it makes to use that capacity for something useful since there’s no additional cost.

I think it is worth mentioning that we are using ‘micro’ instances for our web sites and, now, for our mail server. Micro instances have limited memory but web servers and mail servers are not demanding so they go together nicely. Each micro instance costs $0.05/hour to run or $5/month. So we run a fleet of micro instances behind a load balancer and in this way can enjoy the knowledge that any demand will be spread across the available servers.

About hMailServer

hMailServer is a free, Windows based mail transfer agent (MTA) which supports:

  • Inbound and outbound SMTP
  • POP3 and IMAP
  • The ability to integrate virus and spam agents

These are all the features I need. Although hMailServer supports being ‘proper’ mail server with domains, user accounts, etc., its attraction to me is that it can act as a front end server to check email and forward messages on to our Exchange server. Setting it up with no prior knowledge was a little bit of a voyage of discovery and took about 8 hours. Most of that time was finding the various components and learning how to configure them. The purpose of this post is to document as much as I can about that voyage before I forget.

The components

Obviously hMailServer.

In addition it was necessary to download Windows versions of SpamAssassin and ClamAV. Although there is a ready built Windows installer for ClamAV to download from the ClamAV site, Windows support for SpamAssassin on the SpamAssassin site is not so good. But a good and up-to-date copy of SpamAssassin for Windows is available free from Jam Software.

Although hMailServer runs as a service, the daemons included with the Windows packages of ClamAV and SpamAssassin do not run as Windows services. If these components were being installed on Windows Server 2003 it would be possible to use InstSrv and SrvAny from the Windows Resource kit. However, as the host machine is Window 2008 R2 other solutions are needed.

To run ClamAV as a service I used a small utility call WinServ. This tool acts a wrapper around any program and takes responsibility for starting and stopping a program like the ClamAV daemon in response to Windows service commands. This the line of code to install a service to run clamd.exe that ClamAV daemon process:


C:\ClamAV\Service\winserv install ClamAV -displayname "ClamAV service" -description "Controls the ClamAV service" -ipcmethod blind -errorcontrol normal -noninteractive c:\clamav\clamd.exe

This presumes ClaAV is installed in ‘c:\clamav’ and that winserv has been saved into a sub-folder called ‘service’.

Note that on Windows 2008 and later there is a tool called ‘sc’ which is provided with Windows to allow Windows services to be created at the command line. However this approach presumes that the program being run does not block which, unfortunately both the ClamAV and SpamAssassin daemons do. This makes ‘sc’ unsuitable in this case.

Even WinServ cannot be used to run the SpamAssassin daemon because this daemon MUST be run so that the working directory is the installed folder. Windows services use ‘c:\windows\system32’ as the working folder and as there’s no way to change this and WinServ cannot help another solution is needed. Fortunately there’s the spamdloaderservice.

The spamd loader service is a small .NET application which like WinServ is a wrapper around a process to provide service interaction. Unlike WinServ it will run the wrapped process in it’s install folder. The spamd loader service is also able to run sa-update to keep the spam signatures up-to-date.

Installing ClamAV

The first setup task for ClamAV is to create create two sub-folders: ‘db’ and ‘tmp’. Next create configuration files for ‘clamd.exe’ and ‘freshclam.exe’. Example files are provided and specify useful default options for both programs. The real changes needed are to replace the paths which are shown in a unix style with their Windows paths equivalents. The updated configuration files should be saved into the root of the ClamAV install folder.

The last setup task for ClamAV is to create a scheduled task to run Freshclam. Freshclam should be run frequently, say one a day to update the virus signatures. Freshclam must also be used before any other ClamAV software so the main database can be downloaded.

The service can be started, like any other service, using the services control applet.

Installing SpamAssassin

Installing SpamAssassin is little more than running the installer provided by Jam Software. The installer will also run sa-update to retrieve the most recent signatures.

The next task is to use the spamd loader service. In my case I saved the spamd loader service into a sub-folder named ‘service’. Next, run ‘SpamDloaderConfig.exe’ to set the options for the loader. The option are stored in the registry and because of this, the program should be run as administrator so the application has rights to update the correct registry keys. The options are obvious – such as the location of the spamd program.

What didn’t work for me was setting the sa-update options. For me, the option to enable updating spam assassin was not enabled. As the configuration values are stored in the registry I found the the values in this key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Tooms\SpamDloaderService. The sa-update options can be enabled by setting the value ‘SAupdate_channel_Enable’ to ‘True’. Now it’s possible to re-run ‘SpamDloaderConfig.exe’ to select the appropriate options for the sa-update. It did find it was necessary to do one last manual check of the values saved in the registry to make sure they were all correct.

The spamd loader service can be installed by running InstallService.bat. The service can be started, like any other service, using the services control applet.

Configuring hMailServer

When the hMailServer software is installed it will be running and able to respond in port 25. The remaining tasks are to configure it to process email message using ClamAV and SpamAssassin and to forward messages to our internal Exchange server but only if they are to addresses for a valid domain. To do this, start the configuration tool.

To begin, click on the SMTP protocol node in the hierarchy on the left of the screen. DO NOT ENTER OR CHANGE ANYTHING HERE. Move along.

Next, create two routes (Setting->Protocols->SMTP->Routes). One route will be called ‘Valid domain’ and will provide a route to use when a message to a valid domain is received. The other will be called ‘Invalid domain’ and will be used to route messages that are to other addresses. Note the second route is there as a fall back and will probably not be used.

In the ‘Domain’ box of the first route enter ‘Valid domains route’. In the ‘Target SMTP Host’ box enter the address of your internal mail server. Nothing else needs to be entered or changed.

In the ‘Domain’ box of the second route enter ‘Invalid domains route’. In the ‘Target SMTP Host’ box enter the address of your internal mail server. Nothing else needs to be entered or changed.

The next step is to create two rules. Like the routes, there are two rules: one for valid and one for invalid domains. Rules have two parts: criteria and actions. The rule criteria define a filter constraining the messages to which the rule action will be applied. So the rules will be defined as follows:

Rule 1

Name: Valid domains

Criteria: Add a criteria for each valid domain. The ‘Field’ for each crtieria will be ‘To’, the ‘Search type’ will be ‘Wildcard’ and the ‘Value’ will be ‘*@*’ (you will replace ‘‘ with your domain.

Action: Add two actions. The first will be ‘Send to route’ and select the ‘Valid domains route’ route created earlier. The second will be ‘Stop processing rules’. This prevents the second rule (to be created in a moment) being processed if the message is for a valid domain recipient.

Rule 2

Name: Invalid domains

Criteria: Add one criteria. The ‘Field’ for each criteria will be ‘To’, the ‘Search type’ will be ‘Wildcard’ and the ‘Value’ will be ‘*’. This will match all messages not matched by rule 1.

Action: Add two actions. Ultimately, the first action will be to ‘Delete e-mail’ but initially it’s safer to use the alternative route. The second action is to ‘Stop processing rules’.

Time to test

With the routes and rules in place mail for valid domains should be relayed through the server. This is a good time to do some testing.

Anti-spam/Anti-virus

The final steps are to enable the use of ClamAV and SpamAssassin. This is done using the respective node in the hierarchy on the left.

To enable SpamAssassin, select the anti-spam node then select the SpamAssassin tab. Check the ‘Use SpamAssassin’ box. You should not need to change anything else. Now click on the ‘Test…’ button. If it works you will see a dummy message sent to spamd, processed and returned.

To enable ClamAV, select the anti-virus node then select the ClamAV tab. Check the ‘Use SpamAssassin’ box. You should not need to change anything else. Now click on the ‘Test…’ button.If it works, you will see a message box telling you that a virus has been found in a dummy message sent to clamd.

And there you have it, a mail server able to check and forward valid in-bound emails to an internal server.

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Be the first to leave a comment!