RE: ANNOUNCE: Apache SpamAssassin 3.2.2 available

2007-07-25 Thread Chris Blaise

Running without the daemon option makes it clear:

$ /usr/bin/spamd -x --max-conn-per-child=20 --socketpath=/dev/spamd
--socketgroup=mail -m3 --min-spare=3 -u mail

...
[4463] info: spamd: server started on UNIX domain socket /dev/spamd (running
version 3.2.2)
[4463] info: spamd: server pid: 4463
spamd: setuid to uid 8 failed
[4463] info: spamd: server successfully spawned child process, pid 4468
[4463] info: spamd: server successfully spawned child process, pid 4469
spamd: setuid to uid 8 failed
[4463] info: spamd: server successfully spawned child process, pid 4470
[4463] info: prefork: child states: SSS
[4463] info: prefork: server reached --max-children setting, consider
raising it
[4463] info: spamd: handled cleanup of child pid 4468 due to SIGCHLD
spamd: setuid to uid 8 failed
[4463] info: spamd: server successfully spawned child process, pid 4471
spamd: setuid to uid 8 failed
[4463] info: prefork: child states: SSS
[4463] info: prefork: server reached --max-children setting, consider
raising it
[4463] info: spamd: handled cleanup of child pid 4469 due to SIGCHLD
spamd: setuid to uid 8 failed

This is the die() message from when the setgid/setuid functions are
called:

...
  # bug 5518: assignments to $) and $( don't always work on all
platforms
  # bug 3900: assignments to $> and $< problems with BSD perl bug
  # use the POSIX functions to hide the platform specific workarounds
  POSIX::setgid($ugid);  # set effective and real gid
  POSIX::setuid($uuid);  # set effective and real UID

  # keep the sanity check to catch problems like bug 3900 just in case
  if ( $> != $uuid and $> != ( $uuid - 2**32 ) ) {
die "spamd: setuid to uid $uuid failed\n";
  }
...

 Chris

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 25, 2007 10:10 AM
To: Chris Blaise
Cc: users@spamassassin.apache.org
Subject: Re: ANNOUNCE: Apache SpamAssassin 3.2.2 available 

try using "strace -fp {PID}" to see what is causing those
deaths...

Chris Blaise writes:
> 
>   Can you verify that it's not in the "child create/due" loop?
> Tailing my log, I see the following:
> 
> 2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: server started on UNIX
> domai
> n socket /dev/spamd (running version 3.2.2)
> 2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: server pid: 4553
> 2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: server successfully
> spawned
> child process, pid 4556
> 2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: server successfully
> spawned
> child process, pid 4557
> 2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: server successfully
> spawned
> child process, pid 4558
> 2007 Jul 25 08:41:01 ThreatWall spamd[4553]: prefork: child states: SSS
> 2007 Jul 25 08:41:01 ThreatWall spamd[4553]: prefork: server reached
> --max-child
> ren setting, consider raising it
> 2007 Jul 25 08:41:01 ThreatWall spamd[4553]: prefork: child states: SSS
> 2007 Jul 25 08:41:01 ThreatWall spamd[4553]: prefork: server reached
> --max-child
> ren setting, consider raising it
> 2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: handled cleanup of
child
> pid
>  4556 due to SIGCHLD
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: server successfully
> spawned
> :
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: handled cleanup of
child
> pid
>  4558 due to SIGCHLD
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: prefork: child states: S
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: server successfully
> spawned
> child process, pid 4560
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: server successfully
> spawned
> child process, pid 4561
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: handled cleanup of
child
> pid
>  4559 due to SIGCHLD
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: handled cleanup of
child
> pid
>  4560 due to SIGCHLD
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: prefork: child states: S
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: server successfully
> spawned
> child process, pid 4562
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: server successfully
> spawned
> child process, pid 4563
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: prefork: child states: SSS
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: prefork: server reached
> --max-child
> ren setting, consider raising it
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: handled cleanup of
child
> pid
>  4561 due to SIGCHLD
> 2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: handled cleanup of
child
> pid
>  4562 due to SIGCHLD
> 
> 
>   Until I kill the parent spamd process.  I run it with:
> 
> /usr/bin/spamd -d -x --ma

RE: ANNOUNCE: Apache SpamAssassin 3.2.2 available

2007-07-25 Thread Chris Blaise

Can you verify that it's not in the "child create/due" loop?
Tailing my log, I see the following:

2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: server started on UNIX
domai
n socket /dev/spamd (running version 3.2.2)
2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: server pid: 4553
2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: server successfully
spawned
child process, pid 4556
2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: server successfully
spawned
child process, pid 4557
2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: server successfully
spawned
child process, pid 4558
2007 Jul 25 08:41:01 ThreatWall spamd[4553]: prefork: child states: SSS
2007 Jul 25 08:41:01 ThreatWall spamd[4553]: prefork: server reached
--max-child
ren setting, consider raising it
2007 Jul 25 08:41:01 ThreatWall spamd[4553]: prefork: child states: SSS
2007 Jul 25 08:41:01 ThreatWall spamd[4553]: prefork: server reached
--max-child
ren setting, consider raising it
2007 Jul 25 08:41:01 ThreatWall spamd[4553]: spamd: handled cleanup of child
pid
 4556 due to SIGCHLD
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: server successfully
spawned
:
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: handled cleanup of child
pid
 4558 due to SIGCHLD
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: prefork: child states: S
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: server successfully
spawned
child process, pid 4560
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: server successfully
spawned
child process, pid 4561
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: handled cleanup of child
pid
 4559 due to SIGCHLD
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: handled cleanup of child
pid
 4560 due to SIGCHLD
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: prefork: child states: S
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: server successfully
spawned
child process, pid 4562
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: server successfully
spawned
child process, pid 4563
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: prefork: child states: SSS
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: prefork: server reached
--max-child
ren setting, consider raising it
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: handled cleanup of child
pid
 4561 due to SIGCHLD
2007 Jul 25 08:41:02 ThreatWall spamd[4553]: spamd: handled cleanup of child
pid
 4562 due to SIGCHLD


Until I kill the parent spamd process.  I run it with:

/usr/bin/spamd -d -x --max-conn-per-child=20 --socketpath=/dev/spamd
--socketgroup=mail -m3 --min-spare=3 -u mail

 Chris

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 25, 2007 9:06 AM
To: Chris Blaise
Cc: users@spamassassin.apache.org
Subject: Re: ANNOUNCE: Apache SpamAssassin 3.2.2 available 


Chris Blaise writes:
>   When starting up on a Perl 5.6.1 system under x86 Linux, spamd goes
> into a child spawn/die loop because of the fix for bug 5518 which replaces
> the previous set uid/gid routines fails and causes the newly spawned child
> to immediately die.
> 
>   Is Perl 5.6.1 no longer the lowest support version?

works fine for me with perl 5.6.1; make test passes:

t/spamd.ok
t/spamd_allow_user_rulesok
t/spamd_hup.ok
t/spamd_kill_restartok
[.etc.]

and 'sudo make test TEST_FILES=t/root_spamd*' similarly passes:

t/root_spamdok
t/root_spamd_tell...ok
t/root_spamd_tell_paranoid..ok
t/root_spamd_tell_x.ok
t/root_spamd_tell_x_paranoidok
t/root_spamd_x..ok
t/root_spamd_x_paranoid.ok
All tests successful.

--j.



RE: ANNOUNCE: Apache SpamAssassin 3.2.2 available

2007-07-25 Thread Chris Blaise

When starting up on a Perl 5.6.1 system under x86 Linux, spamd goes
into a child spawn/die loop because of the fix for bug 5518 which replaces
the previous set uid/gid routines fails and causes the newly spawned child
to immediately die.

Is Perl 5.6.1 no longer the lowest support version?

 Chris



SpamAssassin CVS confusion

2005-06-06 Thread Chris Blaise

We've recently upgraded from 3.0.1 to 3.0.3 and started having
problems which sound very similar to bug 4310.

In trying to figure out what could have changed in spamd.raw between
those versions I looked at the CVS commits under
tags/spamassassin_release_3_0_1/ , tags/spamassassin_release_3_0_2/, and
tags/spamassassin_release_3_0_1/.  It didn't look like much changed.

So as per the bug report, I downloaded today's "daily build" release
(spamassassin_20050606105134.tar.gz) and through CVS and noticed that there
is considerable work on spamd.raw that is not on the release branches.  I'm
a little confused because there are many commits that seem like they should
have been in the 3.0.3 release.  In particular, I noticed:

Revision 112029 - (view) (download) - [select for diffs] Modified Wed Dec 15
21:57:03 2004 UTC (5 months, 2 weeks ago) by jm File length: 80348 byte(s)
Diff to previous 109603 (colored) bug 3828: add new timeout support to
spamd, using guarnteed SIGALRM signals on all perl versions after 5.6, to
avoid out-of-control perl OPs from hanging.

However, when I looked at the release 3.03 of spamd.raw, I don't see
this support in the code.  I guess my confusion is that will this work be in
the next release of SpamAssassin or will it continue to be on a
development-only branch?

 Thanks,
 Chris



RE: Greylisting

2005-03-02 Thread Chris Blaise

If you use exim, check out:

 http://marc.merlins.org/linux/exim/sa.html

It allows SA scanning at the MTA level and includes a GreyListing
pluging for SA3.  You should be able to configure exim to only allow it for
certain recipient addreses but you'd have to do that research yourself.

 Chris 

-Original Message-
From: Matt [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 02, 2005 6:20 AM
To: [EMAIL PROTECTED]
Subject: Greylisting

Hi,
Is there any kind of plugin or patch for spamassassin that will allow me to
selectively turn on GREYLISTing for certain user accounts?

When I say greylist I mean:  All e-mail coming into them is bounced with a
temporary error the first time, and then accepted the second
time.   If accepted (ie sent a second time) it is then put in a
database of valid e-mail accounts for the next 60 days (or until another
e-mail is received).

This has the potential to greatly reduce spam since spammers don't usually
try to send mail again, however I don't want to roll this out on a server
wide setup, but rather would like to do it on a per-user basis.

Any thoughts?

 ~ Matt



RE: AWL confusion

2004-12-20 Thread Chris Blaise

I agree it's a very misleading term.  

The easiest and most appropriate term I've heard is "historical
averaging". 

-Original Message-
From: Bill Landry [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 20, 2004 7:51 AM
To: users@spamassassin.apache.org
Subject: Re: AWL confusion

- Original Message -
From: "Rich" <[EMAIL PROTECTED]>

> > On Sun, 19 Dec 2004 17:02:06 -0500, Rich <[EMAIL PROTECTED]> wrote:
> >> So why on earth is a 17-score given to an address in an auto
white-list?
> >> Shouldn't an address get a negative score (or, at least, a neutral
zero)
> >> if it's in a WL?
> >
> > You may want to read up on the AWL in the WIKI - it explains exactly 
> > why you're seeing the scores you are.
>
> Ahh, so AWL is not a "white-list" in any way - it's a "sender history"
> score. That is quite misleading.

I agree, and that why I thought that "auto weight leveling" was a more
appropriate and correctly descriptive name than "auto whitelist".  But
that's just my 2 cents...

Bill




RE: Bayes databases losing file ownership

2004-12-02 Thread Chris Blaise

Thanks.  I'll modify the script to run as mail.

Can you think of why it wouldn't always happen?  I'd expect running
the script would always change the ownership, but it's been well over a
month (the script is run every couple of days) and this is the first time
its happened.  

And any not both files?

 Chris 

-Original Message-
From: Bob Proulx [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 02, 2004 9:37 AM
To: [EMAIL PROTECTED]
Subject: Re: Bayes databases losing file ownership

Chris Blaise wrote:
> 
>   spamd runs as mail and that's what the bayes_ files are owned as.  A

> few days ago we started seeing an increase in spam and looking into 
> the problem today, I found that the bayes_toks file (but not 
> bayes_seen) was owned as root.
> 
>   Anyone have any ideas what could cause this?

Running spamd as 'root' instead of 'mail', most likely.  When it writes the
files they will be owned by the current user.  If they are owned by root
then the current user at that moment was the root user.
Since the superuser has permissions to take over any file but the reverse is
not allowed this is a one-way street.  That is, a mistake can latch into
this mode and running as the 'mail' user can't fix it.

>   We do run a script that runs as root that calls sa-learn 
> occasionally.  Could that interaction somehow cause the file ownership 
> to be changed?  If so, any recommendations for the proper locking 
> between spamd and sa-learn?

That is probably your problem.  Run that script as the 'mail' user.
The root user can do this easily enough.

  su mail -c "sa-learn --options-here"

Bob



Bayes databases losing file ownership

2004-12-02 Thread Chris Blaise

spamd runs as mail and that's what the bayes_ files are owned as.  A
few days ago we started seeing an increase in spam and looking into the
problem today, I found that the bayes_toks file (but not bayes_seen) was
owned as root.

Anyone have any ideas what could cause this?

We do run a script that runs as root that calls sa-learn
occasionally.  Could that interaction somehow cause the file ownership to be
changed?  If so, any recommendations for the proper locking between spamd
and sa-learn?

 Thanks,
 Chris



RE: any performance benefit to SA 3.0?

2004-09-14 Thread Chris Blaise

The biggest performance benefit you'll see is if you use spamd.  The
pre-forking of children makes an incredible amount of difference.  

We ran tests with networking and bayes disabled and the improvement
was over 2x.

 Chris 

-Original Message-
From: scohen [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 14, 2004 7:37 AM
To: users@spamassassin.apache.org
Subject: any performance benefit to SA 3.0?

I've read through the benefits to SA 3.0 but I don't see any mention of
performance. I was wondering:

A) Does SA 3.0 use less memory/CPU then SA 2.64?
B) Does SA 3.0 take less time to decide if an email is spam then SA 2.64?
C) Does SA 3.0 do a better job of identifying spam with its default
configuration then  SA 2.64?

Thank you for your time.

Steve Cohen




RE: Bayes scoring weirdness?

2004-09-07 Thread Chris Blaise

Ok, I see how it's happening.  

Now, 'why'?  Can you point me to some documentation that explains
why it's desirable to ignore certain types of tests?  Maybe I'm being thick,
but I'm not finding it in the Wiki or docs.

 Thanks,
 Chris 

-Original Message-
From: Theo Van Dinter [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 07, 2004 2:41 PM
To: Chris Blaise
Cc: users@spamassassin.apache.org
Subject: Re: Bayes scoring weirdness?

On Tue, Sep 07, 2004 at 02:32:42PM -0600, Chris Blaise wrote:
>   The rules were ALL_TRUSTED,MISSING_DATE,USER_IN_BLACKLIST and I
think 
> since "ALL_TRUSTED" is a negative value.
> 
>   Am I missing something about how auto-learn should consider this?  
> 
>   Is there a reason why it doesn't consider such a message as spam, 
> soley on the score?  I realize that it won't learn spam if the header 
> and body aren't at least 3 each, but for such a high score, it seems 
> like it should be able to disregard that to say, "This is huge; learn it
as spam."

This has been convered many times.  It's probably in the wiki, and
definitely in the documentation:

[...]
   bayes_auto_learn ( 0 | 1 )  (default: 1)
[...]
   Note that certain tests are ignored when determining whether a
mes-
   sage should be trained upon:

- rules with tflags set to 'learn' (the Bayesian rules)

- rules with tflags set to 'userconf' (user white/black-listing
  rules, etc)

- rules with tflags set to 'noautolearn'

   Also note that auto-training occurs using scores from either
score-
   set 0 or 1, depending on what scoreset is used during message
   check.  It is likely that the message check and auto-train scores
   will be different.


As always though, run with -D and you'll find out plenty. ;)

--
Randomly Generated Tagline:
"It used to be said [...] that AIX looks like one space alien discovered
Unix, and described it to another different space alien, who then
implemented AIX. But their universal translators were broken and they'd  had
to gesture a lot." - Paul Tomblin



Bayes scoring weirdness?

2004-09-07 Thread Chris Blaise

In experimenting with white/blacklists and bayes, I got a message
that was in a blacklist but learned as ham!

2004 Sep  7 14:22:02 server spamd[8949]: identified spam (197.2/5.0) for
nobody:8 in 0.6 seconds, 191 bytes.
2004 Sep  7 14:22:02 server spamd[8949]: logmsg: result: Y 197 -
ALL_TRUSTED,MISSING_DATE,USER_IN_BLACKLIST
scantime=0.6,size=191,mid=(unknown),autolearn=ham
2004 Sep  7 14:22:02 server spamd[8949]: result: Y 197 -
ALL_TRUSTED,MISSING_DATE,USER_IN_BLACKLIST
scantime=0.6,size=191,mid=(unknown),autolearn=ham

The rules were ALL_TRUSTED,MISSING_DATE,USER_IN_BLACKLIST and I
think since "ALL_TRUSTED" is a negative value.

Am I missing something about how auto-learn should consider this?  

Is there a reason why it doesn't consider such a message as spam,
soley on the score?  I realize that it won't learn spam if the header and
body aren't at least 3 each, but for such a high score, it seems like it
should be able to disregard that to say, "This is huge; learn it as spam."

 Thanks,
 Chris



RE: SpamAssassin 3.0.0-rc3 RELEASE CANDIDATE available!

2004-09-07 Thread Chris Blaise

Another reason for SPF/SenderID vs. PTR records is unfortunately
while technically possible to delegate, many ISPs don't allow their
customers to manage the reverse records. 

 Chris