Re: SA logging options wrong uid Debian-exim sa-stats
On Monday 21 August 2006 22:21, Stefan Bauer took the opportunity to say: > iam using Debian with Spamassasin 3.1.1-1 and exim 4.62. > > Iam looking forward to use sa-stats[1] with the stats from spamassasin > from /var/log/exim4/mainlog.log like: > > Aug 21 17:58:51 main spamd[4064]: spamd: result: . -1 - AWL,BAYES_00 > scantime=2.3,size=5146,user=Debian-exim,uid=104,required_score=3.0,rhost=lo >calhost. > localdomain,raddr=127.0.0.1,rport=49475,mid=<[EMAIL PROTECTED] >.de>,rmid= > <[EMAIL PROTECTED]>,bayes=1.11668452262847e-11,autolearn=no > > this works but not very well. Spamassasin logs to the file above but > the user=Debian-exim part is always Debian-exim. How can i setup > Spamamsassin to log the files or deliver the files under the uid of > the user who received the mails? This is an Exim question, which you should ask exim-users@exim.org or [EMAIL PROTECTED] about. > Running sa-stats only let me get stats[2] for the user Debian-exim > which lists all mails. > > So my question is how can i negotiate SA to deliver the mails under > the UID of the users to get usable logs? It depends on how you call SpamAssassin from Exim, which in turn partly depends on whether you want personal user preferences or not. With sa-exim you can't. With the exiscan ACL condition (spam = ) you can, but you have to make special arrangements to unambiguously decide which user to scan for if there are many recipients. If you call SA late in the delivery process, for instance as a transport filter, once for each recipient, then it's easy. So please come to the Exim mailing lists and describe your setup in more detail. > [1] http://david.hexstream.co.uk/scripts/sa-stats/sa-stats.pl.html > [2] http://www.plzk.de/stats/spam -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp6G55dVZIMj.pgp Description: PGP signature
Re: SA logging with amavis
On Apr 21, 2006, at 12:50 PM, Michael Monnerie wrote: The other idea I have is to disable SA support in amavis, and just use it for the virus checks, and call SA directly. I'm not sure this would why not teach your log analyzer to understand amavisd-new's log format, too?
Re: SA logging with amavis
On 4/21/06, Michael Monnerie <[EMAIL PROTECTED]> wrote: > You don't get a spamd log when SA is called via amavis. That's not good > if you want stats. So what could we do to have that? > > SA is called directly via Mail::SpamAssassin from amavis. Is it possible > to configure that to log like spamd? > > The other idea I have is to disable SA support in amavis, and just use > it for the virus checks, and call SA directly. I'm not sure this would > be good, because amavis is working very robust and I'm happy with it > (except for this logging issue). > > Any other way? Maybe something with SQL? I love stats, and that's how > you can fine tune your system - so I'd like to have all the info I can > get. > There are several log analyzers built to work with amavisd-new logging. Maybe one will work for you. http://www.ijs.si/software/amavisd/#contrib also, amavisd-new logging is somewhat configurable. Maybe you can convince it to do what you want directly. Check the amavis-users list and archives for help. Changing your configuration to use spamd separately from amavisd-new is certainly an option. Weigh the advantages of each method and decide which best suits your needs. -- Noel Jones
Re: SA logging
Thanks guys, problem was i commented out the old stuff: #:0fw #| /usr/bin/spamassasin #:0 when i needed to leave the second :0 uncommentedd'oh! thanks again > From: Morris Jones <[EMAIL PROTECTED]> > Date: Fri, 8 Oct 2004 13:19:01 -0700 (PDT) > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Cc: Matt Kettler <[EMAIL PROTECTED]>, > Subject: Re: SA logging > > You have two separate things happening in two recipes: > > The first recipe: > >> :0fw >> | /usr/bin/spamassassin > > Adds the X-SpamStatus: header to the email. The second recipe: > >> :0 >> * ^X-Spam-Status: Yes >> $HOME/spam > > Delivers email with the specified header to $HOME/spam. > > The problem I was addressing was in the first recipe. Instead of > what you have, it should be: > > :0fw > * < 256000 > | /usr/bin/spamc > > Note that there are two differences between my version and yours: > > 1. The line "* < 256000" only feeds email under 256,000 bytes to > Spamassassin. > 2. The third line, using /usr/bin/spamc instead of > /usr/bin/spamassassin, makes use of the spamd daemon instead > of individual instances of spamassassin. > > I only gave you the change required for the first recipe. You still > have to deliver the spam to the right place, which means that the > full procmailrc entry needs to be: > > --- cut here -- > # Pass the message through the spamassassin daemon and mark up > # for spam status > > :0fw > * < 256000 > | /usr/bin/spamc > > # Deliver spam marked email into user's spam folder > > :0 > * ^X-Spam-Status: Yes > $HOME/spam > > --- cut here -- > > The additional blank lines and comments add some clarity. > > Best regards, > Mojo > > On Fri, 8 Oct 2004, [EMAIL PROTECTED] wrote: > >> Thank you, appeared to work great, logging to maillog and all, the problem >> now becomes where it's putting spam. >> >> previously my procmailrc looked like this: >> >> :0fw >> | /usr/bin/spamassassin >> :0 >> * ^X-Spam-Status: Yes >> $HOME/spam >> >> which routed spam to the users spam folder >> >> when i change it to: >> :0fw >> * < 256000 >> | /usr/bin/spamc >> >> it doesnt do that anymore. Is there a way to route it back to the >> /user/spam? >> >> >> >>> From: Morris Jones <[EMAIL PROTECTED]> >>> Date: Fri, 8 Oct 2004 12:25:15 -0700 (PDT) >>> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> >>> Cc: Matt Kettler <[EMAIL PROTECTED]>, >>> Subject: Re: SA logging >>> >>> His information is all correct. >>> >>> Change your procmailrc lines so they're something like this: >>> >>> # Pass through spamassassin >>> :0fw >>> * < 256000 >>> | /usr/bin/spamc >>> >>> Mojo >>> >>> On Fri, 8 Oct 2004, [EMAIL PROTECTED] wrote: >>> >>>> Thank you Matt! >>>> >>>> You're info is great, but I'm sure you dont mind if I take your disclaimer >>>> seriously. >>>> >>>> Before I go on, anyone that uses spamd confirm this info...? >>>> >>>> >>>>> From: Matt Kettler <[EMAIL PROTECTED]> >>>>> Date: Fri, 08 Oct 2004 13:48:40 -0400 >>>>> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, >>>>> >>>>> Subject: Re: SA logging >>>>> >>>>> At 01:16 PM 10/8/2004, [EMAIL PROTECTED] wrote: >>>>>> Yea, ive been asked this before. I inherited this setup, so Im trying to >>>>>> work that out. >>>>>> >>>>>> i can restart SA by using rc.d/init.d/spamassassin >>>>>> >>>>>> it shows in ps aux as /usr/bin/spamd -d -c -a >>>>>> >>>>>> and when mail comes in it shows as >>>>>> /usr/bin/perl -T -w /usr/bin/spamassassin >>>>>> >>>>>> >>>>>> is that helpful? >>>>> >>>>> Yes, I dug back in your old emails. You're calling spamassassin (plain) >>>>> from procmail. Although you are starting spamd, you're not using spamc, so >>>>> that's a complete waste at the moment. >>>>> >>>>> Suggestion: >>>>>
Re: SA logging
[EMAIL PROTECTED] wrote: Thank you, appeared to work great, logging to maillog and all, the problem now becomes where it's putting spam. previously my procmailrc looked like this: :0fw | /usr/bin/spamassassin :0 * ^X-Spam-Status: Yes $HOME/spam which routed spam to the users spam folder when i change it to: :0fw * < 256000 | /usr/bin/spamc it doesnt do that anymore. Is there a way to route it back to the /user/spam? I never used procmail but i would assume you should have left everything the same except change /usr/bin/spamassassin to /usr/bin/spamc -Jim
Re: SA logging
You have two separate things happening in two recipes: The first recipe: > :0fw > | /usr/bin/spamassassin Adds the X-SpamStatus: header to the email. The second recipe: > :0 > * ^X-Spam-Status: Yes > $HOME/spam Delivers email with the specified header to $HOME/spam. The problem I was addressing was in the first recipe. Instead of what you have, it should be: :0fw * < 256000 | /usr/bin/spamc Note that there are two differences between my version and yours: 1. The line "* < 256000" only feeds email under 256,000 bytes to Spamassassin. 2. The third line, using /usr/bin/spamc instead of /usr/bin/spamassassin, makes use of the spamd daemon instead of individual instances of spamassassin. I only gave you the change required for the first recipe. You still have to deliver the spam to the right place, which means that the full procmailrc entry needs to be: --- cut here -- # Pass the message through the spamassassin daemon and mark up # for spam status :0fw * < 256000 | /usr/bin/spamc # Deliver spam marked email into user's spam folder :0 * ^X-Spam-Status: Yes $HOME/spam --- cut here -- The additional blank lines and comments add some clarity. Best regards, Mojo On Fri, 8 Oct 2004, [EMAIL PROTECTED] wrote: > Thank you, appeared to work great, logging to maillog and all, the problem > now becomes where it's putting spam. > > previously my procmailrc looked like this: > > :0fw > | /usr/bin/spamassassin > :0 > * ^X-Spam-Status: Yes > $HOME/spam > > which routed spam to the users spam folder > > when i change it to: > :0fw > * < 256000 > | /usr/bin/spamc > > it doesnt do that anymore. Is there a way to route it back to the > /user/spam? > > > > > From: Morris Jones <[EMAIL PROTECTED]> > > Date: Fri, 8 Oct 2004 12:25:15 -0700 (PDT) > > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > Cc: Matt Kettler <[EMAIL PROTECTED]>, > > Subject: Re: SA logging > > > > His information is all correct. > > > > Change your procmailrc lines so they're something like this: > > > > # Pass through spamassassin > > :0fw > > * < 256000 > > | /usr/bin/spamc > > > > Mojo > > > > On Fri, 8 Oct 2004, [EMAIL PROTECTED] wrote: > > > >> Thank you Matt! > >> > >> You're info is great, but I'm sure you dont mind if I take your disclaimer > >> seriously. > >> > >> Before I go on, anyone that uses spamd confirm this info...? > >> > >> > >>> From: Matt Kettler <[EMAIL PROTECTED]> > >>> Date: Fri, 08 Oct 2004 13:48:40 -0400 > >>> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, > >>> > >>> Subject: Re: SA logging > >>> > >>> At 01:16 PM 10/8/2004, [EMAIL PROTECTED] wrote: > >>>> Yea, ive been asked this before. I inherited this setup, so Im trying to > >>>> work that out. > >>>> > >>>> i can restart SA by using rc.d/init.d/spamassassin > >>>> > >>>> it shows in ps aux as /usr/bin/spamd -d -c -a > >>>> > >>>> and when mail comes in it shows as > >>>> /usr/bin/perl -T -w /usr/bin/spamassassin > >>>> > >>>> > >>>> is that helpful? > >>> > >>> Yes, I dug back in your old emails. You're calling spamassassin (plain) > >>> from procmail. Although you are starting spamd, you're not using spamc, so > >>> that's a complete waste at the moment. > >>> > >>> Suggestion: > >>> > >>> modify rc.d/init.d/spamassassin to add a -m parameter to spamd to limit > >>> the > >>> number of children it can spawn. Probably -m 5 to start, but you can > >>> estimate the correct value by looking at how big spamd is, and how much > >>> free ram you have using top or ps. Don't let spamd spawn more than will > >>> fit > >>> in free ram or it will end up choking your server to death. > >>> > >>> If your existing call to spamassassin in procmailrc doesn't use the -a > >>> parameter, remove the -a from spamd to match (-a enables the > >>> auto-whitelist > >>> score-averaging system in 2.6x) > >>> > >>> modify your procmailrc to use spamc instead of spamassassin. It's much > >>> faster, has lower CPU overhead, and you'll end up with logging in syslog > >>> as > >>> spamd processes them. > >>> > >>> Disclaimer: I don't actually use spamd so I'm no expert at it, I use > >>> MailScanner which calls the API directly. You might wish to solicit advice > >>> on the list about converting to using spamd. > >>> > >>> > >>> > >> > > > > -- > > Morris Jones <*> > > Monrovia, CA > > [EMAIL PROTECTED] > > http://www.whiteoaks.com > > > -- Morris Jones <*> Monrovia, CA [EMAIL PROTECTED] http://www.whiteoaks.com
Re: SA logging
Thank you, appeared to work great, logging to maillog and all, the problem now becomes where it's putting spam. previously my procmailrc looked like this: :0fw | /usr/bin/spamassassin :0 * ^X-Spam-Status: Yes $HOME/spam which routed spam to the users spam folder when i change it to: :0fw * < 256000 | /usr/bin/spamc it doesnt do that anymore. Is there a way to route it back to the /user/spam? > From: Morris Jones <[EMAIL PROTECTED]> > Date: Fri, 8 Oct 2004 12:25:15 -0700 (PDT) > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Cc: Matt Kettler <[EMAIL PROTECTED]>, > Subject: Re: SA logging > > His information is all correct. > > Change your procmailrc lines so they're something like this: > > # Pass through spamassassin > :0fw > * < 256000 > | /usr/bin/spamc > > Mojo > > On Fri, 8 Oct 2004, [EMAIL PROTECTED] wrote: > >> Thank you Matt! >> >> You're info is great, but I'm sure you dont mind if I take your disclaimer >> seriously. >> >> Before I go on, anyone that uses spamd confirm this info...? >> >> >>> From: Matt Kettler <[EMAIL PROTECTED]> >>> Date: Fri, 08 Oct 2004 13:48:40 -0400 >>> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, >>> >>> Subject: Re: SA logging >>> >>> At 01:16 PM 10/8/2004, [EMAIL PROTECTED] wrote: >>>> Yea, ive been asked this before. I inherited this setup, so Im trying to >>>> work that out. >>>> >>>> i can restart SA by using rc.d/init.d/spamassassin >>>> >>>> it shows in ps aux as /usr/bin/spamd -d -c -a >>>> >>>> and when mail comes in it shows as >>>> /usr/bin/perl -T -w /usr/bin/spamassassin >>>> >>>> >>>> is that helpful? >>> >>> Yes, I dug back in your old emails. You're calling spamassassin (plain) >>> from procmail. Although you are starting spamd, you're not using spamc, so >>> that's a complete waste at the moment. >>> >>> Suggestion: >>> >>> modify rc.d/init.d/spamassassin to add a -m parameter to spamd to limit the >>> number of children it can spawn. Probably -m 5 to start, but you can >>> estimate the correct value by looking at how big spamd is, and how much >>> free ram you have using top or ps. Don't let spamd spawn more than will fit >>> in free ram or it will end up choking your server to death. >>> >>> If your existing call to spamassassin in procmailrc doesn't use the -a >>> parameter, remove the -a from spamd to match (-a enables the auto-whitelist >>> score-averaging system in 2.6x) >>> >>> modify your procmailrc to use spamc instead of spamassassin. It's much >>> faster, has lower CPU overhead, and you'll end up with logging in syslog as >>> spamd processes them. >>> >>> Disclaimer: I don't actually use spamd so I'm no expert at it, I use >>> MailScanner which calls the API directly. You might wish to solicit advice >>> on the list about converting to using spamd. >>> >>> >>> >> > > -- > Morris Jones <*> > Monrovia, CA > [EMAIL PROTECTED] > http://www.whiteoaks.com >
RE: SA logging
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Thank you Matt! > > You're info is great, but I'm sure you dont mind if I take your > disclaimer seriously. > > Before I go on, anyone that uses spamd confirm this info...? His suggestions sound right on to me. For the most part all you need to do is start up spamd and replace /usr/bin/spamassassin with /usr/bin/spamc in your procmailrc. I don't use procmail myself, so I can't give you any further details there. > From: Matt Kettler <[EMAIL PROTECTED]> > > At 01:16 PM 10/8/2004, [EMAIL PROTECTED] wrote: > >> > >> i can restart SA by using rc.d/init.d/spamassassin > >> > >> it shows in ps aux as /usr/bin/spamd -d -c -a > >> > >> and when mail comes in it shows as > >> /usr/bin/perl -T -w /usr/bin/spamassassin > > > > Suggestion: > > > > modify rc.d/init.d/spamassassin to add a -m parameter to spamd to > > limit the number of children it can spawn. Probably -m 5 to > > start, but you can estimate the correct value by looking at how > > big spamd is, and how much free ram you have using top or ps. > > Don't let spamd spawn more than will fit in free ram or it will > > end up choking your server to death. Good idea. The older (2.x) versions of spamassassin did not limit the children. Version 3.0 now preforks a default of 5 children. So if you are running 2.65 or older, you may want to tweak this. On the other hand, I've been running it without limits for over a year now without any problems. If you've got plenty of memory, you probably don't have to worry about it. > > If your existing call to spamassassin in procmailrc doesn't use > > the -a parameter, remove the -a from spamd to match (-a enables > > the auto-whitelist score-averaging system in 2.6x) Just look up your current options in the man pages and configure the comparable options for spamc and spamd. You generally don't need many options unless you want to do something fancy. > > modify your procmailrc to use spamc instead of spamassassin. It's > > much faster, has lower CPU overhead, and you'll end up with > > logging in syslog as spamd processes them. Spamc/spamd works very well. It is significantly faster than calling spamassassin for each email. Bowie
Re: SA logging
His information is all correct. Change your procmailrc lines so they're something like this: # Pass through spamassassin :0fw * < 256000 | /usr/bin/spamc Mojo On Fri, 8 Oct 2004, [EMAIL PROTECTED] wrote: > Thank you Matt! > > You're info is great, but I'm sure you dont mind if I take your disclaimer > seriously. > > Before I go on, anyone that uses spamd confirm this info...? > > > > From: Matt Kettler <[EMAIL PROTECTED]> > > Date: Fri, 08 Oct 2004 13:48:40 -0400 > > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, > > Subject: Re: SA logging > > > > At 01:16 PM 10/8/2004, [EMAIL PROTECTED] wrote: > >> Yea, ive been asked this before. I inherited this setup, so Im trying to > >> work that out. > >> > >> i can restart SA by using rc.d/init.d/spamassassin > >> > >> it shows in ps aux as /usr/bin/spamd -d -c -a > >> > >> and when mail comes in it shows as > >> /usr/bin/perl -T -w /usr/bin/spamassassin > >> > >> > >> is that helpful? > > > > Yes, I dug back in your old emails. You're calling spamassassin (plain) > > from procmail. Although you are starting spamd, you're not using spamc, so > > that's a complete waste at the moment. > > > > Suggestion: > > > > modify rc.d/init.d/spamassassin to add a -m parameter to spamd to limit the > > number of children it can spawn. Probably -m 5 to start, but you can > > estimate the correct value by looking at how big spamd is, and how much > > free ram you have using top or ps. Don't let spamd spawn more than will fit > > in free ram or it will end up choking your server to death. > > > > If your existing call to spamassassin in procmailrc doesn't use the -a > > parameter, remove the -a from spamd to match (-a enables the auto-whitelist > > score-averaging system in 2.6x) > > > > modify your procmailrc to use spamc instead of spamassassin. It's much > > faster, has lower CPU overhead, and you'll end up with logging in syslog as > > spamd processes them. > > > > Disclaimer: I don't actually use spamd so I'm no expert at it, I use > > MailScanner which calls the API directly. You might wish to solicit advice > > on the list about converting to using spamd. > > > > > > > -- Morris Jones <*> Monrovia, CA [EMAIL PROTECTED] http://www.whiteoaks.com
Re: SA logging
Thank you Matt! You're info is great, but I'm sure you dont mind if I take your disclaimer seriously. Before I go on, anyone that uses spamd confirm this info...? > From: Matt Kettler <[EMAIL PROTECTED]> > Date: Fri, 08 Oct 2004 13:48:40 -0400 > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, > Subject: Re: SA logging > > At 01:16 PM 10/8/2004, [EMAIL PROTECTED] wrote: >> Yea, ive been asked this before. I inherited this setup, so Im trying to >> work that out. >> >> i can restart SA by using rc.d/init.d/spamassassin >> >> it shows in ps aux as /usr/bin/spamd -d -c -a >> >> and when mail comes in it shows as >> /usr/bin/perl -T -w /usr/bin/spamassassin >> >> >> is that helpful? > > Yes, I dug back in your old emails. You're calling spamassassin (plain) > from procmail. Although you are starting spamd, you're not using spamc, so > that's a complete waste at the moment. > > Suggestion: > > modify rc.d/init.d/spamassassin to add a -m parameter to spamd to limit the > number of children it can spawn. Probably -m 5 to start, but you can > estimate the correct value by looking at how big spamd is, and how much > free ram you have using top or ps. Don't let spamd spawn more than will fit > in free ram or it will end up choking your server to death. > > If your existing call to spamassassin in procmailrc doesn't use the -a > parameter, remove the -a from spamd to match (-a enables the auto-whitelist > score-averaging system in 2.6x) > > modify your procmailrc to use spamc instead of spamassassin. It's much > faster, has lower CPU overhead, and you'll end up with logging in syslog as > spamd processes them. > > Disclaimer: I don't actually use spamd so I'm no expert at it, I use > MailScanner which calls the API directly. You might wish to solicit advice > on the list about converting to using spamd. > > >
Re: SA logging
At 01:16 PM 10/8/2004, [EMAIL PROTECTED] wrote: Yea, ive been asked this before. I inherited this setup, so Im trying to work that out. i can restart SA by using rc.d/init.d/spamassassin it shows in ps aux as /usr/bin/spamd -d -c -a and when mail comes in it shows as /usr/bin/perl -T -w /usr/bin/spamassassin is that helpful? Yes, I dug back in your old emails. You're calling spamassassin (plain) from procmail. Although you are starting spamd, you're not using spamc, so that's a complete waste at the moment. Suggestion: modify rc.d/init.d/spamassassin to add a -m parameter to spamd to limit the number of children it can spawn. Probably -m 5 to start, but you can estimate the correct value by looking at how big spamd is, and how much free ram you have using top or ps. Don't let spamd spawn more than will fit in free ram or it will end up choking your server to death. If your existing call to spamassassin in procmailrc doesn't use the -a parameter, remove the -a from spamd to match (-a enables the auto-whitelist score-averaging system in 2.6x) modify your procmailrc to use spamc instead of spamassassin. It's much faster, has lower CPU overhead, and you'll end up with logging in syslog as spamd processes them. Disclaimer: I don't actually use spamd so I'm no expert at it, I use MailScanner which calls the API directly. You might wish to solicit advice on the list about converting to using spamd.
Re: SA logging
Yea, ive been asked this before. I inherited this setup, so Im trying to work that out. i can restart SA by using rc.d/init.d/spamassassin it shows in ps aux as /usr/bin/spamd -d -c -a and when mail comes in it shows as /usr/bin/perl -T -w /usr/bin/spamassassin is that helpful? > From: Matt Kettler <[EMAIL PROTECTED]> > Date: Fri, 08 Oct 2004 13:03:59 -0400 > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, > Subject: Re: SA logging > > At 12:55 PM 10/8/2004, [EMAIL PROTECTED] wrote: >> Im sure SA should be logging something to somewhere, probably maillog right? >> Well I dont have anything in the maillog from SA. Am I missing something? >> Anyone help me debug why it's not logging? > > How are you calling SA? > > If you're using spamc/spamd then spamd will generate syslog messages. > > If you're using a call to the plain spamassassin command line, it won't log. > > Most integration tools (mailscanner, amavis, etc) do their own logging. >
Re: SA logging
At 12:55 PM 10/8/2004, [EMAIL PROTECTED] wrote: Im sure SA should be logging something to somewhere, probably maillog right? Well I dont have anything in the maillog from SA. Am I missing something? Anyone help me debug why it's not logging? How are you calling SA? If you're using spamc/spamd then spamd will generate syslog messages. If you're using a call to the plain spamassassin command line, it won't log. Most integration tools (mailscanner, amavis, etc) do their own logging.
