Configuring an Open Source Mail Gateway

harrypotter

quote from www.freshmeat.net

No matter whether you work for a large business or use email simply for family communication, you've probably received junk mail. If you have used email for any length of time, you probably know what it's like to deal with a virus. Unfortunately, fending off unwanted or dangerous electronic communication has become a daily struggle for many system administrators.

Copyright notice: All reader-contributed material on freshmeat.net is the property and responsibility of its author; for reprint rights, please contact the author directly.

The Problem

Although many virus detection and spam filtering programs exist, most are expensive or difficult to administer. Often, viruses and spam are treated as two separate problems, and thus handled in different ways. Viruses are usually perceived as a greater threat, so more resources are dedicated to virus detection while junk mail problems go virtually ignored.

In many cases, virus infection is dealt with in a reactive manner; if a user receives a virus, the system administrator relies on installed virus software to detect and destroy it. However, if some type of automatic updating system is not in place, someone from technical support must be dispatched to eradicate the virus; this is often a very time-consuming process. Workstation-based virus detection works for small businesses, but as a company grows, it becomes increasingly difficult to handle viruses using only a problem-response system.

Fighting spam presents an even greater challenge to the overloaded system administrator. Most email clients provide some type of rules-based sorting system, but who has time to configure each user's filtering rules? More importantly, who wants to be tasked with the responsibility of creating a rule set which checks for every foul, sordid, and disgusting word in the English language? Open mail relay databases exist, but it doesn't take long to find out what happens when your SMTP server rejects a critical piece of client email. Sadly, many system administrators still don't know that the company's server is being used as a relay for thousands of junk email messages.

The combination of these factors has caused many system administrators to give up in despair. A rash of false positives or the cost-prohibitive nature of the solution usually results in the continuation of the status quo. However, the existence of Open Source software means that the problem need not be perpetual.
The Solution

With the proper interconnection of Linux software, even a small network can be protected from the ravages of undesired email. There are actually several different combinations that can be used to accomplish this goal, but this article will focus only on one of them. Programs vary in their support for mail servers or virus detection software, but by far, one of the most versatile programs is AMaViS.

The somewhat unwieldy acronym stands for A Mail Virus Scanner, which provides a basic description of the program. On the most basic level, AMaViS acts as an interface between an email server and a virus scanner. Written in Perl, it exists in a number of different varieties. Its latest incarnation is amavisd-new, which is an updated version of the daemonized edition of the script. It uses a number of Perl modules to act as a simple SMTP relay which runs in conjunction with the primary mail software. One additional feature of amavisd-new is support for SpamAssassin, which allows virus and spam filtering to be combined into one server. amavisd-new supports several dozen antivirus scanners and will interoperate with almost any mail server that speaks SMTP.

SpamAssassin is the other key component to a solid virus and spam filtering mail gateway. Unlike other rule-based junk mail filtering tools, SpamAssassin uses a complex point system to determine whether an email should be accepted or rejected. Instead of allowing or denying a piece of mail based on one rule, SpamAssassin allows you to set the point value at which mail will be dropped. This allows the system administrator to tweak the configuration easily depending on how many false positives are reported.

Although a number of Linux virus scanners exist, I have found Clam AntiVirus to be one of the best. While it does not have commercial support from the likes of McAfee or Sophos, it is completely free for business or personal use. It is well documented and uses a frequently-updated database from OpenAntiVirus, which also has free virus scanning software. It also includes a simple updating program which can be run through cron to keep the local virus database fresh. The selection of a virus scanner is important, but as long as you use one that is frequently updated and supported by AMaViS, the choice is up to you.

This article will deal with configuring Postfix as the primary mailer daemon, but other programs, such as Sendmail or Exim, can be used as well. I recommend Postfix for its stability, security, and ease of configuration, but the AMaViS documentation contains instructions for working with other SMTP software. This article assumes that you have a working Postfix configuration and that you are familiar with the basic functions of the SMTP protocol.
Installing Required Software

When writing a configuration guide, one must always keep in mind the vast variety of Linux versions that exist. This article is no exception. The sample installation was performed on a standard Red Hat 8.0 installation. Most of the steps documented below are non-distribution specific, but as always, your mileage may vary.
Clam AntiVirus

Assuming you have a working Postfix install, the first thing to do is install a virus scanner. After downloading the latest version, untar the package by typing:

tar zxvf clamav*

Next, add a user under which the program will run:

useradd -s /bin/false -c "Clam AntiVirus" clamav

Then, go to the directory of extracted source code and install the program:

./configure
make
make install

Unless otherwise specified, this will install the compiled binaries in /usr/local/bin. Several test files are located in the test directory of the Clam AntiVirus source code. To test the virus scanner, enter:

clamscan test1

If the scanner is working correctly, you should see the following output:

test1: ClamAV-Test-Signature FOUND

Now would be a good time to make sure that Clam AntiVirus has the latest virus definitions. To update the definitions database, enter:

freshclam

You should receive the following output:

Checking for a new database - started [date]
Current working dir is /usr/local/share/clamav
Connected to clamav.elektrapro.com.
Reading md5 sum (viruses.md5): OK
Reading md5 sum (viruses2.md5): OK
viruses.db2 is up to date.
Downloading viruses.db ... done

Finally, place a script in the system's cron.daily directory to run freshclam in quiet mode once a day. Here's a sample script:

#!/bin/bash
/usr/local/bin/freshclam --quiet

The Clam AntiVirus installation is now complete.
SpamAssassin

SpamAssassin requires two Perl modules which are not installed by default on Red Hat 8.0. They are perl-HTML-Tagset and perl-HTML-Parser. Both are included in the Red Hat 8.0 distribution and can be installed via RPM. After installing both Perl modules, download the SpamAssassin RPMs. Both spamassassin-2.5.0-1.i386.rpm and perl-Mail-SpamAssassin-2.5.0-1.rpm are required for installation. If you prefer, you can download and compile the source code from SpamAssassin's homepage. To install SpamAssassin using RPM, enter:

rpm -ivh perl-Mail-Spam* spam*

AMaViS handles the SpamAssassin configuration, so nothing needs to be modified after the initial SpamAssassin installation. Test SpamAssassin using the sample files located in /usr/share/doc/spamassassin-2.5.0. To see a report from a piece of known spam, enter:

spamassassin -t < sample-spam.txt

At the end of the output, you should see a report of the points that the email received and a break down of which rules it violated. The sample piece of spam should receive a score report that includes the following line:

SPAM: Content analysis details:   (14.70 hits, 5 required)

To test a piece of non-spam, enter:

spamassassin -t < sample-nonspam.txt

You should see the following results in the content report:

SPAM: Content analysis details:   (0.90 hits, 5 required)

SpamAssassin is now installed and ready for use.
amavisd-new

Installing AMaViS is a bit more complicated than the preceding packages because it requires a number of Perl modules and file compression utilities. Unfortunately, the current version of amavisd-new does not seem to properly log virus-infected email when run with Perl 5.8.0, which comes installed on Red Hat 8.0. The easiest way to solve this problem is simply to uninstall the 5.8.0 RPM and install the 5.6.1 RPM included with Red Hat 7.3.

Before installing the Perl modules, several file compression utilities should be installed. These utilities include:

arc
unarj
unrar
zoo

RPMs for these utilities are available from http://www.rpmfind.net/. Only the unarj utility is included in the Red Hat 8.0 distribution. Once the correct version of Perl and the file compression utilities are installed, the installation of the Perl modules can begin.

http://www.rmorales.com.ar/rpms/amavis/, maintained by Ramiro Morales, contains an excellent breakdown of the Perl modules required for each version of Red Hat. For installation on Red Hat 8.0, here is a list of the required modules:

Archive-Tar-0.22
Archive-Zip-1.01
Compress-Zlib-1.16
Convert-TNEF-0.17
Convert-UUlib-0.212
Digest-MD5-2.16
File-MMagic-1.15
IO-stringy-2.108
libnet-1.12
MailTools-1.46
MIME-tools-5.411
MIME-Base64-2.12
Net-Server-0.84
Unix-Syslog-0.99

The source code for each module can be obtained from CPAN. One way to install the modules is by downloading the source and using a simple shell script to unpack, build, and install each one. Place all the source code in one directory and create a script with the following code:

#!/bin/bash

# Create a directory for the compressed source code
mkdir tars

# Untar modules
for x in /module-directory/*gz
do tar zxvf $x; mv $x tars;
done

# Build and Install all modules
for x in /module-directory/*-*
do cd $x; perl Makefile.PL; make; make install;
done

Modules can also be installed using the CPAN shell or Webmin, which both automate the entire process.

After installing all the required third-party modules, the actual amavisd-new installation is fairly straightforward. It requires no compilation; only three files need to copied, and several directories must be created. First of all, untar amavisd-new using the following command:

tar zxvf amavisd-new*

Before copying the files to their appropriate locations, make sure that all the files have the proper ownership:

chown root.root amavisd
chown root.root amavisd.conf
chown root.root amavisd_init.sh

After changing the owners, copy each file to its appropriate location:

cp amavisd /usr/sbin
cp amavisd.conf /etc
cp amavisd_init.sh /etc/rc.d/init.d/amavisd

The permissions on the included init script should be changed, and amavisd should then be configured to start on boot using the following commands:

chmod 755 /etc/rc.d/init.d/amavisd
chkconfig --level 2345 amavisd on

amavisd-new requires several temporary directories and a separate user as which to run. Create a user named amavis using the following command:

useradd -s /bin/false amavis

The following directories should be created with the permissions and owners listed:

mkdir /var/amavis
chmod 750 /var/amavis
chown amavis.amavis /var/amavis

mkdir /var/virusmails
chmod 750 /var/virusmails
chown amavis.amavis /var/virusmails

The amavisd-new installation is now complete.
Configuration
AMaViS

There are several configuration options which should be modified before AMaViS is used in a production environment. All configuration options are located in /etc/amavisd.conf. The changes relate primarily to the email addresses used for notification. AMaViS will send email messages with the address specified in the configuration file, so these should be changed before the server is put into production use. The variables are:

$mailfrom_notify_admin     = 'virusalert@example.com';
$mailfrom_notify_recip     = 'virusalert@example.com';
$mailfrom_notify_spamadmin = 'spam.police@example.com';

These email addresses should be changed to the address of the person who will be receiving administrative notifications about viruses and spam. These address allow the user to reply to the email and have it go to the correct person. The next two settings are the email addresses of the administrator who will receive notifications from the mail system. These settings are:

$virus_admin = 'virus-admin@example.com';
$spam_admin  = 'virus-admin@example.com';

The other important configuration options are the settings for SpamAssassin. These settings dictate what to do with mail which contains spam and viruses. By default, virus-infected email messages are quarantined on the server and not sent to the user. Spam is also dropped, but an SMTP error is sent to the offending user. Here are the settings:

$final_virus_destiny  =  0;
$final_spam_destiny   = -1;

AMaViS can be configured to simply tag what it believes is spam and then forward it to the user. If this configuration is desired, $final_spam_destiny should be set to 1. There are only two vital configuration options for SpamAssassin:

$sa_tag_level_deflt  = 4;
$sa_kill_level_deflt = 6.9;

These are the default values for SpamAssassin used by AMaViS. The tag level variable establishes the threshold at which spam info will be added to the header of the message. When spam reaches the kill level, it will either be dropped or passed to the user, depending on the setting of $final_spam_destiny. If spam is passed to the user, ***SPAM*** will be added to the subject line of the message, making it clearly visible.

The kill level is the key to controlling spam. If it is too high, spam will get through; if it is too low, false positives will be generated. The default value is a fairly good one; it will generate a few false positives, but not many. Anything over 10 is almost always spam. The best way to determine the appropriate value is through experience. By monitoring the log closely for the first several days, the system administrator can determine whether the setting needs to be changed.

AMaViS will automatically detect which virus scanner you have installed. By default, it accepts connection over port 10024 on the localhost address. Unless there is a special need, this setting should not be modified. The AMaViS configuration file is very well documented; read the comments before performing any modifications. After making all appropriate configuration changes, start AMaViS using the following command:

/etc/rc.d/init.d/amavisd start

If you are running Red Hat, you can use the "service" command to start and stop AMaViS:

service amavisd start

If everything is installed and configured properly, you should not receive any errors. Check /var/log/maillog for details on the AMaViS startup process.
Postfix

Fortunately, configuring Postfix is the easiest part of the setup. If everything has worked thus far, the final steps will go smoothly. Postfix uses AMaViS through its content filtering feature, which is configured through main.cf and master.cf. To point the Postfix content filter to AMaViS, add the following line to main.cf:

content_filter = smtp:localhost:10024

If you are using a port other than 10024, make sure the content filter setting reflects the correct port. After specifying the destination of the content filter, the following two lines must be added to master.cf:

smtp-amavis unix -  -  -  -  2  smtp -o smtp_data_done_timeout=1200 -o disable_dns_lookups=yes

localhost:10025 inet n  -  -  -  -  smtpd -o content_filter=

The first line allows AMaViS to send scanned mail back to Postfix over a Unix port. The second line configures another instance of Postfix which will send new mail to the AMaViS daemon. After making the configuration changes, restart Postfix. If everything is running properly, running "netstat -ln" should yield the following results:

tcp       0        0 127.0.0.1:10024        0.0.0.0:*        LISTEN
tcp       0        0 127.0.0.1:10025        0.0.0.0:*        LISTEN
tcp       0        0 0.0.0.0:25                0.0.0.0:*        LISTEN

If Postfix is functioning correctly, several tests should be performed to ensure that the filtering system is working properly.
Testing Filtering Capabilities

Three basic email tests should be performed. The first should be a message with a sample virus, the second should be a sample piece of spam, and the third should be a clean message. The tests can be done from the commandline of the Postfix server or from an email client residing on another computer. Since Clam AntiVirus and SpamAssassin come with a sample virus and a sample piece of spam, it may be easiest to perform the tests from the commandline. To send a sample virus, go to the "test" directory of the Clam AntiVirus source code and enter the following command:

cat test1 |mail -s "sample virus" yourname@yourdomain.com

This will send the contents of "test1" to the email address you specify. After entering the command, check the last few lines of /var/log/maillog. There should be a line which contains "VIRUS" followed by the name of the virus found. If AMaViS correctly identified the virus, test spam filtering by going to /usr/share/doc/spamassassin-2.50 and entering:

cat sample-spam.txt |mail -s "sample spam" yourname@yourdomain.com

Once again, check the contents of /var/log/maillog. You should find a line which contains "SPAM" as well as the rules violated and the hits counted by SpamAssassin. If your Postfix server is configured correctly, you should also receive notifications for both the sample virus and sample spam email messages in the account specified in the AMaViS configuration file. Finally, send the "sample-nonspam.txt" file to confirm that AMaViS allows clean messages through:

cat sample-nonspam.txt |mail -s "sample non-spam" yourname@yourdomain.com

If AMaViS is working correctly, no special logs should be created and the message should be forwarded to its final destination. If these three tests yield the proper results, the server is ready to be placed in a production environment.
Conclusion

With the right tools, Linux can provide a cost-effective means of freeing a network from unwanted email. A network of any size can benefit from the installation of an Open Source mail gateway. Not only does this solution free individual users from the headaches of viruses and the annoyances of spam, it allows the technical support staff to devote their valuable resources to areas other than fighting virus infections. No solution is perfect, and filtering spam is particularly difficult, but with these tools, the task can be made much easier.

冰块

哦。i like this one