SpamCheetah E-mail threat control deployment guide

contact@spamcheetah.com

System requirements

Define the resource needs of node running appliance

Initial steps

How to deploy SpamCheetah into your mail flow

Deployment checklist

Things to keep in mind whilst deploying

Using test vectors

How to check if things are working correctly

Technical support/queries

Technical help from our team to deploy

If things go wrong?

What to do if things do not go as planned

System requirements

Depending on if you download the raw appliance or VMWare appliance or ISO to install to bare metal the methodology will vary only a wee bit. But the node running SpamCheetah after installation needs the following characteristics.

Other things can vary. For both editions standard and heavyduty the requirements are same.

The time taken to install SpamCheetah is around half an hour but deploying will take time since the network architecture changes to allow SpamCheetah to do the job. This software being mission critical a great deal of care is needed and for a reasonably experienced systems admin this is no big deal.

Back to contents

Initial steps

Before we can talk about how to deploy SpamCheetah we must first find out the existing network block diagram and how that should be changed to fit SpamCheetah. For both editions and regardless of if it is ISO install or VMWare appliance or raw appliance, the network level semantics do not change.

To deploy a new network node some obvious adjustments must be made, stuff like IP address, network mask and gateway are needed if not using DHCP. And SpamCheetah does support DHCP. You can also assign a domain and assign a public or private alias as well. You also can create static routes as you can see from the web interface.

The steps towards successful deployment almost always involves some amount of planning and routing change and knowing how to handle that. Since the target mail server in case of Standard edition need not belong to same network you can deploy SpamCheetah in a different private cloud or on premises location and run your mail server in the cloud or vice versa.

The way you can check successful deployment is detailed in several pages in this website but usually the most basic tests are sufficient and that may not even involve SpamCheetah's web interface at all. If mail reaches your inbox after passing through the appliance things are good to go.

To deploy SpamCheetah you must know clearly what the flow of mail traffic is. Kindly look at the block diagram below.

Before heavyduty installation of SpamCheetah

It is important to save your IP address, netmask and gateway addresses and other detail like MX records that you change during deployment to go back in case things go wrong.

Here is a partial checklist of what you should note down:

This is how things should look after you deploy heavyduty edition.

After heavyduty installation of SpamCheetah

This is how things should look after you deploy standard edition.

Standard SpamCheetah installation

Please note that this just an example and not relevant to your scenario.

We must be clear what should be the network diagram after deployment.

Back to contents

Using test vectors

Hopefully the above schematics and your network block diagrams helped you has out the deployment details. If not then the text would have helped or alongside that.

The thing now is to check if the deployment was correct in all respects and if it has not broken a single function before deployment. To do that in addition to following checklists outlined here we must also validate based on common sense metrics and reasoning.

The ability to get mail in your inbox is the key thing here. If that works then you are mostly successful. It may take time for mails to flow since SpamCheetah takes a little while to learn about your network particularly with greylisting enabled.

The first test should be to send mail from any of the Whitelisted senders like Gmail for instance. The mail should come right away. SpamCheetah is only concerned with incoming mail flow. If your outgoing mail is somehow affected then you may have done something wrong.

In addition to checking what is mentioned here you should also ensure that other things beyond the purview are not broken , things like outgoing mail, routing and simple ping tests can reveal some debugging info too.

In order to be sure you did deploy correctly you must do the following tests.

Back to contents

Deployment checklist

In addition to the above you must also validate several other things. Always be prepared to roll back changes if something does not feel right.

Just because mails flow does not mean things are working correctly. Please use some network sniffer like wireshark or some network monitoring tool to ensure that emails flow correctly.

Give it time so the greylisting subsystem in SpamCheetah can settle down with your network's mail senders. Sometimes if you do not turn off greylisting you may find that the first mail tests do not succeed right away. But all Gmail and google apps mails are whitelisted so they should arrive right away.

Back to contents

Technical support/queries

Deploying a complex product is not to be taken lightly. In case you wish to avail our presence on a video call or screen share throughout the deployment we don't mind it. But we have furnished as much background information for the task as we can so that should not be necessary. Please check out videos for more information in case you feel lazy to read the text

It is not uncommon to feel lost whilst deploying a complex email gateway product. Feel free to contact us whenever you want and we shall gladly help you out at the earliest opportunity.

Contact support for help.

Back to contents

If things go wrong

If your deployment does not go as planned no need to panic. After all you get success only through multiple failures. It does not matter since there is plenty of useful documentation in this website and you can do lot of Google searches to gain insight into what might be the cause for failure. If it is a bug in our product we can help you or get it fixed as soon as we can.

To find out where you are stuck exactly is very difficult. It could range from you not knowing some technical aspect of networking or e-mail to something you did not read on our instructions or checklist to something wrong with your ISP , some transient outage, it could mean anything.

To find out what really is going on, you can use network probes and tools like wireshark, tcpdump, protocol analyzers and such. It is always important to plan for network deployment using block diagrams to represent network elements from mail point of view before SpamCheetah and after SpamCheetah.

If you are trying to deploy SpamCheetah heavyduty edition then things are slightly more complex as you have to deal with several MX records and DNS records as you know take time to propagate. And if you don't setup correctly then they don't even start to propagate.

Anyway complex enterprise software take time to settle and deploy and be fully operational. So patience maybe a virtue here and perhaps you could solve the issue by taking another stab at deployment after a coffee break or get back to it after some rest to your brain?

The block diagram discipline is very useful and it is not only useful for smooth deploying but also for rolling back very easily in case things do not go our way. It is not uncommon for software installations to fail as even a trivial misstep can bring the whole thing crashing down. So it is always a good idea to plan for failures even before you begin making a single change.

Even if you decide to rollback despite things working fine if your plan was only to test or learn deployment then no problem. Simply follow the block diagram and undo the changes you did and that should do.

Contact support for help.
contact@spamcheetah.com

Live web interface of SpamCheetah