Google Site SearchFN Site Search FN Blog Login FN Blog Login
Site Navigation:

Clam AntiVirus with Sendmail on Fedora Core 1

by Ron Goulard on April 12, 2004

This article describes how to setup Clam AntiVirus on Fedora Core 1 for use with sendmail. I have not tried it with other MTA's (postfix and qmail as examples), and while it may or may not be similar, I do not know and therefore they will not be addressed here.

There are different ways of doing this, it's true (using the source files for example), but this will describe what and how I did it, using available RPMs in order to keep it easy for those who are new to Linux, and specifically to using Fedora Core. If someone else can provide the instructions for a similar setup using other MTA's in order to help others out, please do, as not everyone uses sendmail.

General Information & Feedback:

  • This article assumes that you already have installed and are accepting mail from outside domains, or can easily get and install the sendmail and sendmail-cf packages.
  • While Linux is susceptible to few virus/worms, many people use it as a mailserver and NAT box for Windows machines.  Using clamav will help protect these Windows machines from receiving an email virus.  This does not mean that local anti virus should not be used on those machines.  It is simply an added layer of protection.  Not all users update things when, or as, they should.
  • I am not an expert by any stretch of the imagination. This is based solely on my experience and information that I've managed to pick up from people much more knowledgeable than myself. If you find any errors or omissions, please inform me so that it may be corrected. Please keep in mind that I wish to have this be easy to read and to follow.
  • If more information is required, I would recommend you check out the ClamAntiVirus (0.70) Documentation, as well as the clamav-user mailing list. They can be quite helpful.
  • Version numbers are always changing as software matures, please be aware of that.  As a general rule, always use the latest versions unless something has broken or you have other valid reasons for doing so.  Versions in this article are current as of this writing.
  • For various parts of this, you need to have 'root' access for a successful installation and configuration.
  • If this has been of use to you, and you can translate it into another language in order to help even more people, feel free to do so.

What is Clam AntiVirus?

ClamAV is a UNIX based, GPL'd anti virus toolkit.  It can be used in many different ways, on many different platforms, though this article will focus on using it with sendmail on Fedora Core 1 in order to detect and stop incoming virus and worms through email.  It currently finds and stops everything which I've been able to throw at it.  It can update the virus definition files automatically, usually done hourly, (this is configurable) but please don't check for updates more often than that as this can overload the servers.  Much more information about it can be found at the ClamAntiVirus site itself.

*NOTE* Please be aware that clamav _does_ stop netsky, but clamav calls it SomeFool.  This seems to be a common question as of late in the mail list.  Different AV providers use different names and this is but one example.


Two packages are required before installing clamav: sendmail & sendmail-cf. To determine whether they are installed, issue:
$ rpm -q sendmail sendmail-cf
These two packages should list as installed:

If these are not present, you can install them from the Fedora CD's or use apt/yum/up2date to do so as well.  For example, you could issue the command (as root):
up2date -u sendmail sendmail-cf
to install them.  This should work fine for you, but that command was not tested, as I already had both of those packages installed.

Alternatively, see this FAQ for setting up up yum and issue the commands:
yum install sendmail
yum install sendmail-cf

Where/how do I get Clam AntiVirus and how do I install it?

Clamav RPMs are available from Petr Kristof and Dag Wieers and I'm sure, from others.  Both are excellent sources for packages, kept very current.  The Dag Wieers repository contains much more than just clamav and I recommend it highly for a many packages. 

The packages are also available from the Fedora Extras site, if you have that configured (and of course, I can't find that config at the moment).  Fedora Extras seems to update less frequently, generally meaning more stable software but passes on the newest features until they settle down and stabilize.  This does not mean that it cannot catch the newest virus.  The virus db is still updated very frequently.  Its just a more slowly evolving feature set which allows for greater stability as the software matures. 

That said, the following bit of instruction is from Petr Kristof's site as the instructions there are quite clear and concise, which is why I use them here.

I quote from Petr Kristof's site:
You need to install GPG key used to sign packages. Get it and install as 'root':
*author's note*
*you may also wish to try putting those two commands together
*(ie. rpm --import )

There are to ways to use this repository. Via program up2date or via program yum.

To use up2date, add next lines to file /etc/sysconfig/rhn/sources:
  • yum crash-hat
  • #yum crash-test
To use yum, add next lines to file /etc/yum.conf:
  • [crash-hat]
    name=Fedora Core $releasever - $basearch - CrashHat
  • #[crash-test]
    #name=Fedora Core $releasever - $basearch - CrashTest
Finally, run up2date -u foopackage or yum update foopackage
NOTE: crash-test contains unstable versions. They are tested several days before releasing, but you never know! Uncomment this only if you are brave or fool or both.

Easy enough.  Thank you Petr.  In this case (regarding clamav) you'll need to run, for example:
up2date -u clamav 
up2date -u clamav-milter
yum update clamav
yum update clamav-milter

But you aren't done yet!

There are still things left to do.  This is why you need the sendmail-cf package installed.
There are two lines which must be added to the file and then the file needs to be regenerated.  For this, the sendmail-cf package is required.
cd /etc/mail
You need to add the following line into the file.  The bottom (or end) of the file is fine. 

INPUT_MAIL_FILTER(`clamav', `S=local:/var/run/clamav/clamav-milter.sock, F=, T=S:4m;R:4m')dnl

Please pay attention to the quoting in the line above.  There are backtics (`) and single quotes (').  This is important.  It will not work if the quoting is incorrect.  For example, the segment of "clamav" above, begins with a backtic and ends with a single quote.  Double and triple check your entry.

*Additonal Information
The section of "F=, T=S:4m;R:4m" in the line above are milter parameters.  They can be tuned for your application but for most people the defaults should work well.  If you have no need to change them, leave them as they are.  Otherwise, see the section "Additional Milter Information" at the end of this article.

Save the file and quit.    (ie.     :wq)
Now to regenerate the file, do this, as root:
make -C /etc/mail

That's all the hard stuff.  It's probably the trickiest part in the whole thing.  Now let's move on.

Configuration and Startup

There are config files.  Not much to do here besides tweak things the way you want them.  The defaults should be just fine for most people, but you may wish or need to change them.   Have a look at them, change them if need be, otherwise just accept the defaults.  The config files are located as follows:


The file '/etc/sysconfig/clamav-milter ' contains a flag "--quiet".  Please DO NOT remove this flag.  Removal of this flag causes an email to be sent to the supposed sender of the email that a virus was found in.  This is of little use as most virus out there spoof the "from:" address, causing a false report and what many people/admins regard as spam, being sent to someone who did not send you the virus.  Please leave the --quiet flag intact.  It is much better to simply close the connection and ignore the message when a virus has been found.  It gets logged for administration purposes anyway (in /var/log/clamav/clamd.log) and it's that much less traffic on the Internet during a virus outbreak.

We're almost there.  All that remains is to configure the startup and fire it up.

When you're happy with the contents of the config files, you need to set clamav and its associated parts to start on bootup, etc., otherwise it's all been kind of pointless.  Issue the following command:
for i in `echo clamd clamav-milter freshclam sendmail`; do /sbin/chkconfig --level 2345 $i on; done
What this does is tell the system that clamd, clamav-milter, freshclam and sendmail are to be started up at the runlevels of 2, 3, 4 and 5.  By default, the clamav bits are not configured to automatically startup.  Don't worry too much about what the different runlevels mean, this just ensures that they are running when they should be.

Now that we have everything installed, setup and configured, we just need to start/restart the services and we're done.  No need to reboot, but if you feel you must, or wish to verify that things are in fact starting up as they should, you can.  Otherwise the following command will work just fine:
for i in `echo clamd clamav-milter freshclam sendmail`; do /sbin/service $i restart; done
You'll get errors about stopping the processes (as they weren't running to begin with), but the startup should be fine.

That's all there is.  Freshclam is the component which updates the anti virus database and it should be doing so roughly every hour (or whatever you configured). 

Check the /var/log/clamav/freshclam.log file for results of the updates.
Check the /var/log/clamav/clamd.log file for reports as to which of, and when, the nasties were stopped.


If you send an uninfected email to a user on the machine where you configured ClamAV, and look at the full headers of that email, you should see a line such as this:
X-Virus-Scanned:    Clamd / ClamAV version 0.70rc, clamav-milter version 0.70
By all means, test it with a virus infected email.  I'm sure it's not hard for you to find one.  The infected email should not be deliverable and/or should never make it to the mailbox.  In fact, the connection should close on you immediately upon finding the virus.

Check your logs regularly/religiously.  This applies to any machine, running any kinds of services, not just antivirus.  It's far better to know that something is wrong (and probably be able to have it fixed quickly) by watching the logs closely, than by having people inform you of an outage.  Service outages are bad.

I just can't state this strongly enough:
"This does not mean that up to date virus checking on other machines is not necessary.  There are many ways for a virus or worm to spread and email is only one of them.  Please be aware of this.  This document is aimed at reducing that exposure but cannot eliminate it completely."

Additional Milter Information - for those who want more details

The milter parameters are broken into four main parts.  I will only deal with the last two.  They are set 'per milter' and not globally (yes, you can have multiple milters running on a machine, but that's far beyond the scope of this document).  These basically tell the machine what to do with the message in various cases and will occur whether or not a virus is present.  I'll explain using the parameters from the line above.  (ie   F=, T=S:4m;R:4m )

The two sections are separated by that little comma essentially.   The first being F= and the second being T=.

The first section, the F=, specifies what to do if the milter is unavailable and has three possible options, as follows:
  • F=T   -temporarily fail the connection if the milter is unavailable (down, too busy, etc.)   This leads to mail delays as people cannot deliver to you, but periodic retries should happen, and when the milter is again available, it should be fine.
  • F=R   -reject the connection if the milter is unavailable.  Similar to having the mailserver say "non-exising service".  Retries may or may not happen and as far as I know, its up to the configuration of the MTA on the other end.  It's possible to have this result in 'undeliverable' mail.  Not usually something you want.
  • F=     -accept the mail anyway, even if the milter is unavailable and continue with normal mail handling.  A virus may be accepted, but your mail is still flowing.  You do have up to date anti virus running on the desktop don't you?  Keep a close watch on your logs.
The second section, the T=, specifies timeouts for communication with the milter and has the following options:
  • C   -timeout for connecting to the milter. Default is 5m (minutes).  If set to 0 then the system connect() timeout is used.
  • S   -timeout for sending to the milter.  Default is 10s (seconds).
  • R   -timeout for reading reply from the milter.  Default is 10s.
  • E   -overall timeout between sending 'end of message' to the filter and waiting for the final acknowledgment.  Default is 5m
       Each option is specified as in the following examples:
       S:4m  (timeout sending to milter is 4 minutes   S-colon-4m)
       R:30s  (timeout reading reply is 30 seconds  R-colon-30s)

       Be sure to separate whatever options you choose with a semi-colon ";"  as in  "C:10s;S:10s;R:10s;E:10s"

Future Information

I have begun working on a doc which explains how to incorporate ClamAV with the scanning of Samba shares.  I'll update as that becomes available.

  • I'd like to express my thanks to the members of the Clam AntiVirus team and the members of their mailing list.  I've learned a great deal from them.
  • To Alexander Dalloz, Matt Hansen, James Kosin, Matt Morgan (and the rest of the fedora-users mailing list) for their corrections, additional information and feedback.
  • I'd also like to thank Petr Kristof and Dag Wieers for the RPM packaging they've done.  Very well done and much appreciated. Please don't stop :)
  • The Fedora Core members and all the contributors (for the code and documentation, as well as for providing corrections to this article, from altogether too many places to list).  Together they've come up with an easy to use distribution that just gets better.  Thank you. 
  • There are others, whom I won't name (they know who they are), that I'd like to thank as well. For putting up with my ceaseless questions and comments, while helping me learn (sometimes the hard way but those are usually the best lessons).

I welcome any comments/suggestions which may help in improving this and future articles I may write.

Warm Regards,
Ron Goulard