Re: setting up spamassassin

[dman <dsh8290@rit.edu>]

On Wed, Jan 16, 2002 at 03:47:14AM +0100, martin f krafft wrote:
| also sprach dman <dsh8290@rit.edu> [2002.01.16.0333 +0100]:
| > 1)  Why is spamassassin trying to create a preferences file in /?
| 
| $HOME isn't set in the script.

Good point.  If I set 
    HOME=/tmp
in the script, then spamassassin creates /tmp/.spamassassin.cf (and
tells me on stderr).

| does exim already have the recipient user by the time the filter is called?

It does, and I _could_ run the script as the user.  The problem there
is only "privileged" (in exim's eyes) users are allowed to set the
received_protocol.  

| > 2)  How can users have their own preferences files?  It doesn't seem
| >     possible with this setup since either SA is run as 'mail' or every
| >     user on the system must be 'privilege'.
| 
| there you go, that's the problem. spamassassin is actually designed to
| be run by a user. period.

I think a command line option should be available to say "don't create
a prefs file".  That should be the user's job anyways.

| if you want to do it globally, you have a global prefs file.
| 
| here's my solution:
| 
| i decided i am going to use procmail for delivery (remember my post
| about a .forward and Maildir capable MDA? i ditched .forward for good).
| 
| but instead of telling postfix/local to use procmail as MDA (by that
| time, it knows the recipient, it calls the MDA as the recipient user), i
| wrote a perl-script. and made use of Mail::SpamAssassin, which is still
| wicked slow (spamassassin is), but it's way faster than the command
| invocation.
...

Looks complicated.  I like the simplicity of using the existing
command.  I don't want spamassassin doing the actual delivery anyways,
I want exim (with my filter file) to do it.

I think my choices are

    1)  no user prefs
    2)  play some tricks to set $HOME and tell users that mail/mail
        must be able to read their prefs
    3)  run as user and find a different way to prevent loops

Number 2 would actually be easy to do.

Number 3 has the following tradeoffs :
    If all users are "privileged" then any user can fake the
        $received_protocol.  This probably isn't terribly harmful, but
        is not a good path to tak.
    If I use a different technique to prevent loops (like checking for
    the X-Spam-* headers) then anyone (even the spammer) could create
    the headers and bypass the checking.


| it's nice, because users can touch files ~/.no-spamfilter to completely
| disable spamassassin for themselves, and a file ~/.no-spamreport will
| just cause the "X-Spam-Flag: YES" header, not the subject line change
| and SA report in the body.

These are interesting options.  In my setup the user (via their filter
file) will need to decide to discard the message if they want to.  For
myself, I'm just sticking it into =junk so I can check it later if I
want to.


Thanks for your input martin.

-D

-- 

Be sure of this:  The wicked will not go unpunished,
but those who are righteous will go free.
        Proverbs 11:21