Re: setting up spamassassin
On Wed, Jan 16, 2002 at 02:35:05PM +0100, martin f krafft wrote:
| also sprach dman <dsh8290@rit.edu> [2002.01.16.0507 +0100]:
| > | 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.
|
| i don't know exim well enough... sorry.
Right, and this ties in with the later text :
| > 3) run as user and find a different way to prevent loops
|
| what do you mean with loops? as in you run as a user and then invoke
| exim separately when done?
Exim doesn't run pipe commands immediately like procmail does (with
'f' flag). It schedules the command to be run later, and later
(during the actual delivery) it runs the command. Thus the command
_must_ deliver the message to the final (next) destination or else it
will be lost because exim is finished with it. The technique, then,
is for the output from spamassassin to be directed back to exim. exim
sees this as a new messge to deliver, though. You can see how this
would lead to an infinite loop of spamscanning everything.
The solution is to have a "condition =" in the director that causes
spamassassin to be run. The current condition is if
$received_protocol isn't "spam-scanned" then the message is handled by
that director and sent through spamassassin. Otherwise that director
doesn't handle the message and it passes to the next director to see
if that is how the message should be delivered. $received_protocol
is how exim got the message, usually 'local' or 'esmtp', but can be
set on the command line by "privileged" users.
| why do you insist on using exim till the actual delivery?
I like my filter file :-). Perhaps the above explanation helps too.
| > 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.
|
| i agree. too bad spamassassin is open source. uh, wait... :)
:-).
| > 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.
|
| okay, that's your main point. however, my script's really just plain
| simple...
It was more complicated than the (essentially) one-liner I had :-).
I'm not a perl nut either (I avoid it when I can :-)). I like the
idea of having a program that can be used as a black box. You can
configure it with a combination of system-wide and user-local files
and also with command line options. Each user (or admin) shouldn't
have to code their own interface to the system. It is cool, though,
that (for some) it is easy to do that if they don't like the given
interface.
| > 1) no user prefs
|
| depends on the user base. for instance, the users on some of my systems
| can't even spell "shell account". so i do it globally anyway. those
| power users who want full control can create ~/.no-spamfilter and use
| spamassassin -P from their procmail. simple as that.
Doesn't spamassassin combine the global (/etc/spamassassin.*) config
with the user's anyways?
| > 2) play some tricks to set $HOME and tell users that mail/mail
| > must be able to read their prefs
|
| good luck! telling users anything :)
:-). Fortunately for me, I'm the only user right now. Still, I want
the setup to be "proper" and allow for customization at the user
level, especially since I expect to admin larger systems at some
point.
| i think this might even warrant a cronjob to do 0644 on
| /home/*/.spamassasin.rc
Good idea, but what if someone changes the perms after the last cron
run and before the spamassassin run? This would probably need to be
done right before spamassassin is run, which would require root perms
in the spamcheck script (which can certainly be dropped, but still,
this doesn't seem right).
| > > 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.
|
| well right, but i personally like the spamassasin report in the body (i
| can always delete it again with vi), and others simply hate it.
Can't this be overridden by the user's config? I believe, also, that
using the existence of files to trigger or disable a check can be
added to the condition in the director, so exim can do that part too.
| the spam flag will always be there, but i've had users who objected
| to a program even having access to their mail. i refrained from
| explaining what postfix does. these are executives ;)
LOL! If a program doesn't touch the mail ... then the mail must be
only a figment of your imagination (or hand-written snail-mail).
-D
--
After you install Microsoft Windows XP, you have the option to create
user accounts. If you create user accounts, by default, they will have
an account type of administrator with no password.
-- bugtraq
Reply to: