At 08:38 2004-02-03 -0800, Gary Funck wrote:
The script filters mail as follows:
/var/mail_log/${LOGNAME}.log - procmail log of recent transactions
/var/virus_trap/${LOGNAME} - place where likely viruses are dumped
/var/spam_trap/${LOGNAME} - place where likely spam is dumped
$HOME/spam.mbox - place where marginal spam is dumped
Hmm, do these users have the sophistication to open the spam.mbox file
periodically? Otherwise, it'll fill up. Hopefully, you've got a cron job
or something that can rotate the mbox, dumping it periodically (I realize
you mention something of this about the files in /var/, but the one in the
users homedir is equally important, yet more touchy, since it is in their
homedir).
The motivation for creating a global virus trap and spam trap was to lower
the load on the users.
The global virus trap will lower the load on _everybody_, esp if there are
noobie users there. <g>
deletes old virus and spam e-mails, or this could be done on an on-demand
basis in script at some point.
Suggestion: user management pages which require authentication, and then
once authenticated, the user has access to weblinks which invoke (or if its
easier to digest, queue) scripts on their behalf. Same goes for setting
options.
But depositing the logs, virus mail, and definite spam into a system-wide
location presented some difficulties. Mainly, I wanted to make sure those
files are readable by the user who was the intended recipient (and not
by others).
Well, your recipe seems to have it covered operationally. If instead you
were delivering directly to the mailbox from procmail, you can set UMASK as
appropriate, in which case procmail will do the chmod-like operation
itself, eliminating one more called program.
can I depend upon procmail to create that file with the recipient as owner
of the file? (the containing directory is owner=root,group=mail and is
writeable
If you want to do this, simply DROPPRIVS=YES before delivery. They'll need
appropriate write access to the directory in question though.
only by owner/group and rx everyone). Or would procmail create it on behalf
of the current user, which is root (or mail)?
Correctumundo.
#
# Invoke spamasassin to check for spam.
#
:0 fw:$SA_LOCK
* $ ? test -x $SA
| su $LOGNAME -c "$SA"
I wanted to make sure that spamassassin is run under the user-id of
the recipient, so that SA can pick up local user preferences, local
Bayes database and so on. The SA_LOCK is just to serialize things on
a per-user basis to lower overall system load a bit. Still, this
all seemed a little clunky.
- The bigger question I have is: Is keeping the logs, the virus mail,
the almost-certain spam mail in a global location worth the fuss?
It's certainly a bit more difficult when you want to do many of the global
operations as if you were the user, but without releasing privledges.
The script would've been a _lot_ simpler, if DROPPRIVS took effect
at the beginning and all these files were just deposited in the recipient's
$HOME directory.
DROPPRIVS takes effect at whatever point you set it. To use it, all you
need to do is ensure that the user can actually create files in the
individual directories you're operating within, then use it up top, and the
rest should come naturally.
- I'm concerned that the users may have some trouble navigating
the spam folder in /var/spam_trap/$LOGNAME, and may even require a link from
their home directory back to the spam_trap folder to easily access it from
their mail client application.
Agreed, esp with noobie users.
- A downside to using this /etc/procmailrc approach is that some decisions
are being made for the user: where to put the virus mail, almost-certain
spam, marginal spam, and logs. If the user had their own filtering/filing
rules for spam (one user did, but won't mind the change), they've just
been pre-empted by the sitewide procmailrc.
Have procmail grab configuration options from the user directory, or have a
db that the user can update on their own behalf (say, via a web interface)
where they can enable/disable specific features, and the global procmailrc
will retrieve those settings and use them. I've posted a number of
messages to this list in the past which detail different approaches to
implementing this.
- My other concern is how will the users interact with the two categories of
spam mail folders? How will whitelisting be implemented (will they be shown
how to edit $HOME/spamassassin/user_prefs in order to add from_whitelist
and from_whitelist_rcvd directives? Many users won't know how to do that.
Is there a simple GUI that someone has come up with for that?
That's a question best posed to the SA list. While there's a few people
here who seem to use SA, from my reading, it certainly appears that the
bulk still recognize that their own filters can often do a better job, and
at least they know the specifics.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail