On May 22, 2003 10:56 am, Josh Trutwin wrote:

Is spamd even running? (ps -defa | grep spam)

Anything spam related in /var/log/mail?

Yup it's running. It seems I can get it to check the message but then it deletes the email and just sends on the resulting score. Logs show it checking the messages. I'm clearly missing an option someplace. Nick

On May 22, 2003 12:08 pm, Bruce Marshall wrote:

On Thursday 22 May 2003 11:56 am, Nick Zentena wrote:

...

On May 22, 2003 10:56 am, Josh Trutwin wrote:

...

Is spamd even running? (ps -defa | grep spam)

Anything spam related in /var/log/mail?

Yup it's running. It seems I can get it to check the message but then it deletes the email and just sends on the resulting score. Logs show it checking the messages. I'm clearly missing an option someplace.

Nick

How are you calling spamc?

Yes and it seems to check the message fine. It just eats the message-)) Nick

On Thu, May 22, 2003 at 11:56:42AM -0400, Nick Zentena wrote:

On May 22, 2003 10:56 am, Josh Trutwin wrote:

...

Is spamd even running? (ps -defa | grep spam)

Anything spam related in /var/log/mail?

Yup it's running. It seems I can get it to check the message but then it deletes the email and just sends on the resulting score. Logs show it checking the messages. I'm clearly missing an option someplace.

From your description, it looks a bit like spamc is getting either the -c or the -R option. At least that's the impression I get from:

http://spamassassin.org/doc/spamc.html Im about to try the same transition myself, so I'm very interested in this issue. Which versions of ...well everything... are involved? HTH Jon Clausen -- If we can't be free, at least we can be cheap!

On May 22, 2003 12:41 pm, Bruce Marshall wrote:

Then I call spamc from procmail using: | spamc

No options in either case.

Yanked the options and now all is well-)) Thanks Nick

On Thursday 22 May 2003 19:11 pm, Carlos E. R. wrote:

The 03.05.22 at 12:41, Bruce Marshall wrote:

...

It should be a no brainer.

I start /usr/bin/spamd from /etc/init.d/boot.local without any

Just enable service rcspamd in Yast, or use insserv. No need to touch boot.local, Suse already prepared the script.

-- Cheers, Carlos Robinson

Oh, of course. Unless one is using the CVS version of Spamassassin. (in which case, you can have webmin set up the runlevel for you) -- +----------------------------------------------------------------------------+ + Bruce S. Marshall bmarsh@bmarsh.com Bellaire, MI 05/23/03 13:53 + +----------------------------------------------------------------------------+ "In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." Edward P. Tryon

Bruce Marshall writes:

Oh, of course. Unless one is using the CVS version of Spamassassin.

The SuSE rcspamd script works fine with the CVS version of spamassassin.

The 03.05.23 at 13:54, Bruce Marshall wrote:

...

Just enable service rcspamd in Yast, or use insserv. No need to touch boot.local, Suse already prepared the script.

Oh, of course. Unless one is using the CVS version of Spamassassin.

Not even then :-) You can still use the "/etc/init.d/spamd" script that came with the SuSE rpm; just edit the line SPAMD_BIN=/usr/bin/spamd (the original uses "sbin"). Or, use the script provided by the developpers in "Mail-SpamAssassin-2.53/spamd/suse-rc-script.sh" with instructions. All thought of by somebody :-) -- Cheers, Carlos Robinson

The 03.05.24 at 10:40, Bruce Marshall wrote:

Ok, Ok.... 5 different people have mentioned 5 different ways to do it.

I DID NOT install spamassassin off the DVD because there WAS NO NEED TO.

The version I have is from sources - not cvs, but sources anyway - and the required script is provided by them (the developpers), as I mentioned :-) -- Cheers, Carlos Robinson

On Saturday 24 May 2003 7:09 am, Jon Clausen wrote:

On Fri, May 23, 2003 at 01:11:25AM +0200, Carlos E. R. wrote:

...

The 03.05.22 at 12:41, Bruce Marshall wrote:

...

It should be a no brainer.

I start /usr/bin/spamd from /etc/init.d/boot.local without any

Just enable service rcspamd in Yast, or use insserv. No need to touch boot.local, Suse already prepared the script.

Which works *very* well indeed:

I enabled spamd through YaST yesterday, and changed the procmail line from

| spamassassin -a

to

| spamc

-and I haven't even *received* any spam since!!! ;)

Seriously, at first I thought spamd/spamc made the spam vanish from the system, which would be somewhat undesirable. But I have a backup recipe at the top of the procmailrc, that puts all mail unprocessed in a separate location. No trace of spam there either.

If your backup recipe is at the top of the procmailrc, then ALL of your incoming email should be in that backup.... untouched by spamassassin. The best way to find out whether spamassassin is working is to 1) look in the log file for procmail and see how emails are getting processed, or 2) look in your /var/log/mail file and see messages from spamd.

Which means that I don't *actually* know if spamd/spamc works, because there hasn't been anything for it to catch... A highly unusual situation... may it last forever :)

cheers, Jon Clausen

-- If we can't be free, at least we can be cheap!

-- +----------------------------------------------------------------------------+ + Bruce S. Marshall bmarsh@bmarsh.com Bellaire, MI 05/24/03 10:53 + +----------------------------------------------------------------------------+ "I've gone into hundreds of (fortune tellers' parlors), and have been told thousands of things, but nobody ever told me I was a policewoman getting ready to arrest her." - N. Y. C. detective

The 03.05.24 at 18:03, Jon Clausen wrote:

Thanks. I didn't realize that spamd would be writing to the mail log. I'm now looking at tons of "clean message" messages... so I guess it's working o.k.

I forgot to mention: there is a "sample-nonspam.txt" and a "sample-spam.txt" included with the sources for testing purposes. -- Cheers, Carlos Robinson

On Sat, May 24, 2003 at 08:15:01PM +0200, Carlos E. R. wrote:

...

-and I haven't even *received* any spam since!!! ;)

Good! :-)

It was nice while it lasted... but they're back at it now :P

But you know that simply calling spamc is not enough: that only pass all mail though the filter, adding appropiate headers and such. Then, you need your email client filters, or procmail itself (probably faster) to do the job.

Speed was the main factor in my wanting to use the daemon/client rather than spamassassin.

The rule I have in .procmailrc is:

I put it in /etc/procmailrc instead. Just in case I ever get any users (other than myself) on that server.

:0fw | /usr/bin/spamc

Hmmm... I'd better go change that line, so it's got the full path instead of relying on $PATH...

Some people send it to dev/null directly, but I don't trust it so much. I have some legitimate emails marked as spam now and then...

Indeed. I get the impression that SA 2.5 is smarter than 2.3, but in any case I like it that it now puts the report in the body of the mail, rather than keeping it in the headers.

...

Which means that I don't *actually* know if spamd/spamc works, because there hasn't been anything for it to catch... A highly unusual situation... may it last forever :)

This was kind of a joke.

Turn "full headers on" on your email viewer, and you will notice the line(s) added by SpamAssassin. Your's has:

<snip> Yeah, did that right away.

I'll have to read the docs carefully, I saw something about sending spam that passes the filter somewhere so that it is detected next time. I wonder if that address is local or remote :-?

You mean sa-learn ? AFAICT one needs a fairly large library of spam/ham before sa-learn has much to add... (?) Cheers, Jon Clausen -- If we can't be free, at least we can be cheap!

On Wednesday 28 May 2003 8:00 am, Carlos E. R. wrote:

The 03.05.25 at 15:22, Jon Clausen wrote:

...

...

...

-and I haven't even *received* any spam since!!! ;)

Good! :-)

It was nice while it lasted... but they're back at it now :P

:-(

Almost all the spam I get goes to this address... I wish I could fake it.

...

Speed was the main factor in my wanting to use the daemon/client rather than spamassassin.

...

The rule I have in .procmailrc is:

I put it in /etc/procmailrc instead. Just in case I ever get any users (other than myself) on that server.

It doesn't work for me: "/etc/procmailrc" is not even read, it is ignored, ever since I changed to postfix. Procmail is executed by user "nobody", so that it can not read that file, nor "/root/.procmailrc"

Strange... I run 'getmail' as user nobody and hand the mail off to procmail which uses my /etc/procmailrc and does all the rest. You must have a permission issue somewhere.

...

...

:0fw : | /usr/bin/spamc

Hmmm... I'd better go change that line, so it's got the full path instead of relying on $PATH...

I think it will run faster as well :-?

It should... much faster/

...

...

Some people send it to dev/null directly, but I don't trust it so much. I have some legitimate emails marked as spam now and then...

I have a procmail recipe that sends anything at a level of 10 or above to /dev/null. Anything 5 or above then goes to a 'spam' mailbox. Anything below 5 is delivered normally. This takes care of the occasional 'non-spam' emails that might be received. :0fw | spamc :0e { EXITCODE=$? } :0 * ^X-Spam-Status:.*hits=[1-9][0-9] # Count the spams that got tossed. { :0 c | /usr/local/bin/cntspam :0 /dev/null } :0:hispam.lock * ^X-Spam-Status:.*hits=[5-9][\ \.] /var/spool/mail/highspam

...

Indeed. I get the impression that SA 2.5 is smarter than 2.3, but in any case I like it that it now puts the report in the body of the mail, rather than keeping it in the headers.

I'm not sure I like it better... maybe when I get used to it :-)

It is smarter, true. But I prefer to play safe.

...

...

I'll have to read the docs carefully, I saw something about sending spam that passes the filter somewhere so that it is detected next time. I wonder if that address is local or remote :-?

You mean sa-learn ?

AFAICT one needs a fairly large library of spam/ham before sa-learn has much to add... (?)

No, not that, or maybe yes :-? I don't really know. I mean just someway to tell it that that email it passed as "good" was really "bad". Also, I'd like a way of automatically add the senders addresses used for spam to a local database so that next time they are rejected before download - like one I got the other day claiming to be from M$ support, and containing a 70Kb executable, obviously malign :-} I wonder if somebody falls to that trick?

-- Cheers, Carlos Robinson

-- +----------------------------------------------------------------------------+ + Bruce S. Marshall bmarsh@bmarsh.com Bellaire, MI 05/28/03 12:23 + +----------------------------------------------------------------------------+ "It is far better to be deceived than to be undeceived by those we love."

* Carlos E. R. [05-28-03 14:31]:

The 03.05.28 at 12:28, Bruce Marshall wrote:

...

...

It doesn't work for me: "/etc/procmailrc" is not even read, it is ignored, ever since I changed to postfix. Procmail is executed by user "nobody", so that it can not read that file, nor "/root/.procmailrc"

Strange... I run 'getmail' as user nobody and hand the mail off to procmail which uses my /etc/procmailrc and does all the rest. You must have a permission issue somewhere.

No... even if I set /etc/procmailrc to be world readable, it doesn't work. It works with sendmail, but the same file doesn't work with postfix.

The problem is that postfix calls procmail as user "nobody", whereas sendmail called it as "root". This is documented on the postfix faq, so I don't understand how it works for other people. Maybe some recipes work there, and someother don't (like saving on a particular mail box).

man procmail use ~/.procmailrc man procmail, procmailrc procmailex, procmailsc Procmail Quick Start: http://www.ii.com/internet/robots/procmail/qs/ -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience

* Carlos E. R. [05-28-03 19:07]:

The 03.05.28 at 15:33, Patrick Shanahan wrote:

...

use ~/.procmailrc

So? I read that dozens of times, have been using procmail for years. But I think you have not read carefully my question...

Why are not "/etc/procmailrc" and "/root/.procmailrc" read if I use sendmail, and the same file works as a charm using sendmail? That is no explained in "man procmail".

IANE, but according to 'man procmail': If no rcfiles and no -p have been specified on the command line, procmail will, prior to reading $HOME/.procmailrc, interpret commands from /etc/procmailrc (if present). Care must be taken when creating /etc/procmailrc because, if circumstances permit, it will be executed with root privileges (contrary to the $HOME/.procmailrc file of course). AIUI, /etc/procmailrc would only be used on multi-user systems prior to utilization of ~/.procmailrc and there *should* be *no use* for /root/.procmailrc as *all* root mail must be aliased to another user to be delivered by procmail. ie, /root/.procmailrc will *never* be read. On a single user system you should use $HOME/.procmailrc, and if using sendmail (I use postfix) instead of postfix, per 'man procmail': Procmail should be invoked automatically over the .forward file mechanism as soon as mail arrives. Alternatively, when installed by a system administrator, it can be invoked from within the mailer immediately. This discussion would be better suited for: There exists a mailinglist for questions relating to any program in the procmail package: for submitting questions/answers. for subscription requests. -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience

* Carlos E. R. [05-29-03 06:35]:

The 03.05.28 at 20:47, Patrick Shanahan wrote:

...

...

Why are not "/etc/procmailrc" and "/root/.procmailrc" read if I use sendmail,

typpo: postfix.

...

...

and the same file works as a charm using sendmail? That is no explained in "man procmail".

IANE, but according to 'man procmail':

...

If no rcfiles and no -p have been specified on the command line, procmail will, prior to reading $HOME/.procmailrc, interpret commands from /etc/procmailrc (if present). Care must be taken when creating /etc/procmailrc because, if circumstances permit, it will be executed with root privileges (contrary to the $HOME/.procmailrc file of course).

Mind: you yourself said "root privileges".

Now notice the postfix documentation:

| If you use procmail (or some other command) for local mail | delivery, Postfix will not deliver mail as root. Instead, Postfix | runs procmail (or whatever) as nobody. Perhaps some day Wietse | will trust Postfix enough to run external commands as root.

So, using postfix, procmail is NOT called with root privileges, so it can not read /etc/procmailrc as stated on the procmail man page.

End of argument. :-)

This is what I have been saying all along... please, read carefully what I said before replying.

Agreed, there is *no* argument and I have read correctly what you have conveyed. Notice your comment "typpo: postifx". Root mail must be aliased to be delivered via postfix -> procmail. -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience

The 03.05.29 at 09:46, Bruce Marshall wrote:

...

So, using postfix, procmail is NOT called with root privileges, so it can not read /etc/procmailrc as stated on the procmail man page.

Can you describe how you receive your email? fetchmail, getmail, other? and who is calling postfix?

Fetchmail sends mail to port 25, and postfix sends it (pipes) for local delivery to procmail. The postfix configuration is as set up by YAST2 on a clean 8.1 install (commented by me on another mail, thread "a way to get more verbose logging from the postfix procmail maildrop ?", dated: Wed, 28 May 2003). With exactly the same recipe files (procmailrc) I had under suse 7.3 and sendmail, procmail stopped working right away under 8.2 and postfix. The problem was that it could not read "/etc/procmailrc" as user nobody.

There are ways to get procmail to process incoming mail without using postfix... but I believe that even using fetchmail --> postfix --> procmail it is still possible to use /etc/procmailrc.

Not according to postfix own documentation... The only way I can think is to change these two lines in "/etc/postfix/master.cf": procmail unix - n n - - pipe flags=R user=nobody argv=/usr/bin/procmail -t -m /etc/procmailrc ${sender} ${recipient} ________________^^^^^^^ To: procmail unix - n n - - pipe flags=R user=root argv=/usr/bin/procmail -t -m /etc/procmailrc ${sender} ${sender} ${recipient} _______________^^^^ But I will not try it.

I've used about every combination possible of the above and I have *never* used anything other than /etc/procmailrc.

It is dangerous, that file is processed as root (according to procmail docs). My recipes there were few, and now are completely removed. -- Cheers, Carlos Robinson

* Bruce Marshall [05-29-03 14:39]:

On Thursday 29 May 2003 14:48 pm, Carlos E. R. wrote:

...

Fetchmail sends mail to port 25, and postfix sends it (pipes) for local delivery to procmail. The postfix configuration is as set up by YAST2 on a clean 8.1 install (commented by me on another mail, thread "a way to get more verbose logging from the postfix procmail maildrop ?", dated: Wed, 28 May 2003). With exactly the same recipe files (procmailrc) I had under suse 7.3 and sendmail, procmail stopped working right away under 8.2 and postfix. The problem was that it could not read "/etc/procmailrc" as user nobody.

I'll try this by tommorrow. I used to run fetchmail, started by root and I believe it then used postfix and then postfix called procmail and used my /etc/procmailrc.

*Do* *not* call fetchmail as root. Call fetchmail as $USER. Assign the 'mda, procmail' in ~/.fetchmailrc.

But I later bypassed postfix (why not?) and had fetchmail hand off directly to procmail and still used the /etc/procmailrc. Is this not a possibility? I still started fetchmail from root.

No need to involve postfix, just overhead. BUT, do not call fetchmail from root and use local files (~/.procmailrc, ~/.fetchmailrc) to manipulate your mail. Root is the administrator and expecially for security reasons should/must be kept out of the normal day to day operations. This particular subject is hammered onto every individual who mentions the root use and/or use of /etc/procmailrc in the procmail mail-list. -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience

* Bruce Marshall [05-29-03 15:09]:

On Thursday 29 May 2003 15:55 pm, Patrick Shanahan wrote:

[snip ...]

...

*Do* *not* call fetchmail as root. Call fetchmail as $USER. Assign the 'mda, procmail' in ~/.fetchmailrc.

I'll call it however I want to... thanks.

...

...

But I later bypassed postfix (why not?) and had fetchmail hand off directly to procmail and still used the /etc/procmailrc. Is this not a possibility? I still started fetchmail from root.

No need to involve postfix, just overhead.

True.... but we're trying to solve a problem here. Read up on it.

...

BUT, do not call fetchmail from root and use local files (~/.procmailrc, ~/.fetchmailrc) to manipulate your mail. Root is the administrator and expecially for security reasons should/must be kept out of the normal day to day operations.

You run it the way you want to.... and butt out please.

...

This particular subject is hammered onto every individual who mentions the root use and/or use of /etc/procmailrc in the procmail mail-list.

Yeh, and I'm a big boy and can take care of myself.

Thanks for your help.

You're welcome. Your courtesy and way with words are only exceeded by your good looks. One bright day in the middle of the night -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience

On 05/30/2003 02:48 AM, Carlos E. R. wrote:

Fetchmail sends mail to port 25, and postfix sends it (pipes) for local delivery to procmail. The postfix configuration is as set up by YAST2 on a clean 8.1 install (commented by me on another mail, thread "a way to get more verbose logging from the postfix procmail maildrop ?", dated: Wed, 28 May 2003). With exactly the same recipe files (procmailrc) I had under suse 7.3 and sendmail, procmail stopped working right away under 8.2 and postfix. The problem was that it could not read "/etc/procmailrc" as user nobody.

I used Yast to set procmail as the postfix MDA, and to start spamd, and used the example procmailrc file for spamassassin, and it virus scans the mail I have being fetched with fetchmail as well as checks for spam. /etc/procmail is root.root 644, works like a charm. I don't know why yours didn't work. I only used Yast. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Web Address: http://www.mydestiny.net/~joe_morris Registered Linux user 231871 God said, I AM that I AM. I say, by the grace of God, I am what I am.

On Fri, 30 May 2003, Joe Morris (NTM) wrote:

I used Yast to set procmail as the postfix MDA, and to start spamd, and used the example procmailrc file for spamassassin, and it virus scans the mail I have being fetched with fetchmail as well as checks for spam. /etc/procmail is root.root 644, works like a charm. I don't know why yours didn't work. I only used Yast.

Joe - do any of your users have a .procmailrc ? If they do I would be very interested as that is exaclty the same setup that broke for me last week. David.

On Wed, May 28, 2003 at 11:16:32PM +0200, Carlos E. R. Wrote:

The 03.05.28 at 15:33, Patrick Shanahan wrote:

...

...

The problem is that postfix calls procmail as user "nobody", whereas sendmail called it as "root". This is documented on the postfix faq, so I don't understand how it works for other people. Maybe some recipes work there, and someother don't (like saving on a particular mail box).

man procmail

use ~/.procmailrc

So? I read that dozens of times, have been using procmail for years. But I think you have not read carefully my question...

Why are not "/etc/procmailrc" and "/root/.procmailrc" read if I use sendmail, and the same file works as a charm using sendmail? That is no explained in "man procmail".

-- Cheers, Carlos Robinson

-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

Possibly check your master.cf file, I user Cyrus Imap along with procmail: procmail unix - n n - - pipe flags=R user=cyrus argv=/usr/bin/procmail -t -m USER=${user} EXT=${extension } /etc/procmailrc -- _ _ __ _____ _____ ___| |_ | '__| / __\ \ /\ / / _ \/ _ \ __| -o) | | _ \__ \\ V V / __/ __/ |_ /\\ |_|(_) |___/ \_/\_/ \___|\___|\__|_\_v rsweet@garagenetworks.net "there's no love in fear."