Versions: | - sendmail 8.13.6 |
| - dovecot 1.0 |
| - clamav 0.88.2 |
| - clamav-milter 0.88.2 |
| - spamassassin 3.1.3 |
Basic Configuration Dovecot IMAP Server Starting The Services Preventing Abuse Full SSL/TLS Encryption Clam Antivirus SpamAssassin Sending emails to multiple recipients scattered around the world these days is such an easy everyday task, that its hard to image life without it. Sending an email through the Internet uses many different protocols and applications that all work seamlessly to ensure your message reaches its end destination.
This chapter will provide assistance in the configuration of your own server for sending and receiving emails, and will also provide details on some extra applications to ensure your system remains secure and relatively virus free. In
chapter 13, we will configure a webmail application which provides a means to send and receive email while away from home. To make proper use of an email system requires the server to be configured with a fully registered Internet domain name; DNS is used extensively for email. In
chapter 20 we will configure LDAP to provide our network with a share address book (with SSL) to be used by internal and/or roaming clients.
Before we begin, here are some of the basic components that help to make up the email world:
MUA: Mail User Agent | The email application that a user sends/receives (thunderbird,pine,outlook) |
MTA: Mail Transport Agent | The server agent responsible for sending the emails (sendmail,postfix,qmail) |
MDA: Mail Delivery Agent | The server agent that accepts email from MTA, and places into users mailbox (procmail) |
SMTP: Simple Mail Transport Protocol | MUAs and MTAs use this protocol for sending emails |
POP3: Post Office Protocol (Ver 3) | MUAs use this protocol for receiving their emails from the final server |
IMAP: Internet Message Access Protocol | MUAs can use this protocol to send and receive emails on the servers |
Procmail is normally installed and running on most systems already so it won't be covered here.
| The preferred email protocol for this configuration is IMAPS as all emails are stored on the main server and then replicated through to your MUA client when it connects. Because the mail files on the server and client are synchronised, the webmail application will have all the emails contained on your local workstation and vice versa, including sent emails. |
Sendmail
We are going to configure the MTA first, and the package that is most commonly used is
sendmail. The configuration files for sendmail are extremely technical for new users, and should definately be backed up before making any changes, they are so complex in fact that one configuration file is actually used to configure the second file.
The important thing to remember is that we will make the changes only in the
sendmail.mc file, and the changes will be moved into the
sendmail.cf file for us. This is the preferred method for configuring sendmail.
[bash]# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.original |
| Do not edit sendmail's "cf" file, use the "mc" macro file to make the changes. This backup is only a precautionary measure in case everything goes bad. |
[bash]# cp /etc/mail/sendmail.mc /etc/mail/sendmail.mc.original [bash]# vi /etc/mail/sendmail.mc |
Inside the sendmail macro file, there are many lines that start and end with "
dnl". This acronym stands for "delete through newline", and is used to tell the macro process to ignore the current line when building the new sendmail.cf file. This should be treated just like a standard configuration comment.
When sendmail dispatches your email, it places the servers hostname behind your username, which becomes the "from address" in the email (ie. user@galaxy.example.com). Normally we only want to use the domainname and not the hostname, this setting allows all outgoing emails to be "user@example.com", the preferred method.
define(`confDOMAIN_NAME', `example.com')dnl FEATURE(`relay_entire_domain')dnl |
Email can be sent via a smarthost if the Internet connection is not on all the time. This needs configuring at your ISP or by whoever is providing your smarthost capability. This is generally not required on a dedicated link.
dnl define(`SMART_HOST',`smtp.your.provider')dnl |
Below are some daemon options that specify (basically) who can connect and send emails. The top one (default) only allows emails to be sent from by the local server. The default options need to be adjusted before the server will accept emails from any other networked computer.
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl | Only local server can send email |
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl | Users can now connect to send email |
The aliases and virtusertable ("
/etc/mail/virtusertable") are lists that allow incoming emails to be redirected to other local accounts or external email addresses. See "
man aliases" or README for details on these files.
Many of the applications on the server are configured to send email to the root account when problems occur. It is recommended that an entry be placed into the /etc/aliases file to redirect all of root's email to the supervisors standard user account. This saves having to check the root account for emails as they can be automatically sent to another valid account.
define(`ALIAS_FILE', `/etc/aliases')dnl |
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl |
| If alias file (/etc/aliases) is adjusted, it needs to be updated with the "newaliases" command before settings are implemented. |
The access database ("
/etc/mail/access") is a list of IP addresses and domainnames of allowable connections. Your IP subnet and other details need to be placed in here before you can send email, ensuring that you leave the localhost information as configured.
FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl |
# Example of /etc/mail/access localhost.localdomain RELAY localhost RELAY 127.0.0.1 RELAY 192.168.1 RELAY example.com RELAY |
Before accepting emails, sendmail can do a DNS lookup on the address of the person who is sending the email. It is recommended that this option be set up so that any email failing a DNS lookup is rejected; there is a fair chance the email was not sent from a valid domain name and possibly spoofed. Comment the following line to enable DNS lookup.
dnl FEATURE(`accept_unresolvable_domains')dnl |
| You should consult the README file for further details on available settings ("/usr/share/sendmail-cf/README"). |
Mail Aliases - Who gets Who's Email
Sendmail includes a standard
"/etc/aliases" file that can be used to redirect certain emails to a single user on the system, a group of users, or even to an email address external of the mail system (i.e. to another organisation). The basic alias file looks similar to below, it contains an alias on the left side followed by a colon and then the list of users that will receive the email, listed on the right hand side.
It is important to nominate an account to redirect all the system emails to, i.e. a "root" alias. This ensures that any system orientated alerts are directed to an individual who can monitor the system's status and warning messages.
[bash]# cp /etc/aliases /etc/aliases.original [bash]# vi /etc/aliases |
# Our Own Aliases www: root admin: root sysadmin: root webmaster: root support: helpdesk # Person who should get root's mail root: john <-- John will receive all system/security email alerts meant for root. # People who have left our organisation - Mail redirection... sarah: sarah@otherdomain.org tom: tom@differentorganisation.org |
Aliases can also be configured to for mutliple recipients, this is a convenient way to create generic group email accounts outside of a global address book. With this example, a file is created with a list of mail receipiants listed on one line at a time.
[bash]# vi /etc/mail/mailing-list |
alice@wonderland.com peter@nevernever.org harry@potterworld.net |
The "mailing-list" alias is listed in the alias table, and the file containing the list of users is also added with the use of an "include" statement; this tests sendmail where the list of users can be found for the mailing-list. Alternatively, an alias can have several recipients listed directly aside the alias, separated by commas.
[bash]# vi /etc/aliases |
# Our Own Aliases sysadmins: john,mark,lisa mailing-list: :include:/etc/mail/mailing-list |
After the alias table has been adjusted, the
"newaliases" command needs to be executed before the table will be used by sendmail again.
[bash]# newaliases |
/etc/aliases: 97 aliases, longest 31 bytes, 998 bytes total |
Now that the sendmail server has been setup to allow the sending of emails, we need to configure a means for the user to retrieve any emails that are waiting for them on the server. One of the packages that does this is
dovecot, which handles POP and IMAP mailboxes in clear text or with link encryption (POPS and IMAPS); IMAPS is the preferred mail protocol for MUAs.
Dovecot is relatively easy to configure, but backing up the config file is still important.
[bash]# cp /etc/dovecot.conf /etc/dovecot.conf.original [bash]# vi /etc/dovecot.conf |
Dovecot needs to be told which protocols it will accept for incoming client connections, the setting below is the main dovecot configuration file; note its detail for both IMAP and POP3 protocols.
protocols = imap pop3 login_dir = /var/run/dovecot/login login_chroot = yes login_user = dovecot protocol imap { login_executable = /usr/libexec/dovecot/imap-login mail_executable = /usr/libexec/dovecot/imap login_greeting_capability = yes } protocol pop3 { login_executable = /usr/libexec/dovecot/pop3-login mail_executable = /usr/libexec/dovecot/pop3 pop3_enable_last = no } auth_executable = /usr/libexec/dovecot/dovecot-auth auth_process_size = 256 auth_cache_ttl = 3600 auth default { mechanisms = plain user = root ssl_require_client_cert = no passdb pam { } userdb passwd { } } |
| If you plan on setting up SquirrelMail for your webmail requirements, you will need to have the IMAP protocol enabled. |
User Email Accounts
When a standard user account is created on the server, that user is automatically granted access to login to the system and is also able to send and receive emails. The user now really only needs to configure their MUA with the details of the servers address and their account details, and email should be fully accessible.
Creating a standard user account with a false shell stops that account from being able to log into the system (a Linux login), but still allows them to use the system for the purpose of sending and receiving emails. Creating a user account using the following example, is the easiest method for creating email only accounts for friends and family where they do not require login access to the server.
[bash]# useradd -c "Alice Jones" -s /sbin/nologin alice |
Email only accounts forbid a user from logging in and accessing their home directories. These accounts may not be suitable if users expect access to their "public_html" directories if they are present.
You may also consider placing all of the email only accounts into an appropriately named group for easy management.
Starting the newly configured services are relatively straight forward, however if any changes have been made to the sendmail macro file or access lists, then the sendmail.cf file will need to be recompiled before any of the changes will be accepted. These days many of the initscripts handle this task automatically, however its good to do it manually just to be certain.
[bash]# make -C /etc/mail |
The services should now be set at the appropriate runlevels and then checked to ensure they are correct.
[bash]# chkconfig --level 2345 sendmail on [bash]# chkconfig --level 2345 dovecot on [bash]# chkconfig --list sendmail [bash]# chkconfig --list dovecot |
The services can now be started. The system logs should also be checked to ensure there are no errors.
[bash]# /etc/init.d/sendmail restart [bash]# /etc/init.d/dovecot restart |
[bash]# grep sendmail /var/log/maillog [bash]# grep dovecot /var/log/maillog |
You've got email !
Open mail relays
The worst exploitation of an email system is if its able to relay emails for everyone, this allows spammers and other nasty organisations to use your unprotected system as a platform for their malicious activities. Although we have defined who can use the system in the above configurations (access database), we can take extra precautions to minimise the effects of any possible damage.
The following example is a basic open relay test that you can perform on your sendmail server as an example of how easy it is for a spammer to send emails through an insecured MTA. Firstly you need to telnet into your server on port 25 (SMTP) and then cut and paste the following text into the telnet session; remembering to change the "RCPT To:" address to your own email.
[bash]# telnet localhost 25 |
(CUT AND PASTE BELOW TEXT) (Change "RCPT To:" email address) HELO example.com MAIL From: TheBoss@example.com RCPT To: sysadmin@example.com <-- Change this to your own email to see results. DATA Subject: Think we're insecure... I have a feeling our mail server is being abused... . QUIT |
Now if you check your email you will notice an email from "TheBoss" and you'll see how easy it is to spoof an email. If this worked, it means that you have probably enabled your
"/etc/mail/access" database with the correct RELAY permissions for it to occur. However, we only want to allow the correct clients to be able to relay through the MTA.
The following telnet test is an another open relay test that will automatically test your system from a remote Internet based relay attempt. Approximately 19 relay tests are conducted with results displayed as they occur, this is a good test of your systems configuration; it your server is open to relay, the spammers will find you soon.
[bash]# telnet relay-test.mail-abuse.org |
| If any of the open relay tests return serious warnings, you should seriously check your systems configuration - guaranteed your system will be exploited. |
Email limits
The default file size for sendmail is unlimited, so if someone tries to send a tar archive over 2 GB throught the system, it will most likely crash the MTA while trying. A maximum file size should be set so sendmail knows when to reject a file that is too large.
[bash]# vi /etc/mail/sendmail.mc |
define(`confMAX_MESSAGE_SIZE',`52428800')dnl |
If you are using a PHP based webmail application like SquirrelMail, you can adjust the max file size for PHP to match the same amount; this allows PHP applications to match your mail server size limits.
## ONLY NEEDED TO SUPPORT PHP WEBMAIL ## [bash]# vi /etc/php.ini post_max_size = 50M upload_max_filesize = 50M memory_limit = 64M |
The following settings limit the rate of connections, the amount of running 'children', and the maximum number of recipients for each email. By specifying these types of directives it limits the rate of any possible exploitation or Denial of Service attacks. These would be suitable for a small office or home network, but may need to be increased for larger demands.
define(`confMAX_DAEMON_CHILDREN',`5')dnl define(`confCONNECTION_RATE_THROTTLE',`3')dnl define(`confMAX_RCPTS_PER_MESSAGE',`50')dnl |
This section provides a few basic settings as an introduction to possible abuse situations and should provide you with some security considerations for your system. You should always check your system logs for any signs of abuse, and do some form of test attack on your own system (from the outside of course).
One of the easiest ways for any system to be exploited is for a username and password to be intercepted whilst traveling through the Internet, the basic action of logging into your server from the external (Internet) side opens your user credentials to such a risk. Luckly both Sendmail and Dovecot can both be covered by TLS and SSL encryption systems to ensure your credentials and correspondence stay safe.
To configure sendmail with TLS / SSL encryption, edit the main configuration file and make the following changes. The first setting disables plain text authentication, the second defines the trusted authentication mechanisums (to allow relaying), the third defines the SSL certificate files and the fourth enables the TLS link encryption and opens port 465 for secure emails (SMTPS).
[bash]# vi /etc/mail/sendmail.mc |
define(`confAUTH_OPTIONS', `A p')dnl |
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl |
define(`confCACERT_PATH',`/etc/pki/tls/certs')dnl define(`confCACERT',`/etc/pki/tls/certs/ca-bundle.crt')dnl define(`confSERVER_CERT',`/etc/pki/tls/certs/sendmail.pem')dnl define(`confSERVER_KEY',`/etc/pki/tls/certs/sendmail.pem')dnl |
DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl |
| The bottom option causes sendmail to additionally listen for secure connections on port 465 through enforced SSL. Basic SMTP is still configured through port 25 for remote MTA connections and TLS. |
In our initial configuration, we allowed sendmail to accept SMTP email from all hosts (the default is only from 127.0.0.1, itself). By changing this setting back to it's default, then only the local server can send unsecured emails, this is ideal if you are going to configure webmail to run from the local Apache web server.
Change This: DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl |
Back To: DAEMON_OPTIONS(`Port=smtp, Addr=127.0.0.1, Name=MTA')dnl |
Now that sendmail had been configured for encrypted connections and authentication, you will need to create your SSL certificates before you can activate your new configuration; this can be done using the automated scripts located in the
"/etc/pki/tls/certs" directory.
[bash]# cd /etc/pki/tls/certs [bash]# make sendmail.pem |
Country Name (2 letter code) [GB]:AU State or Province Name (full name) [Berkshire]:QLD Locality Name (eg, city) [Newbury]:Brisbane Organization Name (eg, company) [My Company Ltd]:Miles Brennan Organizational Unit Name (eg, section) []:Home Linux Server Common Name (eg, your name or your server's hostname) []:galaxy.example.com Email Address []:sysadmin@example.com |
You should now be able to send secure emails to your MTA (Sendmail) for delivery to remote addresses.
The next step is to configure Dovecot so you may be able to successfully retrieve emails from your mail server using SSL encryption; sending is only half way there, the receive path also needs to be configured. Open your Dovecot configuration and make the following adjustments. A point to note is that we are configuring the Dovecot server to use the exact same SSL certificates that the Sendmail server is using.
[bash]# vi /etc/dovecot.conf |
ssl_disable = no ssl_verify_client_cert = no ssl_parameters_regenerate = 168 ssl_cipher_list = ALL:!LOW ssl_cert_file = /etc/pki/tls/certs/sendmail.pem <-- NOTE: Can use same certificate as Sendmail ssl_key_file = /etc/pki/tls/certs/sendmail.pem <-- NOTE: Can use same certificate as Sendmail disable_plaintext_auth = yes |
We can also block Dovecot from allowing any insecure client connections by forcing the server to only accept secure IMAPS and POP3S connections.
Change This: protocols = imap pop3 |
To This: protocols = imaps pop3s |
Now that the services have both been configured, the services will need to be restarted.
[bash]# /etc/init.d/sendmail restart [bash]# /etc/init.d/dovecot restart |
If you have users on the external side of your firewall (i.e. on the Internet), you can allow both SMPTS (port 465) and IMAPS (port 993) connections to pass through your firewall with the following adjustments to your firewall script. Remember that port 25 (SMTP) is still required and will use TLS as required.
[bash]# vi /root/firewall.sh |
# New INBOUND Connection: SMTP and SMTPS (over SSL) iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 25 -j ACCEPT <-- for TLS encryption (and basic SMTP) iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 465 -j ACCEPT <-- for SSL encryption # New INBOUND Connection: IMAPS Email Clients (Secure Link - In and Out) iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 993 -j ACCEPT <-- for SSL encryption |
[bash]# /root/firewall.sh |
By default the Dovecot server will listen on all interfaces when we declare a protocol to be configured. However we can add the following options to the protocol declaration to define a more detailed configuration.
The following Dovecot configuration causes both the secure IMAPS and POP3S protocols on be active on all network interfaces, but also allow Dovecot to operate the insecure IMAP protocol only from the localhost server, this again is an ideal configuration if you intend to run SquirrelMail on your server and it is an IMAP based application.
[bash]# vi /etc/dovecot.conf |
protocols = imap imaps pop3s protocol imap { listen = 127.0.0.1 ssl_listen = * ssl_disable = no } |
| The above Dovecot settings allow for the IMAP based SquirrelMail application to work on the local server without requiring TLS/SSL encryption. A remote user will still interface the HTTPS web interface through SSL, ensuring secure access through a web browser. |
There is really no such thing as a virus in the Linux world and what you would call a virus is really nothing more than an exploit or maliciously crafted piece of code. Some not so better operating systems however are quite susceptible to virus attacks and the number one means of virus infection is currently via the email system. Although your Linux MTA itself is quite safe from any possible virus threats, we have a duty of care to at least protect our internal workstations that may face a somewhat different fate.
Clam AntiVirus is an opensource antivirus scanning toolkit for UNIX systems. Effectively it runs as its own independent service with its own suite of applications, these need to be interfaced by other applications in order to use the scanning facilities. Sendmail interfaces into clamav with whats called a milter (Mail Filter), and the results are returned to sendmail for further processing.
Clamav-Milter
Firstly we need to install the clamav suite of applications, this command will install the clamav server and the milter required to work with Sendmail.
[bash]# yum install clamav* |
The clam daemon configuration file should be backed up before any adjustments are made.
[bash]# cp /etc/clamd.d/milter.conf /etc/clamd.d/milter.conf.original [bash]# vi /etc/clamd.d/milter.conf |
The following is an example of a typical clamd configuration file. The
"/etc/clam.d/clamd.conf" file is well documented with configuration options and further detailed information can be obtained from reading the supporting man page. Type
"man clamd.conf" at the command prompt.
The "
Example" option must be commented out before the daemon will start.
#Example <-- This must be commented out before the daemon will function LogFile /var/log/clamd.milter LogFileMaxSize 5M LogTime DatabaseDirectory /var/lib/clamav LocalSocket /var/run/clamd.milter/clamd.sock FixStaleSocket #TCPAddr 127.0.0.1 #TCPSocket 3310 User clamilt ScanMail ScanHTML DetectBrokenExecutables ArchiveBlockEncrypted |
On one side we have a running MTA (Sendmail) and the other side we have a fully functional antivirus system, clamav-milter is the glue that binds it all together. As an email is passed onto the MTA, the milter redirects it to the antivirus server and awaits the results.
The following parameters detail how the milter will act and respond between the other two systems; should it just drop all infected email, should it notify the recipient or the sender, should it inform the administrator; there are numerous available options. You should consult the man page to configure the settings that will best suit your needs. Type "
man clamav-milter" at the command prompt for more details.
[bash]# cp /etc/sysconfig/clamav-milter /etc/sysconfig/clamav-milter.original [bash]# vi /etc/sysconfig/clamav-milter |
CLAMAV_FLAGS="--local \ --bounce \ --advisory \ --force-scan \ --dont-wait \ --dont-log-clean \ --max-children=2 \ --server=localhost \ --postmaster=sysadmin@example.com \ --config-file=/etc/clamd.d/milter.conf \ --pidfile=/var/run/clamav-milter/milter.pid \ --signature-file=/etc/mail/clamav-email-signature \ local:/var/run/clamav-milter/clamav.sock " CLAMAV_USER='clamilt' |
In the above sample configuration we are placing a footer (signature-file) on all the emails that successfully pass thru the system, as an assurance to the end recipients that the email is virus free. The following is an example signature file, it isn't required but is an option should your email policy require it.
[bash]# vi /etc/mail/clamav-email-signature |
_________________________________ This email has been ClamScanned ! www.clamav.net |
The service is now ready to run after we set the correct runlevels. The clamav-milter logs directly to
"/var/log/maillog" when it processes an email, which can be checked after all the configurations are complete.
[bash]# chkconfig --level 2345 clamav-milter on [bash]# chkconfig --list clamav-milter |
[bash]# /etc/init.d/clamav-milter restart |
Now that the milter is running, we need to tell sendmail to use it. Place the following line into the sendmail.mc file, then restart the Sendmail service.
[bash]# vi /etc/mail/sendmail.mc |
INPUT_MAIL_FILTER(`clamav-milter', `S=local:/var/run/clamav-milter/clamav.sock, F=T,T=S:4m;R:4m;E:10m') |
[bash]# make -C /etc/mail [bash]# /etc/init.d/sendmail restart |
Thats it !! You are all configured now for antivirus scanning.
Testing the Clamav Scanner
The easiest way to check if the scanner is functioning, is to check the mail logs. The details of each email that gets sent by the milter to clamd is placed in the log, the example below shows how the milter added the extra header details to the incoming email.
[bash]# grep Milter /var/log/maillog |
sendmail: Milter add: header: X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on galaxy.example.com sendmail: Milter add: header: X-Virus-Status: Clean |
The email can be checked at the MUA to confirm the presence of the extra milter headers on all of the incoming emails. This is confirmation that the system is configured and functioning as expected.
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on galaxy.example.com X-Virus-Status: Clean |
The
European Institute for Computer Antivirus Research (EICAR) have created an antivirus test signature that can be used to test many antivirus programs. Your new Sendmail configuration can be tested by sending the EICAR test signature through as an email and check to see if Clamav identified and labelled the email as an infected message.
Issue the following command at the command line interface, ensuring that you change the email address to your own (or one you can access). When the email arrives at the email address you inserted, you can check the headers within the email and see if Clamav has inserted the following flags.
[bash]# echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' | mail sysadmin@example.com |
To: sysadmin@example.com X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on galaxy.example.com X-Virus-Status: Infected with Eicar-Test-Signature Subject: [Virus] Eicar-Test-Signature |
Freshclam updates
The Clam Antivirus system is only as effective as its latest copy of the virus definitions, these can be updated using the freshclam application. Make the following adjustments to your freshclam settings, ensuring you ADD a "#" (comment) to the
"FRESHCLAM_DELAY" directive, this enables the update service.
[bash]# vi /etc/sysconfig/freshclam |
FRESHCLAM_MOD=180 <-- Update interval in minutes #FRESHCLAM_DELAY=disabled-warn <-- Add "#" to activate (enable) clamav updates |
The main antivirus functions are now running and freshclam can be configured to keep the system up to date with the latest virus patterns. As normal the configuration file should be backed up.
[bash]# cp /etc/freshclam.conf /etc/freshclam.conf.original [bash]# vi /etc/freshclam.conf |
This is an example of the freshclam configuration file. This file too is well documented and the supporting man page should be consulted for any further queries. Type
"man freshclam.conf" at the command prompt.
If your system is behind a firewall or you prefer to use a proxy server, then ensure that you complete and enable the appropriate HTTPProxy options for your system.
#Example DatabaseOwner clamav DatabaseDirectory /var/lib/clamav Checks 24 MaxAttempts 5 UpdateLogFile /var/log/freshclam.log DNSDatabaseInfo current.cvd.clamav.net DatabaseMirror db.??.clamav.net ### <-- See Note. DatabaseMirror database.clamav.net #HTTPProxyServer galaxy.example.com #HTTPProxyPort 3128 #HTTPProxyUsername username #HTTPProxyPassword password |
| Replace "??" (above) with the two letter country code for your region, or remove line from configuration file if you are unsure. |
Freshclam will automatically update itself at intervals define with the earlier "FRESHCLAM_MOD" declaration. However, if you require to update your antivirus manually to test your configuration, you can execute the command at the xterm prompt.
[bash]# freshclam |
ClamAV update process started at Sun May 21 12:01:57 2006 main.cvd is up to date (version: 38, sigs: 51206, f-level: 7, builder: tkojm) Downloading daily.cvd [*] daily.cvd updated (version: 1472, sigs: 4793, f-level: 8, builder: arnaud) Database updated (55999 signatures) from db.au.clamav.net (IP: 61.8.0.16) |
Freshclam keeps a log of all update details.
[bash]# tail /var/log/freshclam.log |
One of the biggest wastes of bandwidth throughout the Internet today is from unwanted/unsolicitated bulk email, in other words spam; we hate it. Unfortunately for us it isn't going to go away for a while, fortunately we can at least filter some of it out of our Inbox by using
SpamAssassin which comes standard now with many Linux distributions. SpamAssassin will at the very least allow you to take some control back over your email account.
To install SpamAssassin and the required milter for Sendmail, type the following command at the prompt.
[bash]# yum install spamass-milter spamassassin |
SpamAssassin has many plugins written and available for use, they can be enabled in the
"/etc/mail/spamassassin/v310.pre" plugin file. The plugins file is the first configuration to be loaded by SpamAssassin.
[bash]# cp /etc/mail/spamassassin/v310.pre /etc/mail/spamassassin/v310.pre.original [bash]# vi /etc/mail/spamassassin/v310.pre |
loadplugin Mail::SpamAssassin::Plugin::DCC loadplugin Mail::SpamAssassin::Plugin::Pyzor loadplugin Mail::SpamAssassin::Plugin::Razor2 loadplugin Mail::SpamAssassin::Plugin::SpamCop loadplugin Mail::SpamAssassin::Plugin::AWL loadplugin Mail::SpamAssassin::Plugin::AutoLearnThreshold loadplugin Mail::SpamAssassin::Plugin::WhiteListSubject loadplugin Mail::SpamAssassin::Plugin::MIMEHeader loadplugin Mail::SpamAssassin::Plugin::ReplaceTags |
The
"/etc/mail/spamassassin/local.cf" file is the main global configuration file for the whole server and can be configured like so.
[bash]# cp /etc/mail/spamassassin/local.cf /etc/mail/spamassassin/local.cf.original [bash]# vi /etc/mail/spamassassin/local.cf |
required_score 5.0 rewrite_header subject [SPAM] report_safe 1 use_bayes 1 use_bayes_rules 1 bayes_auto_learn 1 skip_rbl_checks 0 use_razor2 1 use_dcc 1 use_pyzor 1 trusted_networks 192.168.1/24 127/8 internal_networks 192.168.1/24 127/8 |
| If you need assistance in determining which configuration options are the best for your system, you can use the online "SpamAssassin Configuration Generator" located at: "http://www.yrex.com/spam/spamconfig.php". your customised online configuration can then be downloaded into your /etc/mail/spamassassin/local.cf file. |
To define daemon runtime options, edit the system configuration file for SpamAssassin.
[bash]# cp /etc/sysconfig/spamassassin /etc/sysconfig/spamassassin.original [bash]# vi /etc/sysconfig/spamassassin |
SPAMDOPTIONS="-d -c -l -m5 -H" |
Users can also fine tune their own options for SpamAssassin by editing their own user configuration files located in their home drives.
[/home/miles]$ vi ~/.spamassassin/user_prefs <-- executed as basic user |
The SpamAssassin mail filter (milter) can then be configured with runtime options.
[bash]# cp /etc/sysconfig/spamass-milter /etc/sysconfig/spamass-milter.original [bash]# vi /etc/sysconfig/spamass-milter |
SOCKET=/var/run/spamass-milter/spamass-milter.sock EXTRA_FLAGS="-r 15" |
The daemons need to be configured to start at the appropriate runlevels using the following commands, this should also be checked to ensure the daemons will initialise at expected if needed at next reboot.
[bash]# chkconfig --level 2345 spamassassin on [bash]# chkconfig --level 2345 spamass-milter on [bash]# chkconfig --list spamassassin [bash]# chkconfig --list spamass-milter |
Once the services has been configured, the daemons can both be restarted.
[bash]# /etc/init.d/spamassassin restart [bash]# /etc/init.d/spamass-milter restart |
The SpamAssassin configurations have now been completed, however the mail server has not yet been configured to use the spam filtering daemon yet. Before we do the final configuration, it is important to firstly test that SpamAssassin is functioning as expected and the email that passes through the daemon is handled correctly. If we don't do these tests then some of your email may just disappear because of a poorly configured service.
The first test passes a test email to the spam daemon and returns the results to the screen. This test email is considered by SpamAssassin to be clean and should return a clean result.
[bash]# spamassassin -t < /usr/share/doc/spamassassin-3*/sample-nonspam.txt | grep X-Spam |
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on galaxy.example.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable |
The second test passes an email that is considered by SpamAssassin to contain spam signatures, as such the test should return a positive result to the test. You should note the
"X-Spam-Flag: YES" flag that SpamAssassin inserts into the email's headers, this will allow users an easily way to identify and automatically sort spam affected emails into junk email folders as they arrive in their Inboxes.
[bash]# spamassassin -t < /usr/share/doc/spamassassin-3*/sample-spam.txt | grep X-Spam |
X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on galaxy.example.com X-Spam-Level: ************************************************** X-Spam-Status: Yes, score=1000.0 required=5.0 tests=GTUBE,NO_RECEIVED, |
Once you are happy that the outcomes of both your spam and non-spam tests are successful, Sendmail can be configured to pass emails to the SpamAssassin daemon by use of the mail filter (milter).
[bash]# vi /etc/mail/sendmail.mc |
INPUT_MAIL_FILTER(`spamassassin', `S=unix:/var/run/spamass-milter/spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')dnl define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name}, {if_name}, {if_addr}')dnl define(`confMILTER_MACROS_HELO',`s, {tls_version}, {cipher}, {cipher_bits}, {cert_subject}, {cert_issuer}')dnl |
Now that the SpamAssassin milter settings have been inserted into the Sendmail configuration, the Sendmail server can be restarted; this will complete your installation.
[bash]# make -C /etc/mail [bash]# /etc/init.d/sendmail restart |
For further information on SpamAssassin configuration, you can view the following man pages:
"Mail::SpamAssassin::Conf" and
"Mail::SpamAssassin".
REFERENCEhttp://www.brennan.id.au/12-Sendmail_Server.html