user_prefs read from somewhere else

[Alex Thor]

Hi there!

Is there a way to convince spamassassin to read the *user_prefs* file 
not from ~/.spamassassin/  but let's say /var/mail//.spamassassin/ ?


I use sendmail with spamassassin milter, whereby spamass-milter starts 
with 
-u defaultuser


Thanks in advance!
Alex

user_prefs read from somewhere else

[Alex Thor]

Hi there!

Is there a way to convince spamassassin to read the *user_prefs* file 
not from ~/.spamassassin/  but let's say /var/mail//.spamassassin/ ?


I use sendmail with spamassassin milter, whereby spamass-milter starts 
with -u defaultuser


Thanks in advance!
Alex

Re: RE: only user_prefs from root read

[Alex Thor.]

On 2006-07-15 01:21, Gary V wrote:
> Not sure if this still applies, but you have:
> 
> /opt/csw/sbin/spamass-milter -p /var/run/spamass.sock -f
> 
> According to:
> http://www.monkey.org/freebsd/archive/freebsd-questions/200411/msg01326.html
> 
> "Make sure you are passing spamass-milter the "-u defaultuser" flag;
> otherwise it won't try to extract the recipient name from the incoming
> email."
> 
> Gary V
> 
> 
> 
Thanks!
it works like a charm! :)

Alex

Re: RE: only user_prefs from root read

[Alex Thor.]

On 2006-07-14 22:39, Gary V wrote:
> >>hello,
> >>
> >>Spamassassin has been working for a few days now, i'm quite
satisfied
> >>with it (actually i haven't got a single spam since then :) )
> >>my only problem:
> >>it seems that spamass doesn't/cann't read the individual user_prefs
> >>files.
> >>
> >>i use a sendmail dual configuration, amavisd-new, and spamass-milter
> >>
> >
> >There is only one user when you run amavisd-new - the amavisd-new
user 
> >(usually amavis or vscan).

amavisd should have nothing to do with spamass-milter

> > Only the user prefs for that user are read when 
> >amavisd-new scans a message with spamassassin.

correct

> > I'm not familiar with 
> >sendmail or spamass-milter, but I would imagine amavisd-new runs
after 
> >spamass-milter,

indeed. amavisd-new is relaying between the two MTA-sendmails

> > so any mail passed to amavisd-new will have the previous 
> >spamassassin results ignored. If spam checks are enabled in
amavisd-new, 
> >you are running the mail through spamassassin twice.

spam checks are disabled in amavisd-new

> >
> >Gary V
> 
> This may also apply:
> http://marc.theaimsgroup.com/?l=spamassassin-users

i disagree here, spamass-milter can definitively handle per-user prefs,
that's the reason i chose it in the first place :)
...but i'm still doing something wrong

thanks,
Alex

only user_prefs from root read

[Alex Thor.]

hello,

Spamassassin has been working for a few days now, i'm quite satisfied
with it (actually i haven't got a single spam since then :) )
my only problem:
it seems that spamass doesn't/cann't read the individual user_prefs
files.

i use a sendmail dual configuration, amavisd-new, and spamass-milter

here some config files/outputs


-
root 21075 1   0 22:51:33 ?   0:05 /opt/csw/bin/perl
-T /opt/csw/bin/spamd -d -u spamd
root 21080 1   0 22:51:51 ?
0:02 /opt/csw/sbin/spamass-milter -p /var/run/spamass.sock -f
   spamd 21077 21075   0 22:51:40 ?   0:10 /opt/csw/bin/perl
-T /opt/csw/bin/spamd -d -u spamd
   spamd 21076 21075   3 22:51:40 ?   1:13 /opt/csw/bin/perl
-T /opt/csw/bin/spamd -d -u spamd




#less /etc/mail/sendmail-rx.mc


...


INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=T,
T=C:15m;S:4m;R:4m;E:10m')dnl
define(`confMILTER_MACROS_CONNECT',`b, j, _, {daemon_name}, {if_name},
{if_addr}')dnl

...


-





#less /opt/csw/etc/spamassassin/local.cf

allow_user_rules 1


clear_report_template
clear_unsafe_report_template

required_score 3

use_bayes 1

bayes_auto_learn 1


i use

spamass_milter  0.3.0 
spamassassin3.1.3

 on a


#uname -a
SunOS name 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-4
----

what did i do wrong?

Thanks! 
Alex Thor.