Spamassassin is just slowly downing Kmail like you wouldn't believe. I got spamd started but it seems spamc doesn't scan stuff. The docs seem to imply just change the line in the filter section of Kmail from spamassassin to spamc. Well that doesn't seem to work. Any hints?
Thanks Nick
Spamassassin is just slowly downing Kmail like you wouldn't believe. I got spamd started but it seems spamc doesn't scan stuff. The docs seem to imply just change the line in the filter section of Kmail from spamassassin to spamc. Well that doesn't seem to work. Any hints?
Is spamd even running? (ps -defa | grep spam)
Anything spam related in /var/log/mail?
Josh
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 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?
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 Thursday 22 May 2003 12:17 pm, Nick Zentena wrote:
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-))
Fine... but HOW are you calling spamc? Are you piping the email through spamc?
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
On Thursday 22 May 2003 12:18 pm, Jon Clausen wrote:
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?
It should be a no brainer.
I start /usr/bin/spamd from /etc/init.d/boot.local without any options (but DO NOT forget to add the '&' to make it run in the background.)
Then I call spamc from procmail using:
| spamc
No options in either case.
HTH Jon Clausen -- If we can't be free, at least we can be cheap!
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.
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)
On 05/24/2003 01:54 AM, Bruce Marshall wrote:
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)
Or better yet, download the tar file, install the src.rpm from the CD, replace the tar in SOURCES, change the version number in the spec file, and rpm -bb --target=i586 spamassassin.spec works great (and stays SuSEfied). At least it seems to work fine here. (version 2.55)
Bruce Marshall bmarsh@bmarsh.com 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.
On Saturday 24 May 2003 4:25 am, Graham Murray wrote:
Bruce Marshall bmarsh@bmarsh.com 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.
Probably does if spamassassin got installed off the DVD. I didn't want to possibly mess up a later install.
Whatever.... do whatever it takes to make it work!
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 :-)
On Saturday 24 May 2003 5:31 am, Carlos E. R. wrote:
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").
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.
I always have used the CVS version.
If you want to have an easy way to start SA, then load it off the DVD. I didn't.
Do whatever it takes to make it work.
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 :-)
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.
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
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!
On Sat, May 24, 2003 at 10:55:50AM -0400, Bruce Marshall wrote:
-and I haven't even *received* any spam since!!! ;)
Is probably coincidence, but it *did* make me kind of suspicious at first. It *would* be kind of nice, though, if the mere precense of spamd/spamc on a system scared the spam to the degree that it never entered the mailqeue... ;)
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.
Which is precisely the purpose of having it. Stems back from when I was *very* new to procmail, and needed a way to make sure I wasn't losing mail while experimenting with recipes.
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.
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.
there hasn't been anything for it to catch... A highly unusual situation... may it last forever :)
I wish
Jon Clausen
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.
The 03.05.24 at 13:09, Jon Clausen wrote:
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!!! ;)
Good! :-)
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. The rule I have in .procmailrc is:
:0fw | /usr/bin/spamc :0 a: * ^X-Spam-Status: Yes $HOME/Mail/in_spam
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...
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 :)
Turn "full headers on" on your email viewer, and you will notice the line(s) added by SpamAssassin. Your's has:
X-Spam-Status: No, hits=-29.5 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,FROM_ENDS_IN_NUMS,IN_REP_TO, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp)
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 :-?
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
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"
: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 :-?
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.
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?
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
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).
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.
Yes, I thought of that.
Mmm, I'll keep your recipe, I like it :-)
* Carlos E. R. robin1.listas@tiscali.es [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/
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".
* Carlos E. R. robin1.listas@tiscali.es [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: procmail-users@procmail.org for submitting questions/answers. procmail-users-request@procmail.org for subscription requests.
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.
* Carlos E. R. robin1.listas@tiscali.es [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.
On Thursday 29 May 2003 6:55 am, Carlos E. R. wrote:
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.
-- Cheers, Carlos Robinson
Can you describe how you receive your email? fetchmail, getmail, other? and who is calling postfix?
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.
I've used about every combination possible of the above and I have *never* used anything other than /etc/procmailrc.
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.
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.
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.
* Bruce Marshall bmarsh@bmarsh.com [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.
On Thursday 29 May 2003 15:55 pm, Patrick Shanahan wrote:
- Bruce Marshall bmarsh@bmarsh.com [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.
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.
* Bruce Marshall bmarsh@bmarsh.com [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
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 just tried:
1) Starting fetchmail as root. 2) having fetchmail hand off to procmail 3) procmail did its delivery to /var/spool/mail/<wherever>
Now to try postfix in the middle.
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.
The 03.05.30 at 17:45, 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.
Ie, world readable, mine is not: it could be that.
Or it could be that I had recipes directly writing on folders, and that can not be done unless being root.
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 06/02/2003 02:47 AM, David Corking wrote:
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.
No. My 8.2 machine is here at home, so no need. I am only picking up 5 email accounts. /etc/procmail is what I used in 8.0, and spamassassin came with a good example file for me. But, I confess, I used Yast to get it all going (except for copying /etc/procmail and my old antivir key) for mail, and was amazed at how well it set up Postfix, etc. If it ain't broke...
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
-
Bruce Marshall -
Carlos E. R. -
David Corking -
Graham Murray -
Joe Morris (NTM) -
Jon Clausen -
Josh Trutwin -
Nick Zentena -
Patrick Shanahan -
Robert Sweet