Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: SpamAssassin: users

Spamassassin - Per User

 

 

SpamAssassin users RSS feed   Index | Next | Previous | View Threaded


wess at eliquid

Feb 11, 2004, 7:09 AM

Post #1 of 11 (634 views)
Permalink
Spamassassin - Per User

Currently I have spamassassin running globally via spamd with procmail.

Is it possible to specify which users can use spamassassin, and which
cannot? I wish to change from spamd to calling spamassassin per user.

I would really like to allow a certain group to use spamassassin, and
have spamassassin not see the other email addresses.

Is this possible? How would I do this?


Wess Bechard
Systems Admin
eliquidMEDIA
International Inc.

wess [at] eliquid
519.973.1930 -1.800.561.7525


apthorpe+sa at cynistar

Feb 11, 2004, 7:28 AM

Post #2 of 11 (625 views)
Permalink
Re: Spamassassin - Per User [In reply to]

Hi,

On Wed, 11 Feb 2004 09:09:48 -0500 Wess Bechard <wess [at] eliquid> wrote:

> Currently I have spamassassin running globally via spamd with procmail.
>
> Is it possible to specify which users can use spamassassin, and which
> cannot? I wish to change from spamd to calling spamassassin per user.

Using spamassassin instead of spamc/spamd will incur a substantial
performance hit.

You could probably do something with procmail and $LOGNAME where you
pass mail through spamc if $LOGNAME is in a list of allowed spamassassin
users. I doubt that running spamassassin vs spamc/spamd is going to
solve this problem.

> I would really like to allow a certain group to use spamassassin, and
> have spamassassin not see the other email addresses.

Are there certain users you don't trust to use SpamAssassin or are there
accounts that you don't want to filter (e.g. role accounts)? If it's the
latter, consider using the all_spam_to directives in your global config
file. From 'perldoc Mail::SpamAssassin::Conf':

----
whitelist_to add [at] ress
If the given address appears as a recipient in the
message headers (Resent-To, To, Cc, obvious envelope
recipient, etc.) the mail will be whitelisted. Useful
if you're deploying SpamAssassin system-wide, and
don't want some users to have their mail filtered.
Same format as "whitelist_from".

There are three levels of To-whitelisting,
"whitelist_to", "more_spam_to" and "all_spam_to".
Users in the first level may still get some spammish
mails blocked, but users in "all_spam_to" should never
get mail blocked.

more_spam_to add [at] ress
See above.

all_spam_to add [at] ress
See above.
----

hth,

-- Bob


wess at eliquid

Feb 11, 2004, 7:34 AM

Post #3 of 11 (623 views)
Permalink
Re: Spamassassin - Per User [In reply to]

How would I set procmail to check and see if $LOGNAME is on the list of
allowed accounts? That would be perfect. I would much rather stick
with spamc/spamd.

I am making this change because some users do not want spam filtered.
This $LOGNAME check would be perfect if i knew how to do it.



On Wed, 2004-02-11 at 09:28, Bob Apthorpe wrote:

> Hi,
>
> On Wed, 11 Feb 2004 09:09:48 -0500 Wess Bechard <wess [at] eliquid> wrote:
>
> > Currently I have spamassassin running globally via spamd with procmail.
> >
> > Is it possible to specify which users can use spamassassin, and which
> > cannot? I wish to change from spamd to calling spamassassin per user.
>
> Using spamassassin instead of spamc/spamd will incur a substantial
> performance hit.
>
> You could probably do something with procmail and $LOGNAME where you
> pass mail through spamc if $LOGNAME is in a list of allowed spamassassin
> users. I doubt that running spamassassin vs spamc/spamd is going to
> solve this problem.
>
> > I would really like to allow a certain group to use spamassassin, and
> > have spamassassin not see the other email addresses.
>
> Are there certain users you don't trust to use SpamAssassin or are there
> accounts that you don't want to filter (e.g. role accounts)? If it's the
> latter, consider using the all_spam_to directives in your global config
> file. From 'perldoc Mail::SpamAssassin::Conf':
>
> ----
> whitelist_to add [at] ress
> If the given address appears as a recipient in the
> message headers (Resent-To, To, Cc, obvious envelope
> recipient, etc.) the mail will be whitelisted. Useful
> if you're deploying SpamAssassin system-wide, and
> don't want some users to have their mail filtered.
> Same format as "whitelist_from".
>
> There are three levels of To-whitelisting,
> "whitelist_to", "more_spam_to" and "all_spam_to".
> Users in the first level may still get some spammish
> mails blocked, but users in "all_spam_to" should never
> get mail blocked.
>
> more_spam_to add [at] ress
> See above.
>
> all_spam_to add [at] ress
> See above.
> ----
>
> hth,
>
> -- Bob

Wess Bechard
Technical Support
eliquidMEDIA
International Inc.

wess [at] eliquid
519.973.1930 -1.800.561.7525


wess at eliquid

Feb 11, 2004, 7:57 AM

Post #4 of 11 (630 views)
Permalink
Re: Spamassassin - Per User [In reply to]

I have modified procmail to check for .spamcheck in the user's home
dir. If this file is found, spamc is called. Seems to work so far.

I would still rather use a managable file that lists users.

Would anyone out there know how to make procmail check a list for a
username?



On Wed, 2004-02-11 at 09:28, Bob Apthorpe wrote:

> Hi,
>
> On Wed, 11 Feb 2004 09:09:48 -0500 Wess Bechard <wess [at] eliquid> wrote:
>
> > Currently I have spamassassin running globally via spamd with procmail.
> >
> > Is it possible to specify which users can use spamassassin, and which
> > cannot? I wish to change from spamd to calling spamassassin per user.
>
> Using spamassassin instead of spamc/spamd will incur a substantial
> performance hit.
>
> You could probably do something with procmail and $LOGNAME where you
> pass mail through spamc if $LOGNAME is in a list of allowed spamassassin
> users. I doubt that running spamassassin vs spamc/spamd is going to
> solve this problem.
>
> > I would really like to allow a certain group to use spamassassin, and
> > have spamassassin not see the other email addresses.
>
> Are there certain users you don't trust to use SpamAssassin or are there
> accounts that you don't want to filter (e.g. role accounts)? If it's the
> latter, consider using the all_spam_to directives in your global config
> file. From 'perldoc Mail::SpamAssassin::Conf':
>
> ----
> whitelist_to add [at] ress
> If the given address appears as a recipient in the
> message headers (Resent-To, To, Cc, obvious envelope
> recipient, etc.) the mail will be whitelisted. Useful
> if you're deploying SpamAssassin system-wide, and
> don't want some users to have their mail filtered.
> Same format as "whitelist_from".
>
> There are three levels of To-whitelisting,
> "whitelist_to", "more_spam_to" and "all_spam_to".
> Users in the first level may still get some spammish
> mails blocked, but users in "all_spam_to" should never
> get mail blocked.
>
> more_spam_to add [at] ress
> See above.
>
> all_spam_to add [at] ress
> See above.
> ----
>
> hth,
>
> -- Bob

Wess Bechard
Technical Support
eliquidMEDIA
International Inc.

wess [at] eliquid
519.973.1930 -1.800.561.7525


apthorpe+sa at cynistar

Feb 11, 2004, 8:10 AM

Post #5 of 11 (634 views)
Permalink
Re: Spamassassin - Per User [In reply to]

On Wed, 11 Feb 2004 09:57:12 -0500 Wess Bechard <wess [at] eliquid> wrote:

> I have modified procmail to check for .spamcheck in the user's home
> dir. If this file is found, spamc is called. Seems to work so far.
>
> I would still rather use a managable file that lists users.
>
> Would anyone out there know how to make procmail check a list for a
> username?

I'm no procmail expert, but would something like this work?

:0
| grep --silent "$LOGNAME" allowed_sa_users.txt

:0 a
| /usr/bin/spamc -u "$LOGNAME"

This assumes per-user configuration with spamc; if not, drop the '-u
"$LOGNAME"' fragment. Also, I'm not sure if you have to discard STDIN in
the call to grep (a simple test says no); otherwise, you can wrap it in
a shell script.

hth,

-- Bob


ericx_lists at vineyard

Feb 11, 2004, 8:19 AM

Post #6 of 11 (637 views)
Permalink
Re: Spamassassin - Per User [In reply to]

The system we use writes a custom .forward, .procmailrc, and
.spamassassin/* based on user choices in mysql based on their choices on
a cgi.

So at it's simplest level, only those users who wish to be filtered have
a .forward file at all.

Wess Bechard wrote:

> I have modified procmail to check for .spamcheck in the user's home
> dir. If this file is found, spamc is called. Seems to work so far.
>
> I would still rather use a managable file that lists users.
>
> Would anyone out there know how to make procmail check a list for a
> username?
>
>
>
> On Wed, 2004-02-11 at 09:28, Bob Apthorpe wrote:
>
>>/Hi,
>>
>>On Wed, 11 Feb 2004 09:09:48 -0500 Wess Bechard <wess [at] eliquid> wrote:
>>
>>> Currently I have spamassassin running globally via spamd with procmail.
>>>
>>> Is it possible to specify which users can use spamassassin, and which
>>> cannot? I wish to change from spamd to calling spamassassin per user.
>>
>>Using spamassassin instead of spamc/spamd will incur a substantial
>>performance hit.
>>
>>You could probably do something with procmail and $LOGNAME where you
>>pass mail through spamc if $LOGNAME is in a list of allowed spamassassin
>>users. I doubt that running spamassassin vs spamc/spamd is going to
>>solve this problem.
>>
>>> I would really like to allow a certain group to use spamassassin, and
>>> have spamassassin not see the other email addresses.
>>
>>Are there certain users you don't trust to use SpamAssassin or are there
>>accounts that you don't want to filter (e.g. role accounts)? If it's the
>>latter, consider using the all_spam_to directives in your global config
>>file. From 'perldoc Mail::SpamAssassin::Conf':
>>
>>----
>> whitelist_to add [at] ress
>> If the given address appears as a recipient in the
>> message headers (Resent-To, To, Cc, obvious envelope
>> recipient, etc.) the mail will be whitelisted. Useful
>> if you're deploying SpamAssassin system-wide, and
>> don't want some users to have their mail filtered.
>> Same format as "whitelist_from".
>>
>> There are three levels of To-whitelisting,
>> "whitelist_to", "more_spam_to" and "all_spam_to".
>> Users in the first level may still get some spammish
>> mails blocked, but users in "all_spam_to" should never
>> get mail blocked.
>>
>> more_spam_to add [at] ress
>> See above.
>>
>> all_spam_to add [at] ress
>> See above.
>>----
>>
>>hth,
>>
>>-- Bob/
>>
> Wess Bechard
> Technical Support
> eliquidMEDIA
> International Inc.
>
> _wess [at] eliquid <mailto:wess [at] eliquid>
> 519.973.1930 -1.800.561.7525
>
>


chris-barnes at tamu

Feb 11, 2004, 8:42 AM

Post #7 of 11 (627 views)
Permalink
Re: Spamassassin - Per User [In reply to]

Wess Bechard <wess [at] eliquid> wrote:
> I have modified procmail to check for .spamcheck in the user's home
> dir. If this file is found, spamc is called. Seems to work so far.
>
> I would still rather use a managable file that lists users.
>
> Would anyone out there know how to make procmail check a list for a
> username?


Imho, this is still the wrong method. You would be MUCH better off
using the all_spam_to directive in the config file - even if the list of
ids is quite long.


--

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chris Barnes AOL IM: CNBarnes
chris-barnes [at] tamu Yahoo IM: chrisnbarnes
Computer Systems Manager ph: 979-845-7801
Department of Physics fax: 979-845-2590
Texas A&M University


rpuhek at etnsystems

Feb 11, 2004, 9:10 AM

Post #8 of 11 (620 views)
Permalink
Re: Spamassassin - Per User [In reply to]

Wess Bechard wrote:

> I have modified procmail to check for .spamcheck in the user's home
> dir. If this file is found, spamc is called. Seems to work so far.
>
> I would still rather use a managable file that lists users.
>
> Would anyone out there know how to make procmail check a list for a
> username?
>
>
>

The following setup works for me. It's a bit of a kludge, but it's held
up well under heavy use. I tried to ensure that failure of anything
allong the line results in processing through SA.

FWIW: all spam to has issues in this application in the case of multiple
recipients. I believe the issue was having an "all_spam_to" person along
with a regular person in the To: header didn't do the right thing. This
was my solution after a couple of angry calls.


--Rich


#/etc/procmailrc setup:
#################
# #
# SpamAssassin #
# #
#################
:0fw
# skip passing to spamc/spamd if user is on
# exempt list, or if message is really big.
# all_spam_to has problems, and why burden
# the server w/large messages if we can
# catch them here!
* < 500000
* ! ? /usr/local/bin/nospam.pl $LOGNAME
|/usr/bin/spamc -s 100000 -d <SPAMD SERVERNAME> -p 783

The script:

#!/usr/bin/perl
#
# nospam.pl -- accept username as option,
# check a list of names, see if
# user wants spam scanning or not
# 0 = skip scanning
# nonzero = scan (fail "safe" so that
# majority of users are scanned)
# rpuhek [at] etnsystems

$userfile="/etc/spamassassin/exempt";
$found="false";

$user=$ARGV[0];

open USERS,$userfile or die "unable to open $userfile $!\n";
while (<USERS>) {
next if ( /^#/ );
if ( /^$user$/ ) {
$found="true";
last;
};
};

close USERS;

if ( $found eq "true" ){
exit 0;
};

#print "exiting w/spam checking!\n";
exit 1;


gary at intrepid

Feb 11, 2004, 9:35 AM

Post #9 of 11 (638 views)
Permalink
RE: Spamassassin - Per User [In reply to]

Looks good, below, but a couple of procmail/perl suggestions ...

> #/etc/procmailrc setup:
> #################
> # #
> # SpamAssassin #
> # #
> #################
> :0fw
> # skip passing to spamc/spamd if user is on
> # exempt list, or if message is really big.
> # all_spam_to has problems, and why burden
> # the server w/large messages if we can
> # catch them here!
> * < 500000
> * ! ? /usr/local/bin/nospam.pl $LOGNAME
> |/usr/bin/spamc -s 100000 -d <SPAMD SERVERNAME> -p 783
>

Above, the '< 500000' check, I believe, exceeds spamc/spamd's
maximum limit of 250000, so you might want to bring that in a bit. I see
you're using 100000 in the spamc invocation.

> The script:
>
> #!/usr/bin/perl
> #
> # nospam.pl -- accept username as option,
> # check a list of names, see if
> # user wants spam scanning or not
> # 0 = skip scanning
> # nonzero = scan (fail "safe" so that
> # majority of users are scanned)
> # rpuhek [at] etnsystems
>
> $userfile="/etc/spamassassin/exempt";
> $found="false";
>

More typical Perl style would be to use 1/0 for true/false.

> $user=$ARGV[0];
>
> open USERS,$userfile or die "unable to open $userfile $!\n";
> while (<USERS>) {
> next if ( /^#/ );
> if ( /^$user$/ ) {
> $found="true";
> last;
> };
> };

Since user-ids should be considered case insentitive, you might want to
lowercase your user-id,
$user = lc $ARGV[0];
and make sure that your list of exempt users is all lower-case as well.
The you can modify the check above to just do a straight string comparison
rather than a regex. You'll need to 'chomp' the line first to discard the
newline:

open USERS,$userfile or die "unable to open $userfile $!\n";
while (<USERS>) {
chomp;
next if ( /^#/ );
return 1 if ($user eq $_);
};

If your list gets big and you don't want to go to a more complicated
set up using DB files, you might take a look at John Connover's useful
flat file search utility:
http://www.johncon.com/ndex/


rpuhek at etnsystems

Feb 11, 2004, 11:07 AM

Post #10 of 11 (635 views)
Permalink
Re: Spamassassin - Per User [In reply to]

Gary Funck wrote:

> Looks good, below, but a couple of procmail/perl suggestions ...
>
(snip)
>
>
> Above, the '< 500000' check, I believe, exceeds spamc/spamd's
> maximum limit of 250000, so you might want to bring that in a bit. I see
> you're using 100000 in the spamc invocation.
>
>

Yea, the < 500000 is just kind of a sanity check.. belt and suspenders
thing. I figured that I'll short-circuit real large email from even
checking the nospam.pl list. There's really no reason to have the
procmail test different than the spamc limit, just left it there since
the spamc limit does its job.

I'll bring it down to match... might as well avoid calling spamc if it's
not going to do anything.

>>The script:
>>
>>#!/usr/bin/perl
>>#
>># nospam.pl -- accept username as option,
>># check a list of names, see if
>># user wants spam scanning or not
>># 0 = skip scanning
>># nonzero = scan (fail "safe" so that
>># majority of users are scanned)
>># rpuhek [at] etnsystems
>>
>>$userfile="/etc/spamassassin/exempt";
>>$found="false";
>>
>
>
> More typical Perl style would be to use 1/0 for true/false.

I used the long name for readability... since I'm not returning the
value itself. Old habit from when I used to do "#define true 1" :-)


>>$user=$ARGV[0];
>>
>>open USERS,$userfile or die "unable to open $userfile $!\n";
>>while (<USERS>) {
>> next if ( /^#/ );
>> if ( /^$user$/ ) {
>> $found="true";
>> last;
>> };
>>};
>
>
> Since user-ids should be considered case insentitive, you might want to
> lowercase your user-id,
> $user = lc $ARGV[0];
> and make sure that your list of exempt users is all lower-case as well.
> The you can modify the check above to just do a straight string comparison
> rather than a regex. You'll need to 'chomp' the line first to discard the
> newline:
>
> open USERS,$userfile or die "unable to open $userfile $!\n";
> while (<USERS>) {
> chomp;
> next if ( /^#/ );
> return 1 if ($user eq $_);
> };
>

I guess I was assuming that the $LOGNAME will be the correct case, and
that we'll enter the correct username. I do like the string comparason
better, though.

> If your list gets big and you don't want to go to a more complicated
> set up using DB files, you might take a look at John Connover's useful
> flat file search utility:
> http://www.johncon.com/ndex/
>
Using a DBM wouldn't be bad as far as complexity. Would actually
simplify the lookup:

dbmopen %exempt, $exempt_file or die "blah blah $!";

if (defined $exempt{$user}) {
return 1;
} else {
return 0;
};

(to add to the list would be something like: perl -e 'dbmopen %exempt,
/etc/spamassassin/exempt; $exempt{"someuser"} = 1; dbmclose %exempt'
script as necessary...)

If the list gets huge, or if the volume gets large enough (more likely
to happen, and more likely to impact performance), I'm thinking that
I'll have to seperate into two parts, spamd/spamc style. The daemon
portion would just hold the exempt list in memory (well, I'd store it as
a perl hash).

I haven't profiled the code at all, but I'd guess that the overhead of
opening the exemption list, along with just starting up the program, is
much greater than searching the list. Sure it's an O(n) search, but the
list's size is quite small.

Thanks for the input!

--Rich


jp at saucer

Feb 11, 2004, 3:20 PM

Post #11 of 11 (625 views)
Permalink
Re: Spamassassin - Per User [In reply to]

We have SA enabled for everybody. We tell people who don't want SA to do
anything to their email to set their threshold to 100.

Works good for 10,000+ account here.

-Jason

On Wed, Feb 11, 2004 at 09:57:12AM -0500, Wess Bechard wrote:
> I have modified procmail to check for .spamcheck in the user's home
> dir. If this file is found, spamc is called. Seems to work so far.
>
> I would still rather use a managable file that lists users.
>
> Would anyone out there know how to make procmail check a list for a
> username?
>
>
>
> On Wed, 2004-02-11 at 09:28, Bob Apthorpe wrote:
>
> > Hi,
> >
> > On Wed, 11 Feb 2004 09:09:48 -0500 Wess Bechard <wess [at] eliquid> wrote:
> >
> > > Currently I have spamassassin running globally via spamd with procmail.
> > >
> > > Is it possible to specify which users can use spamassassin, and which
> > > cannot? I wish to change from spamd to calling spamassassin per user.
> >
> > Using spamassassin instead of spamc/spamd will incur a substantial
> > performance hit.
> >
> > You could probably do something with procmail and $LOGNAME where you
> > pass mail through spamc if $LOGNAME is in a list of allowed spamassassin
> > users. I doubt that running spamassassin vs spamc/spamd is going to
> > solve this problem.
> >
> > > I would really like to allow a certain group to use spamassassin, and
> > > have spamassassin not see the other email addresses.
> >
> > Are there certain users you don't trust to use SpamAssassin or are there
> > accounts that you don't want to filter (e.g. role accounts)? If it's the
> > latter, consider using the all_spam_to directives in your global config
> > file. From 'perldoc Mail::SpamAssassin::Conf':
> >
> > ----
> > whitelist_to add [at] ress
> > If the given address appears as a recipient in the
> > message headers (Resent-To, To, Cc, obvious envelope
> > recipient, etc.) the mail will be whitelisted. Useful
> > if you're deploying SpamAssassin system-wide, and
> > don't want some users to have their mail filtered.
> > Same format as "whitelist_from".
> >
> > There are three levels of To-whitelisting,
> > "whitelist_to", "more_spam_to" and "all_spam_to".
> > Users in the first level may still get some spammish
> > mails blocked, but users in "all_spam_to" should never
> > get mail blocked.
> >
> > more_spam_to add [at] ress
> > See above.
> >
> > all_spam_to add [at] ress
> > See above.
> > ----
> >
> > hth,
> >
> > -- Bob
>
> Wess Bechard
> Technical Support
> eliquidMEDIA
> International Inc.
>
> wess [at] eliquid
> 519.973.1930 -1.800.561.7525

--
/*
Jason Philbrook | Midcoast Internet Solutions - Internet Access,
KB1IOJ | Hosting, and TCP-IP Networks for Midcoast Maine
http://f64.nu/ | http://www.midcoast.com/
*/

SpamAssassin users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.