What is SecurityGateway for Email Servers?
SecurityGateway for Email Servers, developed by Alt-N Technologies (creators of MDaemon!), is a Windows based software solution that provides a robust front line defense against spam/viruses/phishing emails before they reach the users on the back end email server.
Why would you need a product like SecurityGateway?
The benefits are many, here are just a few!
- On busy email servers SecurityGateway will help lessen the load of the email server that users are connecting to. SecurityGateway will do all the heavy duty work of filtering emails before they reach the email server. Your email server can then concentrate on what it does best – processing requests from your users! Such as sending/receiving email, creating appointments, tasks, notes, sync’ing mobile devices, maintaining shared data, mailing lists, etc.
- Easy to read detailed ‘clickable’ colour-coded logs and reports. Not all email server logging is equal! SecurityGateway’s logging and the ability to search logs through a web based interface makes diagnosing delivery problems a cinch.
- Will help reduce admin overhead of dealing with spam. A default installation of SecurityGateway will reject blatant spam. Other emails that are suspected of being spam get sent to the user’s personal quarantine. An email notification gets sent out to the user informing them what emails they have in their quarantine. Users can release emails from their own quarantine, delete emails, or whitelist/blacklist the sender’s email address. Each user can deal with their own spam!
- Less expensive than other similar solutions. A recent review from a security expert in the UK found that SecurityGateway caught more spam messages than a similar product from Barracuda at half the cost. The full review can be read here.
- You are happy with the functionality provided to your users by the email server, but find the security features lacking or missing altogether.
Deployment Scenarios For SecurityGateway
Scenario 1: A typical Exchange server installation without SecurityGateway.
Here’s what a typical Exchange Server installation would look like before SecurityGateway has been deployed. The DNS MX record would be configured to point to the public IP address of the company.
In most cases the router is configured to direct port 25 (SMTP) traffic to the internal IP address of the server running Exchange. Also known as static NAT.
Scenario 2: Installing SecurityGateway on a Dedicated Windows Server
This scenario is the easiest way to deploy SecurityGateway that requires the least amount of changes to Exchange.
The router’s NAT translation is reconfigured to point SMTP traffic to the new server running SecurityGateway. The destination port of this NAT translation remains unchanged from Scenario 1. Only the internal IP address which traffic is routed to will change.
This scenario is ideal for busier/overloaded Exchange Servers. The workload of the Exchange Server can be lessened by sectioning off the SMTP traffic and the overhead of spam/virus filtering.
This is also the best scenario for testing SecurityGateway, or to have the ability to turn SecurityGateway’s filtering on or off by simply editing the NAT translation to point either SecurityGateway or the server running Exchange.
Scenario 3: Installing SecurityGateway on the Same Server as Exchange (PAT)
Scenario 3 moves away from using dedicated hardware. SecurityGateway and Exchange are both installed on the same server. In this example SMTP traffic is arriving on port 25 and is then redirected to the server running SecurityGateway on port 26. SecurityGateway then sends the email to Exchange on port 25.
***NOTE: this option requires that your router supports Port Address Translation (PAT). A PAT enabled router provides the ability to change the destination port in addition to the IP address. If your router does not support PAT then we would recommend Scenario 4 below.
One of the main reasons for choosing this option is the cost savings associated with using the same hardware to run both Exchange and SecurityGateway. It is important to run a trial of SecurityGateway in this scenario to ensure you are not going to be putting an excessive load on the server. For smaller businesses this does provide a cost effective way to protect your Exchange users.
Scenario 4: Installing SecurityGateway on the Same Server Running Exchange (non-PAT)
Scenario 4 is similar to scenario 3 except that we are not using a PAT enabled router so we have to route email traffic a slightly different way. In the diagram above Exchange has been reconfigured to listen on port 26 for SMTP traffic instead of the standard port 25. By changing the port Exchange listens on we are able to configure SecurityGateway to take it’s place on port 25.
The reason for the changing the port on Exchange is because 2 different services (SecurityGateway and Exchange) cannot share the same port, in this case, port 25.
Thanks for Zensoftware for the pictures and information on deploying SecurityGateway in the different scenarios.
Handy Links
SecurityGateway 30 day trial can be downloaded in English or French.
SecurityGateway ‘Quick Start’ Guide can be download from here.
This is the end of Part I. Stay tuned for Part II where we’ll show you how to create a User Verification Source connecting to an Exchange 2013 Server so that SecurityGateway can add or remove users in an automatic fashion.
Any questions? Send us an email to support@ccsoftware.ca.
