A recent upgrade from Plesk 9 to Plesk 10 resulted in us experiencing an issue where the Plesk Default Page is shown for the WWW prefix for a number of sites. Turns out it is a documented issue however the Parallels suggested solution hardly scales.
Continue reading
Very little in the way of official documentation on upgrading MailScanner on RPM based distributions so here is a 30 second tutorial.
1. Grab a copy of the package you wish to upgrade to, from mailscanner.info
2. Stop any MailScanner processes
3. Extract the file with ‘tar –zxvf MailScanner-X.X.X.rpm.tar.gz’ and enter the directory
4. Start the upgrade by simply running the ‘install’ script within – this will take 10 or so minutes
5. Change dir to /etc/MailScanner
6. Run ‘upgrade_MailScanner_conf MailScanner.conf MailScanner.conf.rpmnew > MailScanner.new’
7. Optionally view what has been changed with ‘diff -w MailScanner.conf.rpmnew MailScanner.new’
8. mv MailScanner.conf MailScanner.old
9. mv MailScanner.new MailScanner.conf
10. Restart MailScanner
Simple.
As promised here is an update to our Anti-Spam gateway since we have gone live. We have successfully been running for over a week now and are receiving positive comments regarding the service.
To monitor the performance of the server and to allow for some pretty spiffy looking reports we are making use of MailWatch. MailWatch will also form the base of our end user interface which is currently a work in progress.
One important change we have made to the MailScanner configuration is switching to using a ClamAV Perl module to scan email. When utilising the executable ClamAV we found the servers load average to be constantly sitting around 25 and mail delays upto an hour and a half. You can change this within /etc/MailScanner/MailScanner.conf as follows;
You will need to restart MailScanner for this change to kick in. Providing you used the SA / ClamAV RPM I linked to in the initial article to install ClamAV, this Perl module will already be available to you.
We are now running this solution on a Dell PowerEdge SC1435 AMD Opteron, 2GB Ram and 160GB SATAII Hard Drives in a RAID0 configuration. I believe the hard disks were the primary bottleneck on our initial server and as such the decision was made to run in RAID0. The server stores no customer data so data redundancy is not an issue.
The servers load average now sits around 1.5. On average over the last few days we are processing 100000 emails a day, 47% of being tagged as spam, and another 2% being tagged as virus.
While Plesk includes a distribution of SpamAssassin, when you have multiple servers to maintain and a need to integrate everything seamlessly it becomes apparent that this is not the best solution.
Based on the concept of Project Gamera from Atomic Rocket Turtle we have developed an in house Spam and Virus filtering solution that scales well, effectively scans and allows the user to manage their own settings.
This server acts as a mail gateway, sitting in front of our Plesk servers. Customers domains have two MX records configured as follows;
Upon scanning the email, it is then passed to the Plesk server the customer is hosted on, based on Relay lists described further on in this guide. The dual MX records allow for the gateway to go offline due to fault or load and customers will still receive their email.
Initial lab testing of this configuration successfully tagged 100% of spam email with zero false positives. During our production environment testing we were seeing close to a 98% success rate with zero false positives.
As described further in, this system is currently offline while we await the installation of new hardware due to performance issues.
From a clean installation of Linux through to a completely working Anti-Spam gateway this guide should have you running within 3-4 hours.
Originally we tested pre built packages including Project Gamera and dspam. While both packages were fairly straight forward in installation and use it made more sense eventually to take a look at their features and put something together that fits in with what we wanted.
The complete system utilises Postfix, SpamAssassin, ClamAV, MailScanner and MailScanner-MRTG for graph monitoring. This system was initially configured on CentOS 4.4 on an old Pentium 4 Server with a single 7200RPM 80GB HDD and 1GB of RAM.
The following steps are taken from the installations I completed and should work without fault. This is a summarised version, however is fairly self explanatory. While a huge amount of text follows, if you are familiar with Postfix you can probably skip some detail.
Save and exit main.cf.
Create the file /etc/postfix/header_checks and enter the following into it
This tells Postfix to move all inbound email to the Hold queue for processing by MailScanner.
Note that the next time you reload Postfix your server will open Port 25 to the outside world. Its important that you don’t put * records into your transport or relay_recipient files as this will result in you acting as an open relay and getting blacklisted. Being blacklisted is a horrible experience and you only make this mistake once.
Now we configure the destination of mail. This is achieved by editing /etc/postfix/transport and /etc/postfix/relay_recipients. This is fairly easy process. These fies simply say which domains we accept mail for, and once we have scanned said mail where do we send it.
relay_recipients lists the domains we are in control of. It must be in the format of
As these are converted to Hash files each entry must be in a name/pair combination hence the word ‘dummy’. For all Postfix cares you could put ‘panda’ in there. As long as its a single word.
The transport file is a little more complex however follows the same format. It should look as follows;
Where 10.0.0.1 and .2 is the IP of the destination mailserver. It is very important you leave the square brackets [ ] in place. I originally made this mistake and spent hours wondering why mail was bouncing, complaining about a loop. These square brackets tell Postfix to not attempt a MX lookup and to instead just send mail straight on.
After updating these files you have to feed them to Postfix manually by running postmap transport and postmap relay_recipients.
As we run this server in front of multiple Plesk servers that have domains added and removed daily we have scripted this process. In simple terms, we pull the list of domains from the PSA database on each server, note which server the list came from and then build these files. The list is checked for duplicates and we are emailed in the event it finds any. The two postmap commands are then run to refresh Postfix. This runs every 10 minutes.
Now we move onto the installation of MailScanner, SpamAssassin and ClamAV. The rest of this guide is much more straight forward, I promise 
You will also need to ensure Postifx can write to the MailScanner queue directories;
chown postfix.postfix /var/spool/MailScanner/incoming
chown postfix.postfix /var/spool/MailScanner/quarantine
Now would be a very good time to test your configuration and make sure email gets through your Postfix server, through MaiLScanner and to the destination server. Restart Postfix and run check_MailScanner to start MailScanner. Using a domain that has been configured in the Postfix relay and transport files and has its MX records configured to pass through your new mail gateway, send a test email. You can view its progress through the mail gateway by watching the mail log tail -f /var/log/maillog
Congratulations, you should now have a working Anti-Spam Anti-Virus mail gateway. Next we move onto “tweaking” MailScanner and configuring some graphs so you have some statistical information.
The main configuration file for MailScanner, /etc/MailScanner/MailScanner.conf is commented very well and explains everything in very simple terms. I am only going to point out the configuration options you really need to pay attention to, however I strongly recommend you go through the entire file. Note that all these directives exist in the default file, search for and edit them as required.
It is suggested you set Max Children to 5 per CPU. However this will vary greatly depending on your hardware specs, you queue scan interval and you messages per batch directives. Its also important to remember that SpamAssassin settings are controled from within MailScanner.conf and changes directly to SA configs will have no effect.
To restart MailScanner you should run check_MailScanner, take not of its process ID’s then kill them. To start MailScanner again rerun check_MailScanner.
As MailScanner uses a standard SpamAssassin installation I would recommend you take the time to install Pyzor, Razor and DCC. all three are easily installed and there is very simple step by step instructions in the SpamAssassin wiki. I would also recommend you collect any Spam that gets through and run sa-learn on it frequently. ClamAV will require its virus definitions to be updated regularly and you can automate this by adding /usr/local/bin/freshclam –quiet >/dev/nul 2>&1 to the crontab. We run ours every 13 hours.
MailScanner-MRTG is a package that automatically generates the configuration to build MRTG graphs for your MailScanner installation, graphing information including total emails, captured spam and spam ratio. These graphs not only please your manager but also help you identify how your gateway is handling the load of emails filtered, if there is a sudden spike in email traffic and how effective SpamAssassin really is.
MailScanner-MRTG requires httpd, net-snmp and net-snmp-utils. You can install this with yum install httpd net-snmp net-snmp-devel net-snmp-utils. YUM will take care of your dependency problems for you. MailScanner-MRTG comes in a nice simple to install RPM. A source version is also available. By default the RPM will install the graphs to /var/www/html/mailscanner-mrtg. If you would like to customise this at installation time you will need to use the source. You can find MailScanner-MRTG here.
This is as far as I will go with this guide. I will shortly add a guide on how to allow your customers to manage their own rulesets. We are yet to iron out the bugs in this ourselves.
As a side note the original server we configured did not cope with the load we put on it. I am expecting a replacement server to be put in later today. I will post some performance details when we have some more information.