A while back I posted a /etc/procmailrc file that I was deploying to
implement
spam and virus scanning before delivery to the users:
http://www.xray.mpe.mpg.de/mailing-lists/procmail/2004-02/msg00086.html
The script that I ended up using is more/less unchanged from that version.
It works fine when run as as root/mail when invoked directly from sendmail.
Ran into a glitch though. One of the users had a legacy .forward file that
read:
|/usr/bin/procmail,/home/user/save_everything.mbox
This caused sendmail to su to the user, and run procmail. Procmail first
executes /etc/procmailrc, which has code like this in it:
# set up per user procmail logs
#
:0
{
LOCKFILE=${USER_LOGFILE}$LOCKEXT
:0 Wc
* $ ! ? test -f $USER_LOGFILE
| touch $USER_LOGFILE && chown ${LOGNAME}.mail $USER_LOGFILE && chmod 640
$USER_LOGFILE
#
# if log has more than 6,000 lines, cut it back to 3000
#
:0 EWc
* $ ? test `wc -l < $USER_LOGFILE` -gt 6000
| cp -p $USER_LOGFILE ${USER_LOGFILE}.tmp ; tail -3000 ${USER_LOGFILE}.tmp >
$USER_LOGFILE ; rm -f ${USER_LOGFILE}.tmp
LOCKFILE # release lock
}
Now, it turns out that /var/mail_log is owner=root,group=mail and is only
owner/group writeable, which is as it should be. But the problem is that if
the logfile doesn't exist, or needs to trimmed (on the fly, this was added
later)
then a file must be created in that directory, and only 'root' or a user in
the
'mail' group can do that.
When the /etc/procmailrc script is run directly form a user account,
procmail
complains that it can't write to the logfile (because it couldn't be created
by the user directly) and this error message is dumped by sendmail to the
system log.
The other parts of the /etc/procmailrc script that need to write to
/var/virus_trap and /var/spam_trap will likely have similar problems
as well, when they try to truncate mail boxes that have grown too large.
Obviously a short term solution is to remove the /usr/bin/procmail directive
and move the mailbox delivery into the user's .procmailrc. What I'm
wondering
is that if I want to hold to performing some front end virus and spam
scanning,
how should the /etc/procmailrc be modified so that it will operate
appropriately
when executed directly from the user's account? Add something like this at
the top of the script?
:0
* ! USER ?? ^^root^^
{ SWITCHRC }
or perhaps maintain the semantics of virus and spam trapping by doing the
following:
:0
* ! test -w /var/mail_log
{
# Can't write to /var/mail_log, therefore resort to using the user's
# home directory.
USER_LOGFILE=$HOME/procmail.log
SPAM_TRAP=$HOME/spam_trap.mbox
VIRUS_TRAP=$HOME/virus_trap.mbox
}
And then there's an idea that has been mentioned before:
:0
* test -e $HOME/.procmailrc
{
DROPPRIVS=yes
SWITCHRC
}
(I'm quickly reaching the conclusion that this sort of front-end processing
would
better be handled in a milter, like MIMEdefang.)
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail