Either my Xen DomU gets slower or my MTA keeps getting busier. But when looking at the stats I could see that a lot of clamscan have been spawned on every fetchmail. Nothing unusual, this is how it always worked. But to be honest, the setup was rather inefficient, to say the least: for every incoming mail, maildrop spawns a clamscan process, sometimes more than one in parallel. ps(1) shows, for just one process:

 PID  %MEM    RSS    SZ    VSZ  COMMAND
 8749 12.8 164500 49081 196324 clamscan

So, one process needs 12.8% of the systems memory, with just 5 process we're at 64% - and the box was indeed swapping heavily. So I finally got around *) to move the virus-scanning to Exim and let it speak to clamd instead:

/etc/exim4/conf.d/main/02_exim4-config_options

     +av_scanner = clamd:/var/run/clamav/clamd.ctl

/etc/exim4/conf.d/acl/40_exim4-config_check_data

     +  warn
     +    message = X-Virus-Status: Infected
     +    demime  = *
     +    malware = *

Note: I chose warn over deny here - I still want to have those viruses, I just want to have it annotated :-)

/etc/clamav/clamd.conf

     User clamav
     AllowSupplementaryGroups true
     LocalSocketGroup Debian-exim
     LocalSocketMode 0660

For Debian/5.0, I also had to:

# usermod -G Debian-exim clamav
# mkdir -m0770 /var/spool/exim4/scan
# chown Debian-exim:Debian-exim /var/spool/exim4/scan

With all this in place (plus disabling the clamscan directives in .mailfilter), the box is far less loaded now. According to ps(1), our single clamd now goes sometimes up to 16%, but that's still just one process and better than those >60% before.

Btw, if you want to test your email AV setup and your mailprovider doesn't even allow the sending of the Eicar Test File, try this instead.

Update: And it helped indeed, see the loadavg going down after changing the configuration to use clamd now. Phew, now I wonder why I haven't done this earlier....

*) I hate MTA configurations, I really do :-\