In implementation, this is very similar to the way I did it with the original qmail-scanner project for PSA, the main difference is that I'm using a completely different implementation of qmail based on the qmail RPM created by Bruce Guenter. Project Gamera consists of an MTA (qmail for now), a secondary mail-queue using qmail-scanner, tcpserver to handle connections, spamassassin and razor to handle spam detection, clamav to handle anti-virus.


Features
* Clusterable, you can create as many Gamera servers as you want, load balancing is done with MX records
* Anti-Spam protection using Spamassassin
* Anti-Spam protection using Razor (Cloudmark), DCC, and Pyzor
* Anti-Virus protection using ClamAV
* Per-User configurations of Spamassassin rules using an external mysql server, and a web frontend (squirrelmail)
* Per-domain configurations
* Can act as a backup mailhost


Installation
Project Gamera is designed to be installed on CentOS 4/5, RHEL 4/5, and Fedora 4+. Do not attempt to install Project Gamera on a Plesk system. 
Step 1) Configure yum to use the [atomic] channel.

  wget -q -O - http://www.atomicorp.com/installers/atomic |sh

Step 2) Remove the sendmail package:

  yum -y remove sendmail

Step 3) Install Project Gamera:

  yum -y install project-gamera

Step 4) reboot

Configuration
Basic configuration of a Gamera server is done from 2 files
/var/qmail/control/rcpthosts - this file tells the server what domains to recieve mail for. The file lists one domain per line, example:
atomicrocketturtle.com

/var/qmail/control/smtproutes - this file tells the gamera server where to send mail it recieves for a domain. The file lists one domain, followed by a colon, followed by the hostname or IP address to send the mail for that domain to. Example:
atomicrocketturtle.com:10.10.12.1

Once those files have been configured, all you need to do is update your DNS MX records for those domains to point to your Gamera server(s). Adding multiple MX records for the domain allows you to cluster as many gamera servers as you want, and in addition in the event that the Gamera servers are not available fail over to the real mail server. Example:
atomicrocketturtle.com. IN MX 10 gamera-1.atomicrocketturtle.com.
atomicrocketturtle.com. IN MX 10 gamera-2.atomicrocketturtle.com.
atomicrocketturtle.com. IN MX 100 mail.atomicrocketturtle.com.

Advanced configuration, this is directly from the qmail-scanner documentation:

#/etc/tcpserver/smtp.rules
#
# No Qmail-Scanner at all for mail from 127.0.0.1
127.:allow,RELAYCLIENT="",RBLSMTPD="",QMAILQUEUE="/var/qmail/bin/qmail-queue"
# Use Qmail-Scanner without SpamAssassin on any mail from the local network
# [it triggers SpamAssassin via the presence of the RELAYCLIENT var]
10.:allow,RELAYCLIENT="",RBLSMTPD="",QMAILQUEUE="/var/qmail/bin/qmail-scanner-queue.pl"

#
# Use Qmail-Scanner with SpamAssassin on any mail from the rest of the world
:allow,QMAILQUEUE="/var/qmail/bin/qmail-scanner-queue.pl"

The above example means from now on all SMTP mail will be scanned, but with different characteristics. Mail from the LAN (10. network) will be scanned by the supported virus scanners, whereas mail from the Internet will be scanned for virii AND tagged by SpamAssassin. This finer control allows you a lot of versatility, e.g. virus scanning only performed on mail coming from your Exchange server, and not from your Unix servers.

By default the system is configured to scan for virii, and spam on all domains.

Per-User configurations, at present this is only available with spamassassin, first you'll need a mysql server, which can run anywhere on your network, I dont recommend running it on the gamera server itself unless you're not handling a lot of mail.
Step 1) change /etc/sysconfig/spamassassin to this:
SPAMDOPTIONS="-d -u qmailq -q -x -c -a -m30"
Step 2) change /etc/mail/spamassassin/local.cf to include these lines

user_scores_dsn                        DBI:mysql:<DATABASE>:<HOSTNAME>
user_scores_sql_username    <USERNAME>
user_scores_sql_table              <TABLENAME>
user_scores_sql_password     <PASSWORD>

Step 3) restart spamd
Now you can tie in any 3rd party front end you want to use to configure those settings, I created a squirrelmail rpm with a spamassassin plugin based on perlboy's rpm. That rpm is configured to work with a PSA server, so unless your Gamera server is pointing to your PSA server's horde database its not going to work without tweaking.


Tuning Notes
Use more than one of these I use 2 PG systems, named "ac1" at MX 5, and "ac2" at MX 100. I've found that the spammer MTA's will always go for the higher level MX, assuming that is your "real" MTA, to bypass something like PG. If you can't have 2 PG boxes, and still want your "Real" server in the mix, sandwich it between an MX 5 and an MX 100 that point to your PG box.

Delete if you can, reject if you must rejects will fill up your queue, if that gets too high, its going to slow down deliveries to your real mail server. I set my delete threshold to 1, and required_hits to 4 (so I delete at 5). I also set my /var/qmail/control/concurrencyremote to 1000.

Tune bayes the default for bayes is to learn spam at 12.0 and above, and ham at .1 and below. Thats way to vague, spam can poison your DB pretty quickly on a new box, so I set my /etc/mail/spamassassin/local.cf to:

# bayes_auto_learn_threshold_nonspam -5.0 # this is too low
bayes_auto_learn_threshold_nonspam -1.0
bayes_auto_learn_threshold_spam 5.0

Increase RBL scores URISBL is a pretty powerful test, it looks for URL's used in spam messages, as opposed to looking at sender IP's. Set the following in /etc/mail/spamassassin/local.cf
score URIBL_SBL 5.0

Mysql Settings

• Store your databases in innodb format, especially for bayes_tokens, bayes_seen, and awl.

• optimize your tables weekly (SQL: optimize table <tablename>

• Spamassassin will store bayesian tokens for 6 months, and then automatically expire them. It uses SQL syntax along these lines:

DELETE from bayes_token where id = $ID and atime < $ATIME

the gotcha here is that spamassassin checks to see how many tokens will be deleted first, and if it exceeds the threshold (100,000 I think), it will not expire those tokens. This will probably only effect you if you're training large pools of spam/ham in a day, which is what I do so I ended up with 47,000,000 rows in my bayes_token table.

• AWL will also need to be cleaned periodically, for the moment Im using:

DELETE FROM awl WHERE count = 1

I'll probably change this to one of these:

DELETE FROM awl WHERE lastupdate <= DATE_SUB(SYSDATE(), INTERVAL 6 MONTH);

DELETE FROM awl WHERE count = 1 AND lastupdate <= DATE_SUB(SYSDATE(), INTERVAL 15 DAY);

Disclaimer Questions, comments, etc can be directed to me, scott AT atomicrocketturtle.com. No warranty, expressed or implied, yadda yadda. If this breaks things on your server, I'll be sad for you, but not responsible. :)

Only registered users can write comments.
Please login or register.

Powered by AkoComment 2.0.3!