Hi all, I'm sure this has been mentioned before, but I can't seem to get it right. I have this in my procmailrc :0 * ^Subject:.**SPAM** ! spambox@company.co.za Which works fine except that the mail loops once, so I get two of each in the spambox. I would rather like to do :0 * ^Subject:.**SPAM** /home/spambox/Maildir/ The mail gets delivered fine, except that it belongs to root instead of user spambox. How do I specify in procmail that this the ownership shouldn't change? All other users mail is fine, just this one account that gets delivered directly. Thanks -- Kind regards Hans du Plooy hansdp@newingtoncs.co.za
Αρχικό μήνυμα από Hans du Plooy
Hi all,
I'm sure this has been mentioned before, but I can't seem to get it right.
I have this in my procmailrc
:0 * ^Subject:.**SPAM** ! spambox@company.co.za
Which works fine except that the mail loops once, so I get two of each in the
spambox.
I would rather like to do
:0 * ^Subject:.**SPAM** /home/spambox/Maildir/
The mail gets delivered fine, except that it belongs to root instead of user
spambox. How do I specify in procmail that this the ownership shouldn't change? All other users mail is fine, just this one account that gets delivered directly.
Thanks
-- Kind regards Hans du Plooy hansdp@newingtoncs.co.za
-- 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
I am wondering about the same thing. I want also to redirect the spam mails to user account. Each time that a user receive a spam then the spam should be moved to a spamfolder within user's folder. I have ended up that procmailrc should do the job. Have you got anyithing in mind?
The Tuesday 2004-01-20 at 15:14 +0200, Hans du Plooy wrote:
I have this in my procmailrc
:0 * ^Subject:.**SPAM** ! spambox@company.co.za
Which works fine except that the mail loops once, so I get two of each in the spambox.
I would rather like to do
:0 * ^Subject:.**SPAM** /home/spambox/Maildir/
The mail gets delivered fine, except that it belongs to root instead of user spambox.
Ah. That must be because you you are talking of '/etc/procmailrc', aren't you? | 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). I think the rule should be: :0 * ^Subject:.**SPAM** ! spambox I think that when this rule executes, the mail is forwarded to that user, sending it back to postfix or sendmail - who will again call procmail for the user spambox: this run will read again /etc/procmailrc, so we have a loop. Ie, the above rule will not work properly. There must be a trick, but can't think of it now. -- Cheers, Carlos Robinson
Αρχικό μήνυμα από "Carlos E. R."
The Tuesday 2004-01-20 at 15:14 +0200, Hans du Plooy wrote:
I have this in my procmailrc
:0 * ^Subject:.**SPAM** ! spambox@company.co.za
Which works fine except that the mail loops once, so I get two of each in the spambox.
I would rather like to do
:0 * ^Subject:.**SPAM** /home/spambox/Maildir/
The mail gets delivered fine, except that it belongs to root instead of user spambox.
Ah. That must be because you you are talking of '/etc/procmailrc', aren't you?
| 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).
I think the rule should be:
:0 * ^Subject:.**SPAM** ! spambox
I think that when this rule executes, the mail is forwarded to that user, sending it back to postfix or sendmail - who will again call procmail for the user spambox: this run will read again /etc/procmailrc, so we have a loop. Ie, the above rule will not work properly.
There must be a trick, but can't think of it now.
-- 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
Do you use spamass-milter to intergate the spamassassin with the smtp? Should i create manually the spam-folder in user's ~/Maildir?
The Wednesday 2004-01-21 at 10:21 +0200, isofroni@cc.uoi.gr wrote:
Do you use spamass-milter to intergate the spamassassin with the smtp? Should i create manually the spam-folder in user's ~/Maildir?
No; as I mentioned on another thread where you asked about this, I don't even know what 'spamass-milter' is. I use postfix + antivir + procmail + spamassassin. I would work the same way with sendmail instead. It is not global filtering, but per-user filtering, in my case. Almost everything configured by Yast on SuSE 8.2 - but I have been using the the same or similar setup since SuSE 5.3 or roundabouts. -- Cheers, Carlos Robinson
On Tuesday 20 January 2004 19:55, isofroni@cc.uoi.gr wrote:
I am wondering about the same thing. I want also to redirect the spam mails to user account. Each time that a user receive a spam then the spam should be moved to a spamfolder within user's folder.
I have ended up that procmailrc should do the job. Have you got anyithing in mind?
Well, what I've got going IS the sollution - I've seen it done before, I'm just missing a piece of the puzzle :-) -- Kind regards Hans du Plooy hansdp@newingtoncs.co.za
On Tuesday 20 January 2004 23:11, Carlos E. R. wrote:
* ^Subject:.**SPAM** /home/spambox/Maildir/
The mail gets delivered fine, except that it belongs to root instead of user spambox.
Ah. That must be because you you are talking of '/etc/procmailrc', aren't you? Yes, sorry, I'll be more clear next time :-)
I think the rule should be: :0
* ^Subject:.**SPAM** ! spambox
I think that when this rule executes, the mail is forwarded to that user, sending it back to postfix or sendmail - who will again call procmail for the user spambox: this run will read again /etc/procmailrc, so we have a loop. Ie, the above rule will not work properly. Which is why I'm trying to drop the mail directly. I also tried putting another instance of the recipy in above the spamassassin recipy, but it didn't work - I still get two of each spam (as if I'm not getting enough spam as it is!)
Somehow there's got to be a way to change the permissions. I was thinking of setting a file creation mask on the Maildir/new directory, but umask didn't help. The files still belong to root instead of spambox. Thanks
| 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). Of course, doing it from .procmailrc would be fine, because it would belong to
On Wednesday 21 January 2004 10:21, isofroni@cc.uoi.gr wrote: the user, but that would only work if the spam was intended for user spambox in the first place, otherwise user spambox's .procmailrc isn't going to be read.
Do you use spamass-milter to intergate the spamassassin with the smtp? Should i create manually the spam-folder in user's ~/Maildir? No, I use postfix
-- Kind regards Hans du Plooy hansdp@newingtoncs.co.za
The Wednesday 2004-01-21 at 17:49 +0200, Hans du Plooy wrote:
I think the rule should be: :0 * ^Subject:.**SPAM** ! spambox
I think that when this rule executes, the mail is forwarded to that user, sending it back to postfix or sendmail - who will again call procmail for the user spambox: this run will read again /etc/procmailrc, so we have a loop. Ie, the above rule will not work properly. Which is why I'm trying to drop the mail directly. I also tried putting another instance of the recipy in above the spamassassin recipy, but it didn't work - I still get two of each spam (as if I'm not getting enough spam as it is!)
Perhaps there is a way to detect, in /etc/procmailrc, that mail has already been forwarded, and that we are now in the part of the process belonging to the 'spambox' user. Maybe there is a header that changes in the process that you can check. Perhaps a ^TOspambox rule, or a forwarded to, or originally to, I don't know. Look carefully at your headers, for one that has been created in the process. If there is no such header, you can add it yourself; at worst, use formail for that. Or reread again the examples man page, maybe we are overlooking something.
Somehow there's got to be a way to change the permissions. I was thinking of setting a file creation mask on the Maildir/new directory, but umask didn't help. The files still belong to root instead of spambox.
Don't know. -- Cheers, Carlos Robinson
The Wednesday 2004-01-21 at 17:51 +0200, Hans du Plooy wrote:
| 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). Of course, doing it from .procmailrc would be fine, because it would belong to the user, but that would only work if the spam was intended for user spambox in the first place, otherwise user spambox's .procmailrc isn't going to be read.
No, you took it out of context - that paragraph I took from the man page, and it applies because we are forwarding to the user named 'spambox'. It doesn't for your second original rule, of course. -- Cheers, Carlos Robinson
Αρχικό μήνυμα από "Carlos E. R."
The Wednesday 2004-01-21 at 10:21 +0200, isofroni@cc.uoi.gr wrote:
Do you use spamass-milter to intergate the spamassassin with the smtp? Should i create manually the spam-folder in user's ~/Maildir?
No; as I mentioned on another thread where you asked about this, I don't even know what 'spamass-milter' is. I use postfix + antivir + procmail + spamassassin. I would work the same way with sendmail instead.
It is not global filtering, but per-user filtering, in my case. Almost everything configured by Yast on SuSE 8.2 - but I have been using the the same or similar setup since SuSE 5.3 or roundabouts.
-- 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
All right, i want system-wide to install spamassassin with sendmail. Is this enough? Only sendmail + spam assassin? The ridirection of the spams, how could be done then? In a spam-folder. (every user has his own spam folder to check his mails before he deletes them)
The Thursday 2004-01-22 at 17:39 +0200, isofroni@cc.uoi.gr wrote:
All right, i want system-wide to install spamassassin with sendmail. Is this enough? Only sendmail + spam assassin?
And procmail. Well, as I don't use it that way, I'm not the right person to answer your question; but I'll say what I would do. [spamassassin comes with documentation: please read it, this is documented] The setup is the same I reported... on this thread, to another person, 21 Jan 2004 20:44:40, X-Message-Number-for-archive: 176430. Please check that email. The only difference would be using amavis-sendmail instead of amavisd-postfix. Then, file /etc/procmailrc would simply have this rule: :0fw | /usr/bin/spamc That triggers spamassassin; it doesn't move nor delete anything, but depending on its configuration adds a header, modifies the header or adds a text explaining why it is spam. That's configurable.
The ridirection of the spams, how could be done then? In a spam-folder. (every user has his own spam folder to check his mails before he deletes them)
That depends on what each user wants. The above rule will add a header (X-Spam-Status: Yes) that has to be checked. How? Well it can be done by the user's mail client program. In that case, they have to use the filtering capacity of whatever program they use. Or, they can simply create their own ~/.procmailrc file, containing this at the beginning: :0 * ^X-Spam-Status: Yes $HOME/Mail/in_spam Or something similar. -- Cheers, Carlos Robinson
----- Original Message -----
From: "Carlos E. R."
The Thursday 2004-01-22 at 17:39 +0200, isofroni@cc.uoi.gr wrote:
All right, i want system-wide to install spamassassin with sendmail. Is this enough? Only sendmail + spam assassin?
And procmail.
Well, as I don't use it that way, I'm not the right person to answer your question; but I'll say what I would do.
[spamassassin comes with documentation: please read it, this is documented]
The setup is the same I reported... on this thread, to another person, 21 Jan 2004 20:44:40, X-Message-Number-for-archive: 176430. Please check that email. The only difference would be using amavis-sendmail instead of amavisd-postfix.
Then, file /etc/procmailrc would simply have this rule:
:0fw | /usr/bin/spamc
That triggers spamassassin; it doesn't move nor delete anything, but depending on its configuration adds a header, modifies the header or adds a text explaining why it is spam. That's configurable.
The ridirection of the spams, how could be done then? In a spam-folder.
(every
user has his own spam folder to check his mails before he deletes them)
That depends on what each user wants. The above rule will add a header (X-Spam-Status: Yes) that has to be checked. How? Well it can be done by the user's mail client program. In that case, they have to use the filtering capacity of whatever program they use.
Or, they can simply create their own ~/.procmailrc file, containing this at the beginning:
:0 * ^X-Spam-Status: Yes $HOME/Mail/in_spam
Or something similar.
-- 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
I have already install the SpamAssassin. Now how to tell sendmail that spamassasssin exists? I used INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,T=C:15m;S:4m;R:4m;E:10m') in the sendmail.cf (but i suspect that this command is for the spamass-milter) and an error concerning the spamass.sock that doen't exist. What am i doing wrong?
The Monday 2004-01-26 at 11:24 +0200, John wrote:
I have already install the SpamAssassin. Now how to tell sendmail that spamassasssin exists?
You don't. If you let Yast install and configure sendmail, you don't need to - provided you follow the instructions I already told you. You only need to configure procmail as documented, and as I explained. Please read the docs for details.
I used INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,T=C:15m;S:4m;R:4m;E:10m') in the sendmail.cf (but i suspect that this command is for the spamass-milter) and an error concerning the spamass.sock that doen't exist.
If you modified the sendmail configuration, I can not help you. -- Cheers, Carlos Robinson
Αρχικό μήνυμα από "Carlos E. R."
The Monday 2004-01-26 at 11:24 +0200, John wrote:
I have already install the SpamAssassin. Now how to tell sendmail that spamassasssin exists?
You don't. If you let Yast install and configure sendmail, you don't need to - provided you follow the instructions I already told you. You only need to configure procmail as documented, and as I explained. Please read the docs for details.
I used INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,T=C:15m;S:4m;R:4m;E:10m') in the sendmail.cf (but i suspect that this command is for the spamass-milter) and an error concerning the spamass.sock that doen't exist.
If you modified the sendmail configuration, I can not help you.
-- 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
Alright, it finally worked. Another issue is about spamassassin "decisions" for the same mail. Two similar mails can score different points (one paased and the other failed) Do you know why is that happening?
The Tuesday 2004-01-27 at 10:35 +0200, isofroni@cc.uoi.gr wrote:
Alright, it finally worked.
Good! :-)
Another issue is about spamassassin "decisions" for the same mail. Two similar mails can score different points (one paased and the other failed)
Do you know why is that happening?
Look carefully at the report - this can be hidden as headers, or in clear text. For one that passed, you will see something like this: |X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on | nimrodel.valinor |X-Spam-Level: **** |X-Spam-Status: No, hits=4.8 required=5.0 tests=BAYES_90,MIME_BOUND_MANY_HEX | autolearn=no version=2.61 This one got 4.8 points, less than 5, so it passed; You can see the tests that indicate the level of "spamminess". For one marked as spam, there is a report in clear (or no report, depends on your personal configuration), giving details of each test. First, the headers: |X-Spam-Flag: YES |X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on | nimrodel.valinor |X-Spam-Level: ********** |X-Spam-Status: Yes, hits=10.1 required=5.0 tests=BAYES_99,MIME_BOUND_MANY_HEX, | NIGERIAN_BODY1 autolearn=no version=2.61 And then, the report: |Content analysis details: (10.1 points, 5.0 required) | | pts rule name description |---- ---------------------- -------------------------------------------------- | 2.7 MIME_BOUND_MANY_HEX Spam tool pattern in MIME boundary | 5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100% | [score: 1.0000] | 2.0 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ Finally, you can do more things. You can "teach" the bayesian filter about what you consider spam and what not - you will find details about this on spamassassin documentation, because it is long to explain. It has been commented as well on the list many times, simply browse the list archive looking for spam or bayes in the subject line. Look also at the unofficial SuSE FAQ. -- Cheers, Carlos Robinson
Αρχικό μήνυμα από "Carlos E. R."
The Tuesday 2004-01-27 at 10:35 +0200, isofroni@cc.uoi.gr wrote:
Alright, it finally worked.
Good! :-)
Another issue is about spamassassin "decisions" for the same mail. Two similar mails can score different points (one paased and the other
failed)
Do you know why is that happening?
Look carefully at the report - this can be hidden as headers, or in clear text. For one that passed, you will see something like this:
|X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on | nimrodel.valinor |X-Spam-Level: **** |X-Spam-Status: No, hits=4.8 required=5.0 tests=BAYES_90,MIME_BOUND_MANY_HEX | autolearn=no version=2.61
This one got 4.8 points, less than 5, so it passed; You can see the tests that indicate the level of "spamminess".
For one marked as spam, there is a report in clear (or no report, depends on your personal configuration), giving details of each test. First, the headers:
|X-Spam-Flag: YES |X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on | nimrodel.valinor |X-Spam-Level: ********** |X-Spam-Status: Yes, hits=10.1 required=5.0 tests=BAYES_99,MIME_BOUND_MANY_HEX, | NIGERIAN_BODY1 autolearn=no version=2.61
And then, the report:
|Content analysis details: (10.1 points, 5.0 required) | | pts rule name description |---- ---------------------- -------------------------------------------------- | 2.7 MIME_BOUND_MANY_HEX Spam tool pattern in MIME boundary | 5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100% | [score: 1.0000] | 2.0 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+
Finally, you can do more things. You can "teach" the bayesian filter about what you consider spam and what not - you will find details about this on spamassassin documentation, because it is long to explain. It has been commented as well on the list many times, simply browse the list archive looking for spam or bayes in the subject line.
Look also at the unofficial SuSE FAQ.
-- 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
I would also like to ask you if i can change the spam file , where the spams are achived. For example if my user test receive a spam the procmail is going to create a file :0 * ^X-Spam-Status: Yes $HOME/Mail/in_spam in_spam with the default onwership root:root Can be that changed during the creation, because i have to change the ownership for every user receives a spam for a first time.
The Tuesday 2004-01-27 at 16:34 +0200, isofroni@cc.uoi.gr wrote: Please don't copy the full message to which you are answering, everybody has it already.
I would also like to ask you if i can change the spam file , where the spams are achived.
For example if my user test receive a spam the procmail is going to create a file
:0 * ^X-Spam-Status: Yes $HOME/Mail/in_spam
in_spam with the default onwership root:root
Can be that changed during the creation, because i have to change the ownership for every user receives a spam for a first time.
You misunderstood the idea. I said you could create a '/etc/procmailrc' file with only one rule: :0fw | /usr/bin/spamc This triggers processing by SpammAssassin, but not filtering: it will not move spam do a diferent folder. For filtering, every user has two possibilities: 1) Create his own '/home/test/.procmailrc' file. And '/home/john/.procmailrc', and '/home/mike/.procmailrc' and '/home/isofroni/.procmailrc' - that is, one for every user that wants to use procmail for his personal delivery. That file must have one rule at the beginning: :0 * ^X-Spam-Status: Yes $HOME/Mail/in_spam and spam will be delivered to file '/home/isofroni/Mail/in_spam' (and '/home/john/Mail/in_spam', and '/home/mike/Mail/in_spam', and '/home/test/Mail/in_spam'... etc. It will go to that file with his user ownersship (test:users, john:root, etc). Of course, he can change that file. So, with the above rule, spam to user 'test' will go to '/home/test/Mail/in_spam'. Non spam will be left at '/var/spool/mail/test' - but this can be changed if the user wants to. Every user must configure his own rules - but you can define an skeleton in '/etc/skel/' for every new user. 2) If any user does not want to use procmail, then simply he doesn't create his .procmailrc file. Instead, he has to define a rule or filter in whatever program he uses to see his mail, like kmail, mozilla, evolution... etc. He has to detect a header containing "X-Spam-Status: Yes", and if it matches, move the email to wherever he wants. This is a global setup, because spamassassin runs globally. But every user has to define his own filtering. It is not the only way to set it up, just one of the possible ways. For example, I don't have '/etc/procmailrc'. You really should read the documentation in: /usr/share/doc/packages/spamassassin/* (specially about spamd) /usr/share/doc/packages/perl-spamassassin/* /usr/share/doc/package/sendmail/* Everything I said is there, and I can not explain every detail. For example, if you have many users, this method might not be the best. Have a look at the spamassassin web page for more methods. -- Cheers, Carlos Robinson
Αρχικό μήνυμα από "Carlos E. R."
The Tuesday 2004-01-27 at 16:34 +0200, isofroni@cc.uoi.gr wrote:
Please don't copy the full message to which you are answering, everybody has it already.
I would also like to ask you if i can change the spam file , where the spams are achived.
For example if my user test receive a spam the procmail is going to create a file
:0 * ^X-Spam-Status: Yes $HOME/Mail/in_spam
in_spam with the default onwership root:root
Can be that changed during the creation, because i have to change the ownership for every user receives a spam for a first time.
You misunderstood the idea.
I said you could create a '/etc/procmailrc' file with only one rule:
:0fw | /usr/bin/spamc
This triggers processing by SpammAssassin, but not filtering: it will not move spam do a diferent folder.
For filtering, every user has two possibilities:
1) Create his own '/home/test/.procmailrc' file.
And '/home/john/.procmailrc', and '/home/mike/.procmailrc' and '/home/isofroni/.procmailrc' - that is, one for every user that wants to use procmail for his personal delivery. That file must have one rule at the beginning:
:0 * ^X-Spam-Status: Yes $HOME/Mail/in_spam
and spam will be delivered to file '/home/isofroni/Mail/in_spam' (and '/home/john/Mail/in_spam', and '/home/mike/Mail/in_spam', and '/home/test/Mail/in_spam'... etc. It will go to that file with his user ownersship (test:users, john:root, etc). Of course, he can change that file.
So, with the above rule, spam to user 'test' will go to '/home/test/Mail/in_spam'. Non spam will be left at '/var/spool/mail/test' - but this can be changed if the user wants to. Every user must configure his own rules - but you can define an skeleton in '/etc/skel/' for every new user.
2) If any user does not want to use procmail, then simply he doesn't create his .procmailrc file. Instead, he has to define a rule or filter in whatever program he uses to see his mail, like kmail, mozilla, evolution... etc. He has to detect a header containing "X-Spam-Status: Yes", and if it matches, move the email to wherever he wants.
This is a global setup, because spamassassin runs globally. But every user has to define his own filtering. It is not the only way to set it up, just one of the possible ways. For example, I don't have '/etc/procmailrc'.
You really should read the documentation in:
/usr/share/doc/packages/spamassassin/* (specially about spamd) /usr/share/doc/packages/perl-spamassassin/* /usr/share/doc/package/sendmail/*
Everything I said is there, and I can not explain every detail. For example, if you have many users, this method might not be the best. Have a look at the spamassassin web page for more methods.
-- 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
Yes, Carlo you are right but if i use both rules in /etc/procmailrc then it will be applied to any user and that is what i really want! Therefore, i have to change the spam file to user:group ownership manually, just once, only in the beginning. Another question is if procmail is an expansion of the sendmail, or does it support every MTA such as postfix and qmail especially? Whata about solaris procmail+sendmail?
The Wednesday 2004-01-28 at 10:06 +0200, isofroni@cc.uoi.gr wrote:
Yes, Carlo you are right but if i use both rules in /etc/procmailrc then it will be applied to any user and that is what i really want!
Mmm. If you want really global filtering, then you should have a look at the spamassassin page for guidance. It was designed for a "per user" setup, and it loads heavily the computer. But they have sugestion for that.
Therefore, i have to change the spam file to user:group ownership manually, just once, only in the beginning.
Unless the user deletes it.
Another question is if procmail is an expansion of the sendmail, or does it support every MTA such as postfix and qmail especially?
No, it is not an expansion, it is independent. It should work with anything.
Whata about solaris procmail+sendmail?
As far as I know, it should work. -- Cheers, Carlos Robinson
Therefore, i have to change the spam file to user:group ownership manually, just once, only in the beginning.
Unless the user deletes it.
Who user deletes which file when the file in_spam is created under root's ownership. Then, the user cannot even read the file :)
On Thursday 29 January 2004 09.02, isofroni@cc.uoi.gr wrote:
Therefore, i have to change the spam file to user:group ownership manually,
just
once, only in the beginning.
Unless the user deletes it.
Who user deletes which file when the file in_spam is created under root's ownership.
Then, the user cannot even read the file :)
When you delete a file, the ownership of the actual file is unimportant. To delete a file you only need write permission on the directory the file is in
I feel that was not understood.
procmail creates the file (if the file hasn't been created before) with root
ownership in $HOME/Mail/
I feel that prcomail create the file with the as if it was root's file
because it is run by root, silently.
Is that right?
----- Original Message -----
From: "Anders Johansson"
On Thursday 29 January 2004 09.02, isofroni@cc.uoi.gr wrote:
Therefore, i have to change the spam file to user:group ownership manually,
just
once, only in the beginning.
Unless the user deletes it.
Who user deletes which file when the file in_spam is created under root's ownership.
Then, the user cannot even read the file :)
When you delete a file, the ownership of the actual file is unimportant. To delete a file you only need write permission on the directory the file is in
-- 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
On Thursday 29 January 2004 09.15, John wrote:
I feel that was not understood.
procmail creates the file (if the file hasn't been created before) with root ownership in $HOME/Mail/
I feel that prcomail create the file with the as if it was root's file because it is run by root, silently.
Is that right?
I have no idea, I don't use procmail. I was only commenting on the "how can a user delete a file when it's owned by root" question.
On Thursday 29 January 2004 10:15, John wrote:
I feel that was not understood.
procmail creates the file (if the file hasn't been created before) with root ownership in $HOME/Mail/
I feel that prcomail create the file with the as if it was root's file because it is run by root, silently.
Is that right? Yes, before this thread took it's many turns, that's the problem I'm having. In this recipy:
:0 * ^Subject:.**SPAM** /home/spambox/Maildir/ Still haven't found a solution, apart from ! forwarding it, but then I receive two copies of each Thanks -- Kind regards Hans du Plooy hansdp@newingtoncs.co.za
The Thursday 2004-01-29 at 10:02 +0200, isofroni@cc.uoi.gr wrote:
Therefore, i have to change the spam file to user:group ownership manually, just once, only in the beginning.
Unless the user deletes it.
Who user deletes which file when the file in_spam is created under root's ownership.
Then, the user cannot even read the file :)
Exactly. That's why I said that moving mail to a folder should be defined on the user's .procmailrc file, not on /etc/procmail. -- Cheers, Carlos Robinson
On Thu, Jan 29, 2004 at 03:24:36PM +0200, Hans du Plooy wrote:
On Thursday 29 January 2004 10:15, John wrote:
I feel that was not understood.
procmail creates the file (if the file hasn't been created before) with root ownership in $HOME/Mail/
I feel that prcomail create the file with the as if it was root's file because it is run by root, silently.
Is that right? Yes, before this thread took it's many turns, that's the problem I'm having. In this recipy:
:0 * ^Subject:.**SPAM** /home/spambox/Maildir/
Still haven't found a solution, apart from ! forwarding it, but then I receive two copies of each
You might want to investigate DROPPRIVS. From man procmailrc: DROPPRIVS If set to `yes' procmail will drop all privileges it might have had (suid or sgid). This is only useful if you want to guarantee that the bottom half of the /etc/procmailrc file is executed on behalf of the recipient. I've no clue exactly what "the bottom half of /etc/procmailrc" covers though... HTH /Jon -- Whatever rocks your boat!
The Friday 2004-01-30 at 06:44 +0100, Jon Clausen wrote:
You might want to investigate DROPPRIVS. From man procmailrc:
DROPPRIVS If set to `yes' procmail will drop all privileges it might have had (suid or sgid). This is only useful if you want to guarantee that the bottom half of the /etc/procmailrc file is executed on behalf of the recipient.
I've no clue exactly what "the bottom half of /etc/procmailrc" covers though...
I saw that, too, but as yourself, I'm not sure of what "bottom half" means. Probably the rest of the file below the token, but then they could have said so direclty... a sample of its use is missing. -- Cheers, Carlos Robinson
On Thursday 29 January 2004 23:59, Carlos E. R. wrote:
Exactly. That's why I said that moving mail to a folder should be defined on the user's .procmailrc file, not on /etc/procmail.
OK, but then, how do I tell procmail to use ~/.procmailrc for one user and /etc/procmailrc for the rest? Having to make a .procmailrc for each user won't always be ideal. Thanks -- Kind regards Hans du Plooy hansdp@newingtoncs.co.za
Αρχικό μήνυμα από "Carlos E. R."
The Thursday 2004-01-29 at 10:02 +0200, isofroni@cc.uoi.gr wrote:
Therefore, i have to change the spam file to user:group ownership manually, just once, only in the beginning.
Unless the user deletes it.
Who user deletes which file when the file in_spam is created under root's ownership.
Then, the user cannot even read the file :)
Exactly. That's why I said that moving mail to a folder should be defined on the user's .procmailrc file, not on /etc/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
Except, whether the root chown all users spam files at the beginning.
On Friday 30 January 2004 07:44, Jon Clausen wrote:
You might want to investigate DROPPRIVS. From man procmailrc: Thanks, I think I'm on the right track now. I'm just not sure which "recipient" they're talking about - is it the person that the mail was orinially sent to? Remember I'm droping a copy (directly) into another user's maildir Procmail log gives me:
procmail: Assigning "DROPPRIVS=yes" procmail: Assuming identity of the recipient, VERBOSE=off procmail: Couldn't create or rename temp file "/home/spambox/Maildir/ tmp/1075465122.18447_2.hermes" I get the idea it's using the identity of the original recipient (hansdp in this case) instead of spambox. Is this correct? Also, I wonder why it says VERBOSE=off when I specify VERBOSE=on in my /etc/ procmailrc Thanks! -- Kind regards Hans du Plooy hansdp@newingtoncs.co.za
The Friday 2004-01-30 at 12:17 +0200, Hans du Plooy wrote:
On Thursday 29 January 2004 23:59, Carlos E. R. wrote:
Exactly. That's why I said that moving mail to a folder should be defined on the user's .procmailrc file, not on /etc/procmail.
OK, but then, how do I tell procmail to use ~/.procmailrc for one user and /etc/procmailrc for the rest?
That's automatic. Procmail first processes /etc/procmailrc, and then goes to the user to whom the present email is destined, and processes his ~/.procmailrc file, it it exists.
Having to make a .procmailrc for each user won't always be ideal.
If they are real users on the system, it is up to them to decide. If they are not real users, but you act as a relay or mail server, then yes, it is impractical. There are ideas for that on the spamassassin site, I think. Spamassassin is designed to be run by each user: the idea is that what one users considers spam, another one doesn't. Therefore, each users should have his own definitions and configurations. That is impractical for a server: now it is possible to use spamassassin with an SQL database. I know nothing of this, only that it exists. -- Cheers, Carlos Robinson
* Hans du Plooy
I get the idea it's using the identity of the original recipient (hansdp in this case) instead of spambox. Is this correct?
Also, I wonder why it says VERBOSE=off when I specify VERBOSE=on in my /etc/ procmailrc
You would probably get more accurate answers in the procmail list @ procmail@lists.RWTH-Aachen.DE -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org
On 01/30/2004 06:17 PM, Hans du Plooy wrote:
On Thursday 29 January 2004 23:59, Carlos E. R. wrote:
Exactly. That's why I said that moving mail to a folder should be defined on the user's .procmailrc file, not on /etc/procmail.
OK, but then, how do I tell procmail to use ~/.procmailrc for one user and /etc/procmailrc for the rest?
Having to make a .procmailrc for each user won't always be ideal.
I just worked on this today. I have an /etc/procmailrc just for sending mail through spamassassin. One user wanted mail over a certain size to be forwarded to another address, which I was able to do with a ~/.procmailrc file. It appears after tests to work as wanted. You would only need a ~/.procmailrc for users that need more. BTW, my /etc/procmailrc does have the DROPPRIVS=yes option. HTH. -- 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.
Another hot question is about the aliases. I mean that if spam hits an aliases that forwards the mail to all members. Then procmail how is going to filter the message? Will filter the spam for every final recipient as if the spam targeted the final recipient? Thanks in advance.
The Friday 2004-01-30 at 14:50 +0200, Hans du Plooy wrote:
Thanks, I think I'm on the right track now. I'm just not sure which "recipient" they're talking about - is it the person that the mail was orinially sent to? Remember I'm droping a copy (directly) into another user's maildir Procmail log gives me:
procmail: Assigning "DROPPRIVS=yes" procmail: Assuming identity of the recipient, VERBOSE=off procmail: Couldn't create or rename temp file "/home/spambox/Maildir/ tmp/1075465122.18447_2.hermes"
I get the idea it's using the identity of the original recipient (hansdp in this case) instead of spambox. Is this correct?
Could be, that is the recipient for him - even if you change the folder, the recipient doesn't, it is given from the start.
Also, I wonder why it says VERBOSE=off when I specify VERBOSE=on in my /etc/ procmailrc
Try put verbose=on below dropprivs Another idea. You can bounce mail, not from /etc/procmail, but from /home/hansdp/.procmailrc.... no probably not, not in your setup. Mmmm. -- Cheers, Carlos Robinson
The Saturday 2004-01-31 at 15:24 +0200, John wrote:
Another hot question is about the aliases.
I mean that if spam hits an aliases that forwards the mail to all members.
Then procmail how is going to filter the message?
Will filter the spam for every final recipient as if the spam targeted the final recipient?
Huh? Sorry, I got lost. Could you expand your meaning with an example, please? :-) -- Cheers, Carlos Robinson
----- Original Message -----
From: "Carlos E. R."
The Saturday 2004-01-31 at 15:24 +0200, John wrote:
Another hot question is about the aliases.
I mean that if spam hits an aliases that forwards the mail to all
Then procmail how is going to filter the message?
Will filter the spam for every final recipient as if the spam targeted
members. the
final recipient?
Huh? Sorry, I got lost. Could you expand your meaning with an example, please? :-)
-- 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
Ok. Say broadcast@localhost broadcast: usera, userb, userc, userd, ... Everyone who sends to broadcast@server, the messages goes to usera, userb, ... I tried that and it worked properly. procmail filters the mails for every recepient separately.
On Saturday 31 January 2004 17:44, Carlos E. R. wrote:
Also, I wonder why it says VERBOSE=off when I specify VERBOSE=on in my
/etc/ procmailrc
Try put verbose=on below dropprivs Didn't work, but making a .procmailrc for me and putting just that in there did. Thanks for that tip - I'm getting to your other reply just now
Hans
On Mon, Feb 02, 2004 at 11:13:19AM +0200, Hans du Plooy wrote:
On Saturday 31 January 2004 17:44, Carlos E. R. wrote:
Also, I wonder why it says VERBOSE=off when I specify VERBOSE=on in my
/etc/ procmailrc
Try put verbose=on below dropprivs Didn't work, but making a .procmailrc for me and putting just that in there did. Thanks for that tip - I'm getting to your other reply just now
man procmail: section about [Extended diagnostics]: ... Assuming identity of the recipient, VERBOSE=off Dropping all privileges (if any), implicitly turns off extended diagnostics. ... I'm guessing that you won't see any diagnostic messages until the point where you include your .procmailrc ... Question is, whether one might 'hotwire' procmail by including a .procmailrc.verbosity early in /etc/procmailrc, and then including your *real* .procmailrc later... Something like: # /etc/procmailrc DROPPRIVS=yes INCLUDERC=/home/$USER/.procmailrc.verbosity <system recipes> INCLUDERC=/home/$USER/.procmailrc I have no idea if this would work, but thought I'd throw the idea in here... Cheers, Jon -- Whatever rocks your boat!
The Monday 2004-02-02 at 09:52 +0200, John wrote:
Ok. Say broadcast@localhost
broadcast: usera, userb, userc, userd, ...
Everyone who sends to broadcast@server, the messages goes to usera, userb, ...
I tried that and it worked properly. procmail filters the mails for every recepient separately.
Ah. Using the global /etc/prcomailrc, or a file per user? The second it is obvious it should work. The first one is not so obvious. Interesting. -- Cheers, Carlos Robinson
participants (8)
-
Anders Johansson -
Carlos E. R. -
Hans du Plooy -
isofroni＠cc.uoi.gr -
Joe Morris (NTM) -
John
-
Jon Clausen -
Patrick Shanahan