Thanks to those that replied, it is appreciated. Perhaps I should have laid out my reasons along with my request so that a better understanding was in hand. I have used Qmailqueue and qmail-scanner before and find it to be useful however it does not solve my challenges in this case. AFAIK there are several issues that using them present in my situation. I will detail them and hope that other methods are readily available before going out and doing it from scratch. It may be easy and it may be more difficult than expected, this is what I am attempting to ascertain.
0) qmail-queue is a patch against the sources, this introduces regression and maint issues that are problematic to long term stability and deployment. Rapid mass patching is extremely slowed when you have to patch sources, build, and fully regress to deploy, a mail server is a high risk target and as such I would prefer to not have to do this even if performance takes a hit. Using environment variables to source what will happen next introduces opportunity for compromise, even if it is not a multi user system. A compromise of any component that allows the attacker to control the execution environment of the system locally could result in further elevation of privileges. It has undergone "virtually no testing" [1] I have not looked at the viability of this attack vector or the security of the patch, it is outside my scope of deploying a highly configurable and secure mail server with readily available, easily supported, stable applications that cost nothing.
1) Jason Harr does good work but qmail-scanner is a perl script and it uses suid perl, while it is possible to properly develop a safe perl script the odds are against it in the time/complexity/security equation, there are ~3000 lines in the last copy I have. For every component that adds complexity risk is increased, I find the complexity unnecessary for what I need. For a history of bugs and issues the script has been known to introduce just reference the changelog [0]
1a) suidperl has had it's own issues and is inherently risky.
2) qmail-scanner does not allow me to turn scanning on and off for different accounts or domains. My systems and needs dictate that antivirus be a configurable item by account.
3) using procmail adds more complexity that is not needed. I use it when appropriate however in this case it is not. Enabling users to modify procmail filters allows local execution of programs. This conflicts with the goals of a well secured mail server. I also am not aware of a way to use procmail for accounts that are virtual domains.
4) Intercepting and changing the destination of mail or discarding it for any client introduces liabilities, especially if there is a change of a false identification. This decision needs to be put onto the user so that the liabilities remain with the user.
What I ultimately need to do is take the delivery, check it for a virus, and take an action. This needs to be configurable by account and maintainable by an inexperienced admin that can follow directions. Updates should be easily performed and the entire system should be installable without ever having compiled anything. If no work has been done in this area I am happy to embark on it and even make more in doing so however I would be remiss if I did not look for existing works.
Thanks again, Jason.
[0] = http://qmail-scanner.sourceforge.net/CHANGES [1] - http://www.qmail.org/qmailqueue-patch
------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
