Paul Kosinski via clamav-users wrote:
For many years now (well before Cisco's involvement) I have been scanning email
just before delivery by Postfix using procmail (not a Milter). Up until now, I
have been running ClamAV on the same computer as Postfix, and scanning using
clamdscan to stream (not fdpass) the mail contents to clamd. (I do this using
clamscan-procfilter.pl, originally developed by A G Basile in 2004 and modified
by me in 2007 and 2017.)
Unfortunately, ClamAV has changed so much from 0.103.x to 1.0.9 (not to mention
1.4.3 and 1.5.0) that I can't currently run ClamAV in the same OS environment
as Postfix.
But I can't afford to have no email during the time that would be needed to
upgrade the OS, Dovecot, Postfix, Samba, etc. and test everything on my current
server. Nor can I afford to buy another computer with similar power and storage
(including software RAID0 and redundant backup disks), set it up with new
software versions, fully test everything and then cut over almost atomically
(as if that would immediately work without problems).
So, what I am doing is setting up ClamAV on a small (but powerful) computer and
running clamd on it so as to receive the mail contents to be scanned via a TCP
port. (This might not be practical for a commercial email service, but the
email volume associated with home use is pretty small.)
The problem I run into is that, although clamd.conf allows one to specify a
port number and even an an IP address for clamd to bind to, there seems to be
no way -- such as a command-line option -- to specify what IP address clamdscan
should talk to. (This makes the clamd binding address almost irrelevant, I
think.)
What we do is place a minimal "clamdscan.conf" on each node calling our
filter service cluster (also hosts several SpamAssassin instances with
different configurations) with just two directives:
TCPAddr [load balanced IP]
TCPSocket 3310
and run "clamdscan --config-file=/etc/clamav/clamdscan.conf" from each
system that needs to scan, well, anything. At present this is 6
systems, soon to be 8. (For some cases we use other options as well -
--no-summary in particular - so we don't have to postprocess the result
to stick the virus name into some logging or an SMTP error message.)
We also have variant config files each with one of the individual IPs of
the servers running clamd, mainly for testing.
This has worked quite well for us for over a decade. Scaling is mainly
a matter of a) enough CPU cores and RAM allocated for the VMs running
clamd and SpamAssassin and b) enough VMs in the load-balanced cluster.
We've gone pretty heavily overprovisioned, to ensure consistent
processing times 99%+ of the time.
-kgd
_______________________________________________
Manage your clamav-users mailing list subscription / unsubscribe:
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/Cisco-Talos/clamav-documentation
https://docs.clamav.net/#mailing-lists-and-chat
