I use Chirpy’s oft-maligned MailScanner package. Despite the complaints about it, no one has put together something better, and Chirpy’s package works well, is easy to administer, and the Cpanel client front-end that comes with their installation package makes it easy for clients to configure their personal settings, all pretty important things to consider in my book.
So I thought I would share my various MailScanner and Exim tweaks that I use to make the two work better and reduce the load on the server. Some of them come from other posts in this forum, and some come the Exim and MailScanner sites. They have worked well for me, but your mileage may vary.
If you have any others, please share them with us.
These are in no particular order, but I’ve added my comments and experiences with each.
1. Use a ramdisk for MailScanner’s work directory.
This was very easy to do and has helped reduced both server load and queue processing time. This is especially noticeable when dealing with large mailing lists or messages with large attachments.
First, create a ramdisk using tmpfs. It needs to be remounted at every boot, so adding it to /etc/fstab is the easiest. Use vi or your favorite editor to open /etc/fstab and add a line like this:
none /var/mailscanner tmpfs size=100m 0 0
/var/mailscanner is the mount point for the ramdisk, and the size option sets the amount of memory to use.
Second, go ahead and mount your new ramdisk:
#mount /var/mailscanner
You can do df -vh to make sure it has mounted if you like.
Third, tell MailScanner to use the new ramdisk as its working directory. If you use the WHM front-end, just click on the MailScanner Configuration button to edit the file. Otherwise, it is usually located at /usr/mailscanner/etc/MailScanner.conf
In your MailScanner configuration file, find the line that begins:
Incoming Work Dir =
and set it to your ramdisk. For Example:
Incoming Work Dir = /var/mailscanner
Finally, save your changes to the MailScanner configuration, and restart the service manually if you aren’t using the WHM front-end to edit the file.
Determining the right size to use for the ramdisk is tricky. I originally used 20m, and MailScanner ran happily for several days until it choked without warning. This happened a couple of times before I realized it was choking because it had run out of workspace on the ramdisk. My current setting of 100mb is probably not optimal, and is based on educated guessing as follows. If anyone can provide a better method for calculating this, I’d love to hear it.
My suggestion would be to find these lines in your MailScanner configuration:
Max Unscanned Bytes Per Scan = (Mine is set to 50m)
Max Unsafe Bytes Per Scan = (Mine is set to 30m)
I recommend twice the Max Unscanned Byters Per Scan unless your mail usage would suggest otherwise. Theoretically, your ramdisk size needs to be at least as big as Max Unscanned Bytes Per Scan, but in reality, if Max Unscanned Byters Per Scan determined the size of the every batch, your ramdisk would need to be at least two or three times that size to accommodate expanding compressed files. Fortunately, the next two lines under those also limit the number of messages per scan:
Max Unscanned Messages Per Scan = (Mine are both at 30)
Max Unsafe Messages Per Scan =
So MailScanner will scan 30 messages per scan, unless 30 would put it over the size limits above in which case it would scan fewer messages. Most of the time, this means you probably wouldn’t need more than 2-3mb of space except when large attachments are being sent. Then the size limit in Max Unscanned Bytes Per Scan will come into play. Consider what your numbers for these options are, and make an educated guess.
Using twice the Max Unscanned Bytes has not caused me any problems in the five or six months I’ve used it, but your mileage may vary.
2. Offload blacklist checking to Exim
I hated doing this because I believe clients should get every piece of mail so *they* can determine what’s spam and what’s not, and to protect that occasional mis-marked non-spam message out there, but the volume of spam the server received finally forced me to do it. This has made a *big* difference in terms of the loads put on the system by both Exim and MailScanner. Instead of processing 12-15K messages a day, MailScanner now only has to deal with ~4K because the rest are dropped before receipt.
Place this in the second ACL box in the advanced Exim configuration editor:
deny message = Message rejected - $sender_fullhost is in an RBL, see $dnslist_text
!hosts = +relay_hosts
!authenticated = *
dnslists = bl.spamcop.net : sbl-xbl.spamhaus.org
Where it goes in the box will depend on your configuration. I use Chirpy’s dictionary attack ACL, and place this right after it. That puts it above this line:
# Accept bounces to lists even if callbacks or other checks would fail
You may need to put it elsewhere.
3. Keep the MailWatch database clean
If you use Chirpy’s package, you probably have MailWatch installed. MailWatch is great for keeping an eye on what’s happening with mail and spam, and for training the Bayesian filter. However, the default install never seems to clean out the accumulated messages in the database (as opposed to the quarantine). After a while, accessing the database starts to get slow, and MailScanner performance suffers. I encountered this when loading a MailWatch page went from taking seconds to minutes.
You can execute a simple cron job to keep it clean and moving swiftly.
First, create a small shell script to trim the database. Use vi or your favorite editor to create a file named mailwatch_mysql_maintenance.sql with these lines:
delete from maillog where timestamp < date_sub(curdate(), interval 14 day);
optimize table maillog;
Second, add the following line to your crontab, editing as appropriate:
0 10 * * * /path/to/mysql mailwatch_database -u mailwatch_user --password=mailwatch_password < /path/to/mailwatch_mysql_maintenance.sql
This will run nightly and delete messages that are over 14 days old, keeping your database manageable and speedy.
4. Let Exim drop senders who only use IPs
This came from another thread in this forum. Like moving RBL checking to Exim, it helps reduce MailScanner loads by reducing the number of messages MailScanner has to deal with.
Place this in the first ACL box in the advanced Exim configuration editor:
check_helo:
################################################## ###
# IP Only is sent as the HELO
deny condition = ${if match {$sender_helo_name}\
{^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$}\
{yes}{no}}
message = Your server announces itself ($sender_helo_name) with a plain IP address which is in breach of RFC2821.
log_message = Bad HELO: IP Only Announce
################################################## ###
accept
So I thought I would share my various MailScanner and Exim tweaks that I use to make the two work better and reduce the load on the server. Some of them come from other posts in this forum, and some come the Exim and MailScanner sites. They have worked well for me, but your mileage may vary.
If you have any others, please share them with us.
These are in no particular order, but I’ve added my comments and experiences with each.
1. Use a ramdisk for MailScanner’s work directory.
This was very easy to do and has helped reduced both server load and queue processing time. This is especially noticeable when dealing with large mailing lists or messages with large attachments.
First, create a ramdisk using tmpfs. It needs to be remounted at every boot, so adding it to /etc/fstab is the easiest. Use vi or your favorite editor to open /etc/fstab and add a line like this:
none /var/mailscanner tmpfs size=100m 0 0
/var/mailscanner is the mount point for the ramdisk, and the size option sets the amount of memory to use.
Second, go ahead and mount your new ramdisk:
#mount /var/mailscanner
You can do df -vh to make sure it has mounted if you like.
Third, tell MailScanner to use the new ramdisk as its working directory. If you use the WHM front-end, just click on the MailScanner Configuration button to edit the file. Otherwise, it is usually located at /usr/mailscanner/etc/MailScanner.conf
In your MailScanner configuration file, find the line that begins:
Incoming Work Dir =
and set it to your ramdisk. For Example:
Incoming Work Dir = /var/mailscanner
Finally, save your changes to the MailScanner configuration, and restart the service manually if you aren’t using the WHM front-end to edit the file.
Determining the right size to use for the ramdisk is tricky. I originally used 20m, and MailScanner ran happily for several days until it choked without warning. This happened a couple of times before I realized it was choking because it had run out of workspace on the ramdisk. My current setting of 100mb is probably not optimal, and is based on educated guessing as follows. If anyone can provide a better method for calculating this, I’d love to hear it.
My suggestion would be to find these lines in your MailScanner configuration:
Max Unscanned Bytes Per Scan = (Mine is set to 50m)
Max Unsafe Bytes Per Scan = (Mine is set to 30m)
I recommend twice the Max Unscanned Byters Per Scan unless your mail usage would suggest otherwise. Theoretically, your ramdisk size needs to be at least as big as Max Unscanned Bytes Per Scan, but in reality, if Max Unscanned Byters Per Scan determined the size of the every batch, your ramdisk would need to be at least two or three times that size to accommodate expanding compressed files. Fortunately, the next two lines under those also limit the number of messages per scan:
Max Unscanned Messages Per Scan = (Mine are both at 30)
Max Unsafe Messages Per Scan =
So MailScanner will scan 30 messages per scan, unless 30 would put it over the size limits above in which case it would scan fewer messages. Most of the time, this means you probably wouldn’t need more than 2-3mb of space except when large attachments are being sent. Then the size limit in Max Unscanned Bytes Per Scan will come into play. Consider what your numbers for these options are, and make an educated guess.
Using twice the Max Unscanned Bytes has not caused me any problems in the five or six months I’ve used it, but your mileage may vary.2. Offload blacklist checking to Exim
I hated doing this because I believe clients should get every piece of mail so *they* can determine what’s spam and what’s not, and to protect that occasional mis-marked non-spam message out there, but the volume of spam the server received finally forced me to do it. This has made a *big* difference in terms of the loads put on the system by both Exim and MailScanner. Instead of processing 12-15K messages a day, MailScanner now only has to deal with ~4K because the rest are dropped before receipt.
Place this in the second ACL box in the advanced Exim configuration editor:
deny message = Message rejected - $sender_fullhost is in an RBL, see $dnslist_text
!hosts = +relay_hosts
!authenticated = *
dnslists = bl.spamcop.net : sbl-xbl.spamhaus.org
Where it goes in the box will depend on your configuration. I use Chirpy’s dictionary attack ACL, and place this right after it. That puts it above this line:
# Accept bounces to lists even if callbacks or other checks would fail
You may need to put it elsewhere.
3. Keep the MailWatch database clean
If you use Chirpy’s package, you probably have MailWatch installed. MailWatch is great for keeping an eye on what’s happening with mail and spam, and for training the Bayesian filter. However, the default install never seems to clean out the accumulated messages in the database (as opposed to the quarantine). After a while, accessing the database starts to get slow, and MailScanner performance suffers. I encountered this when loading a MailWatch page went from taking seconds to minutes.
You can execute a simple cron job to keep it clean and moving swiftly.
First, create a small shell script to trim the database. Use vi or your favorite editor to create a file named mailwatch_mysql_maintenance.sql with these lines:
delete from maillog where timestamp < date_sub(curdate(), interval 14 day);
optimize table maillog;
Second, add the following line to your crontab, editing as appropriate:
0 10 * * * /path/to/mysql mailwatch_database -u mailwatch_user --password=mailwatch_password < /path/to/mailwatch_mysql_maintenance.sql
This will run nightly and delete messages that are over 14 days old, keeping your database manageable and speedy.
4. Let Exim drop senders who only use IPs
This came from another thread in this forum. Like moving RBL checking to Exim, it helps reduce MailScanner loads by reducing the number of messages MailScanner has to deal with.
Place this in the first ACL box in the advanced Exim configuration editor:
check_helo:
################################################## ###
# IP Only is sent as the HELO
deny condition = ${if match {$sender_helo_name}\
{^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$}\
{yes}{no}}
message = Your server announces itself ($sender_helo_name) with a plain IP address which is in breach of RFC2821.
log_message = Bad HELO: IP Only Announce
################################################## ###
accept
