Qscanq was designed for security. Your qmail installation should be just as secure after installing qscanq as it was when you first installed qmail. I say "should be", rather than "will be", because I can't certify that your virus scanner (most of which are not open source) is free of bugs.
The principles behind qscanq security are similar to those followed in the qmail design. Particularly:
Do as little as possible in setuid programs.
Exactly two programs are either setuid or setgid, and neither runs as root or any of qmail's users and groups.
Qscanq runs as the qscanq user, so it can create a working folder under qscanq's spool folder. Run-cleanq is setgid to qscanq's control group, so that the cleanq service can be started without granting users access to give the cleanq daemon other commands. Everything else, including actual scanning of files, runs under the identity of the caller--either the local user who invoked qmail-inject, or qmaild for remote emails.
Do as little as possible as root. Qscanq does nothing as root (except when invoked by root).
Move separate functions into mutually untrusting programs.
The virus scanner runs as the calling user. The qscanq user controls access to the queue in which scanning occurs. A separate group controls the ability to control the cleanq daemon. Another user owns the cleanq logs.
Don't parse.
Practically every configuration setting, of which there are few, is decided at compile time. There are no configuration files to parse, no scriptable behaviors, and no loopholes. Infected emails will be rejected, period. There is no room for surprise behavior and/or exploits due to ill-written parsers.
Keep it simple, stupid.
Write bug-free code.
Lots of the underlying code is shamelessly ripped off from qmail's author, and is of the highest quality. (In fact, if you find a bug, make sure you contact me and only me about it. It's almost certainly a bug I introduced, not a bug in Dan's code.) Though I'd be the last to claim perfection, my code was written with meticulous care.
