configuring amavisd-new and ClamAV always pisses me off

For about the tenth or fifteenth time in my career, I’m (re-)configuring a virus and spam scanning gateway machine using amavisd-new and ClamAV as the virus filter. This process has admittedly gotten easier over the years, but by no means is it totally foolproof. You still have to know what you are doing, and fortunately my 5+ years of experience managing similar setups comes in handy. The permissions issues still aggravate me, though.

Installing the whole bundle on CentOS is easy enough. First, we install the rpmforge-release bundle which gives us access to the valuable Dag Wieers APT/RPM Repository. Then it’s just a matter of running:

# yum install clamd
# yum install amavisd

and all the dependencies get sucked down. Beware that the amavisd package has some weird %postinstall scriptlet that will complain if ClamAV isn’t present yet. I also had an odd problem where amavisd couldn’t find perl(DBI) >= 1.43 and refused to install, but I think the versioning check is too aggressive; I used perl-DBI version 1.40 from base and it worked.

I also hate sendmail, so I always use Postfix with these sorts of setups. There are a number of reasons for this:

1. Using sendmail with amavisd-new requires either a milter setup, or a dual-sendmail instance. I find both of these alternatives unpalatable and they’re notoriously difficult to set up (trust me, I’ve done it, since I’m the NetBSD package maintainer for amavisd-new and need to test all possibilities thoroughly)
2. sendmail has so many security holes that continue to be discovered and actively exploited that I don’t have confidence in the product.
3. sendmail is a pain to configure for anything other than basic functions. I mean, this is the year 2006… do we really need to be using software that requires its configuration files to be macro pre-processed before use?

Anyway, onto the meat of the problem: ClamAV and amavisd-new run under two different user IDs, clamav and amavisd by default. amavisd-new feeds scan requests to ClamAV using a local UNIX socket, but ClamAV then needs to read the temporarily-spooled email off disk, which was written by amavisd-new as the amavisd user. This means that the ClamAV user needs to be in the same group as amavisd. amavisd-new also needs permission to write to the local socket set up by ClamAV.

If this sounds needlessly complicated, it is. I get it wrong every time, and part of the problem is that I always forget to set ClamAV to run with a local socket (at least on CentOS/RHEL it ships with LocalSocket off.) What puzzles me is that ClamAV has a native TCP/IP socket mode; actually, the RHEL ClamAV packages ship with this turned on, as follows:

# TCP port address.
# Default: disabled
TCPSocket 3310

# TCP address.
# By default we bind to INADDR_ANY, probably not wise.
# Enable the following to provide some degree of protection
# from the outside world.
# Default: disabled
TCPAddr 127.0.0.1

So why doesn’t amavisd-new have a routine to be able to connect using a TCP/IP socket instead of a local socket? I don’t know. Another thing: why does ClamAV need to be able to read physical disk files written by amavisd-new in order to do its job? One would think that the interprocess communication over the socket would be sufficient to send both control and data, instead of just control requests.

Don’t get me wrong — I think both products are, on the whole, excellent. There are, however, some inherent design flaws that cause me to tear my hair out again and again.