Is there a software able of use .qmail-default file for scanning viruses using clamd? I don't want use qmail-scanner.
I only saw that spamc work with vpopmail.
I couldn't find any, and so wrote my own that does something similar to that :)
Solution we used:
1) Patch vdelivermail to, upon finding a BLAH environment variable, leave the message in Maildir/tmp and run an external program specified in BLAH a la the QMQ patch. (We call this "vrecordmail"). Several arguments are given to BLAH: the user, domain, msg size, and the full path to the message.
- Program BLAH stores a record of the message in a MySQL DB (a queue) and flags it in the queue for processing.
- Program BLAH exits cleanly to vdelivermail, which exits with success to qmail-local.
2) Replace ~vpopmail/bin/vdelivermail with a simple ash script that sets the BLAH environment variable to the program, and then exec's the original vdelivermail with the arguments it was given. (Just like the QMQ patch, it can be selectively enabled.)
3) A separate process (we call "vprocessmail") runs via supervise and queries for entries from the queue DB that need to be processed. We read each entry, checking for race conditions at each step along the way, and:
a) Punt if over a specific size,
b) Use ripmime to expand the message to tempdir on a RAM disk
c) Clamdscan the tempdir
d) If dirty, replace the body with a warning message including the virus found, time spent, and boilerplate; otherwise perform spam scanning (Mail::SpamAssassin, dspam) and other other message tweaking/rewriting per user prefs.
e) Add headers with info about d)
f) Update the queue DB with the same info
g) If message is being deleted, delete message, and move on to the next msg.
h) Otherwise write the re-written message back out as Maildir/tmp/.tmp.(origfilename)
i) rename to Maildir/tmp/origfilename
j) rename to Maildir/new/origfilename
k) Record success and move onto the next message.
l) If last message has been reached, sleep 7-12 seconds (randomly), query the queue again, and repeat.
It works great for us, and also has the benefit of not spending any processing power on messages that aren't being delivered locally (ie, the final delivery). For scanning mail on a server used primarily for outgoing mail (or forwarding messages), a qmail-queue-based solution might work better.
Having the queue DB based makes for really easy reporting and forensics too, and it's all written in Perl, so the sky's the limit in terms of functionality.
YMMV... but let me know if you want any more info on the setup, or code :)