Flexible Web Services Info Tech Support

One of the things I discovered, or re-discovered, while setting up MailCleaner is DNS lookups will not work with public name servers. While running the mailscanner spam test (located here /usr/mailcleaner/bin/is_spam.sh) 

 /usr/mailcleaner/bin/is_spam.sh -D check.eml > results

I received a notice that my rbls were blocked and to contact the administrator. Researching a little, I found this:

Anthony Cartmell-2 wrote
> The caching aspect isn't particularly relevant.
> 
> The problem is that your ISP's name server will be querying the URIBL
> server on behalf of perhaps thousands of SpamAssassin instances on other
> machines. So it's blocked because it's making too many queries from a
> single IP address.

Yep, thank you, already figured this out. My problem was that I was not sure
how exactly DNS works, and by studying dnsmasq configuration I incorrectly
assumed that a dns server is always supposed to have an upstream server.
Apparently this is the case for dnsmasq but not the case in general. So now
with djbdns setup that I have in place that perform recursive queries
starting from the root servers this all makes sense. Thank you again.

The master MailCleaner server was easy to fix. The web interface has a connection to upate the DNS information under Base System. the slave server was not so easy to fix. When I try to connect to the web browser at the slave, I get redirected to the web site on the main server. Digging around, I found set_ip_config.sh in /usr/mailcleaner/scripts/configuration. Running it ask questions about the network interface, which includes the DNS settings. After running that and answering the questions, I ran dig to see what DNS server the slave would check. The end of the script errored out as it did not restart the network interface, but it did set the DNS servers.

This made the most dramatic change in spam detection for me. I pretty much had SpamAssassin configured, but with the DNS being blocked, many of the SpamAssassin tests didn't work either.

One of the things that seems apparent in Mailcleaner is you will have to train the Bayesian filter yourself.  They had a script for it at one time, but that doesn't appear to be anywhere in the new installations. Here is the line to run:

Code:

sa-learn -C /usr/mailcleaner/etc/mailscanner/spam.assassin.prefs.conf --ham ham.eml
sa-learn -C /usr/mailcleaner/etc/mailscanner/spam.assassin.prefs.conf --spam spam.eml

Code:

netset: cannot include 146.164.36.14/32 as it has already been included
Use of uninitialized value $type in numeric eq (==) at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 668.
Use of uninitialized value $type in numeric eq (==) at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 671.
Use of uninitialized value $type in numeric eq (==) at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 674.
Use of uninitialized value $type in numeric eq (==) at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 677.
Use of uninitialized value $type in numeric eq (==) at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 680.
Use of uninitialized value $type in numeric eq (==) at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 683.
Use of uninitialized value $type in numeric eq (==) at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 686.
Use of uninitialized value $type in numeric eq (==) at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 689.
Use of uninitialized value $type in numeric eq (==) at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 692.
Use of uninitialized value $type in numeric eq (==) at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 695.
Use of uninitialized value $type in concatenation (.) or string at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 699.
config: unknown conf type ! at /usr/local/share/perl/5.10.1/Mail/SpamAssassin/Conf/Parser.pm line 699.

 

The Clamav-Unofficial-sigs are not provisioned by default and the ClamSpam daemon does not start without the sigs config file being configured and sigs downloaded. The forum information for setting this up that I used is here. Koma also provides a link to get the most current sigs install which includes the script for updating the database. On that link, he/she provides a complete conf file, which I think is helpful as it points to many directories in mailcleaner that are moved from the defaults.

Review the entire thread. There is informaiton for downloading, installing and setting up the crontab to automatically update the databases. One point on the crontab though. In the script, they use an & and I got errors when I used that symbol. It should be:

/sanesecurity/clamav-unofficial-sigs.sh >$ /dev/null

and not

/sanesecurity/clamav-unofficial-sigs.sh >& /dev/null

I had a frustrating problem (besides getting access to post in the forums), creating a cluster.

I finally got my master up and running like I wanted it to and was ready to create a cluster so I could off load some of my firewall issues. I followed the procedures here:

how to set up more than one filter (master-slave cluster)

First, install each host independently. 
Once installed you will have to get the password created by the mailcleaner installation process. This password is located in the file /etc/mailcleaner.conf. Use this command: 

cat /etc/mailcleaner.conf | grep MYMAILCLEANERPWD

Then:

1. On the master: 
   Use the script located in /usr/mailcleaner/scripts/configuration/slaves.pl. The first time, you will have to set the real hostname of the master, with option 1) (fully qualified hostname or ip). (by default it is 127.0.0.1). 
   Then select option 4) to add a slave and enter the hostname or ip and the password of the host. 
   Back in the main menu, hit “q” to apply changes.
2. On the slave: 
   Use the script located in /usr/mailcleaner/scripts/configuration/slaves.pl. The first time, you will have to set the real hostname, with option 1) (fully qualified hostname or ip). (by default it is 127.0.0.1). 
   Then select option 5) to set this host as a slave. Enter master hostname or ip and password. 
   Back in the main menu, hit “q” to apply changes.

You can now reach the admin interface of any host, but only the master will let you configure the system. 
It also is the only one that users can reach in order to access their quarantine.

 

In step one, I was a little confused about which password to use in option 4. The description for getting the password doesn't say which password you are getting, the master or the slave. Naturally, since we are linking both, we need both passwords and I assume we need the password for the slave on the master. It just doesn't say that. I thought the instructions should read: "to add a slave and enter the hostname or IP and the password of the slave." 

Which I did. Then I went to the slave and followed the instructions there, which kept giving me this error:

Syncing to master host (this may take a few minutes)...
** ERROR ** Unknown error !
Check the master hostname or IP address, DNS resolution and that this script has been run on the master first.

Since my slave was just installed, I had forgotten to do an aptitude update and then safe-upgrade, so I tried that and still got the same error. Researching the cause, I found this:

olivier wrote:

Jeff Slone wrote:

I get the following error when trying to put 2012.6 to slave to an existing cluster. The cluster upgraded from 2012.5 to 2012.6 with no issues. 


Syncing to master host (this may take a few minutes)... 
** ERROR ** Unknown error !
Check the master hostname or IP address, DNS resolution and that this script has been run on the master first.

I would say.. mmhh... "Check the master hostname or IP address, DNS resolution and that this script has been run on the master first"
You really really need to add the slave in the master first. That's not a joke.

No! I had such a problem and was helped by the decision of "theun":

I just ran into this problem.
The permissions on the script are wrong.
just type:
cd /usr/mailcleaner/bin/
chmod 755 resync_db.sh
They seem to be 644 for some reason on resync_db.sh
rerun the slave script on the slave and resync.
Try using ipadresses if hostnames don't work.
I got it working with ipadresses, haven't tried hostnames yet.

Olivier, check this please. Thank you.

The script is still not executable and doing that chmod did fix the problem. Since this only synchronizes the databases, I'm sure I will still have to apply all the updates and crontab changes manually. More on that later.