Message Sniffer Installation Guide: Declude + IMail

Documentation Home · White Papers · Installation Guide: Declude + IMail

Installation Guide: Declude + IMail

This is a general guide for installing Version 3 of SNFServer / SNFClient on IMail systems using Declude. We assume that you have already installed Declude sucessfully. Your specific installation might be slightly different than the example we're presenting here, so be prepared to make appropriate adjustments to these instructions as you go along.

Be sure to consult the readme files in your SNF distribution for additional information.

Please email support@armresearch.com with any questions.

Be sure you have your license id and authentication code. If you don't have a valid SNF license yet then you can get one by signing up for a 30 Day free trial. Your license ID & authentication string will be sent to you via email.
Download the SNF Client/Server Win* Installer.
Review the Installer tutorial, and have your trial SNF license ready.
Run the Installer and follow the SNF Install Tutorial for the Imail with Declude Install option.
- When prompted, as shown in Figure 9 of the Installer tutorial, use the free trial licenseID, and authentication. The Installer will download fresh rulebase and help set you up.
- The Installer will need to restart the Imail delivery service.
When you have completed the Installer, you will have installed Message Sniffer in a folder of your choice and pulled down a rulebase.
Review the documentation on configuring the snf_engine.xml file for your specific needs (Header Injection, Rulebase Downloads, GBUdb).
Advanced: Abuse Reporting Addresses - If you have any email addresses where your customers might legitimately send you spam or pieces of spam, such as an abuse reporting address, you may want to tell SNF to bypass GBUdb training when a message is sent to that address. That way GBUdb won't erroneously learn that the customer's IP is a source of spam. If you use a form on a web server for this kind of reporting then you may want to bypass GBUdb training for that server's address.

To set up GBUdb bypass based on the To: header of an email, make a copy of the example provided in your snf_engine.xml file, remove the  to uncomment the entry, and modify the entry for the To: header you want bypassed. For example, if you have an address called abuse@example.com then your <bypass> section might look like this when you're done:
```
<bypass>
    
    <header name='To:' find='abuse@example.com'/>

    
</bypass>
```
To set up an additional entry to bypass a web server's IP (say 12.34.56.78) then you could make a copy of the Received header directive and modify it so that it matches what you would expect to see from the first (ordinal 0) received header when the web server delivers a message. Your <bypass> section might look like this when you're done:
```
<bypass>
    
    <header name='To:' find='abuse@example.com'/> 

    
    <header name='Received:' ordinal='0' find='[12.34.56.78]'/>

</bypass>
```
There are many other configuration options in the snf_engine.xml file that you can explore later. For now, we've covered the basics. Check the file over to ensure it is still formatted correctly and that the parts you have changed are correct then save and close the file.
Advanced: Telling GBUdb to Ignore Gateways - If you have gateways or other MTAs that are trusted and you want SNF to ignore them and drill down to find the actual IP source for each message then those IPs need to be entered into the GBUdb with their Ignore/Infrastructure flag set. The easy way to make sure that these IPs are always "Ignored" is to add them to your GBUdbIgnoreList.txt file. Each time SNFServer loads a new configuration (or restarts) the IPs in the GBUdbIgnoreList.txt file are posted to the GBUdb as Ignore entries. This way even if your GBUdb data is lost these IPs will be safely ignored as part of your infrastructure.

Use a text editor (like notepad) to open your GBUdbIgnoreList.txt file. If you have two gateways with the IPs 12.34.56.78 and 32.54.76.98 then you would add each IP on it's own line in the file. Your GBUdbIgnoreList.txt file might look like this when you are done:
```
# List of IPs to Ignore on startup
# Each IP in this list is set to Ignore in GBUdb when
# The configuration is loaded.
# Hash mark on the beginning of a line indicates a comment.
# Comments after an IP are also ignored.
# One line per IP. Sorry, no CIDR yet.
# Be sure to list ALL of your gateways :-)

127.0.0.1	# ignore localhost, of course.
12.34.56.78
32.54.76.98
```
The GBUdbIgnoreList.txt file DOES NOT understand CIDR or wildcards. If you wish to ignore blocks of IP addresses then you will probably want to use the drilldown feature which allows you to enter patterns of received headers who's IPs should be flagged Ignore in the GBUdb.

Save and close the GBUdbIgnoreList.txt file.
SNFServer should now be running as a service. You can check its status at the command line using SNFClient -status.second which will show you some XML data representing the current operating status of the SNF engine. You can see the same data by opening your status.second.log.xml file in the SNF folder.

Usually you can open this file in your favorite web browser and then refresh it periodically. Your browser may complain that there is no style information associated with the file - but that's ok.

The top line will indicate a basetime that changes about once per second. If it is changing when you refesh the page then SNFServer is running. You can scroll further down to the <rates/> section and observe the message processing rates changing when you refresh the page. The <m/> element shows messages per second, minute, hour, and day. The <s/> element shows how many of those messages were tagged as spam, again - per second, minute, hour, and day. If these numbers show messages moving through SNF then your installation is complete and successful!