Seems that no matter how I pharse the SuSE rule I cannot get the SuSE-list emails to go to the correct directory using procmail. I have tried different variations: To:.*suse-linux-e\@suse.com To:.*suse-linux-e To:.*suse.com ..all of which fail. Anyone care to share how they're doing it? Thanks. -- "Yogi" CH Namaste Yoga Studio
On Saturday 02 October 2004 9:55 am, C Hamel wrote:
Seems that no matter how I pharse the SuSE rule I cannot get the SuSE-list emails to go to the correct directory using procmail. I have tried different variations:
To:.*suse-linux-e\@suse.com
To:.*suse-linux-e
To:.*suse.com
..all of which fail. Anyone care to share how they're doing it?
I go for the List-Id header myself.... * ^List-Id:.*(suse\.com|sqlite|popfile) Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.108-default x86_64
On Saturday 02 October 2004 12:55 pm, C Hamel wrote:
Seems that no matter how I pharse the SuSE rule I cannot get the SuSE-list emails to go to the correct directory using procmail. I have tried different variations:
To:.*suse-linux-e\@suse.com
To:.*suse-linux-e
To:.*suse.com
..all of which fail. Anyone care to share how they're doing it?
Thanks.
* ^.*suse.com (blank after the '*')
On Sat, 2 Oct 2004 16:55:11 +0000 C Hamel <yogich@sc2000.net> wrote:
Seems that no matter how I pharse the SuSE rule I cannot get the SuSE-list emails to go to the correct directory using procmail. I have tried different variations:
..all of which fail. Anyone care to share how they're doing it?
:0f * ^X-Mailinglist: suse-linux-e | /usr/bin/formail -bfi "Reply-To:suse-linux-e@suse.com" :0 a: /home/psrwebs/smail/Suse/. There is a 'dot' at the end because I use MH format. - Richard -- Richard Kimber http://www.psr.keele.ac.uk/
On Sat, 02 Oct, 2004 at 16:55:11 +0000, C Hamel wrote:
Seems that no matter how I pharse the SuSE rule I cannot get the SuSE-list emails to go to the correct directory using procmail. I have tried different variations:
To:.*suse-linux-e\@suse.com
To:.*suse-linux-e
To:.*suse.com
..all of which fail. Anyone care to share how they're doing it?
I'm using the "X-Mailinglist" header. It's a nonstandard header, but it works fine, and I'm guessing they add it specificly to simplify procmail filtering: # suse-linux-e: :0 * ^X-Mailinglist: suse-linux-e | $IMAPCOMMAND $SLE # suse-linux-ot: :0 * ^X-Mailinglist: suse-ot | $IMAPCOMMAND $SLEot The use of variables in the pipe is something I picked up in some howto or other. It complicated the initial setup, but now I'm happy with it. Although a large part of that complication stemmed from me wanting to set up Postfix, Procmail, Spamassassin and Cyrus all in one go, neither of which I knew very well at the time :P /Jon -- Just say "know!"
On Sunday 2004 October 3 07:03, Jon Clausen wrote:
On Sat, 02 Oct, 2004 at 16:55:11 +0000, C Hamel wrote:
Seems that no matter how I pharse the SuSE rule I cannot get the SuSE-list emails to go to the correct directory using procmail. I have tried different variations:
To:.*suse-linux-e\@suse.com
To:.*suse-linux-e
To:.*suse.com
..all of which fail. Anyone care to share how they're doing it?
I'm using the "X-Mailinglist" header. It's a nonstandard header, but it works fine, and I'm guessing they add it specificly to simplify procmail filtering:
# suse-linux-e: :0
* ^X-Mailinglist: suse-linux-e
| $IMAPCOMMAND $SLE
# suse-linux-ot: :0
* ^X-Mailinglist: suse-ot
| $IMAPCOMMAND $SLEot
The use of variables in the pipe is something I picked up in some howto or other. It complicated the initial setup, but now I'm happy with it. Although a large part of that complication stemmed from me wanting to set up Postfix, Procmail, Spamassassin and Cyrus all in one go, neither of which I knew very well at the time :P
/Jon -- Just say "know!" Pipes is something I need to understand better than I do. I use simple pipes (like | less & | grep <item>) w/o totally understanding how they work. Guess I'll ry this example & see what happens. :-)
(While we're on the subj... I was hopig to also get the process using Mailder rather than mbox, and putting msgs in KMail's inbox, etc. Had it working, once, then it busted & I don't know what I did. Guess that's another post; right?) Thanks! -- "Yogi" CH Namaste Yoga Studio
On Sun, 03 Oct, 2004 at 10:17:29 +0000, C Hamel wrote:
On Sunday 2004 October 3 07:03, Jon Clausen wrote:
The use of variables in the pipe is something I picked up in some howto or other. It complicated the initial setup, but now I'm happy with it. Although a large part of that complication stemmed from me wanting to set up Postfix, Procmail, Spamassassin and Cyrus all in one go, neither of which I knew very well at the time :P
Pipes is something I need to understand better than I do. I use simple pipes (like | less & | grep <item>) w/o totally understanding how they work. Guess I'll ry this example & see what happens. :-)
Well... Pipes may not be appropriate for what you want to achieve here, but... The concept itself is very simple: command1 | command2 basically executes `command1` and takes whatever output this produces, and feeds it to `command2`. Pretty simple. Now, in reality it *is* a bit more complex than that, but that's another subject.
(While we're on the subj... I was hopig to also get the process using Mailder rather than mbox, and putting msgs in KMail's inbox, etc. Had it working, once, then it busted & I don't know what I did. Guess that's another post; right?)
Probably :) In any case I may as well explain why pipes is the right thing for me (and incidentally why they might not be for you): My system is set up so that incoming mail is passed from Postfix -> Procmail For processing Procmail -> SpamAssassin For Spam-classification SpamAssassin -> Procmail For further processing (including user procmailrcs) Procmail -> Cyrus For final delivery Now, it's in this final step, where the user procmailrc contains the pipe that feeds it's data (each message) to $IMAPCOMMAND $Destination $IMAPCOMMAND contains "/usr/lib/cyrus/bin/deliver -a $USER -q -m" and $Destination contains something like "user.SLE" which all tells *Cyrus* what to do with the message. The reason for all this is that I'm *accessing* my mail through (Cyrus) IMAP only. And Cyrus takes care of all the 'housekeeping', including where to put the actual file in the filesystem, and subsequent manipulations like moving msgs around and deleting them and so on. Under this scheme each message is still just a file, but *I* don't own it, *Cyrus* does. And in fact *I* (the user) haven't got read-priviliges in the area where Cyrus keeps the messages (/var/spool/imap/user/) And so: Unless you have some sort of MDA to take care of final delivery, you probably don't want to pipe anything anywhere. Just let Procmail write the file in your ~/Mail/inbox/new - or wherever Kmail expects to see new messages (I don't know. I haven't used Kmail in quite a while, and never like that...) Hope I'm not confusing you with all this, but it seemed prudent to explain why I'm using pipes, and why it might not be appropriate for you /Jon -- Just say "know!"
On Monday 2004 October 4 05:27, Jon Clausen wrote: <SNIP>
Well... Pipes may not be appropriate for what you want to achieve here, but...
The concept itself is very simple:
command1 | command2
basically executes `command1` and takes whatever output this produces, and feeds it to `command2`. Pretty simple. Now, in reality it *is* a bit more complex than that, but that's another subject.
(While we're on the subj... I was hopig to also get the process using Mailder rather than mbox, and putting msgs in KMail's inbox, etc. Had it working, once, then it busted & I don't know what I did. Guess that's another post; right?)
Probably :)
In any case I may as well explain why pipes is the right thing for me (and incidentally why they might not be for you):
My system is set up so that incoming mail is passed from
Postfix -> Procmail For processing Procmail -> SpamAssassin For Spam-classification SpamAssassin -> Procmail For further processing (including user procmailrcs) Procmail -> Cyrus For final delivery
Now, it's in this final step, where the user procmailrc contains the pipe that feeds it's data (each message) to
$IMAPCOMMAND $Destination
$IMAPCOMMAND contains "/usr/lib/cyrus/bin/deliver -a $USER -q -m"
and
$Destination contains something like "user.SLE"
which all tells *Cyrus* what to do with the message.
The reason for all this is that I'm *accessing* my mail through (Cyrus) IMAP only. And Cyrus takes care of all the 'housekeeping', including where to put the actual file in the filesystem, and subsequent manipulations like moving msgs around and deleting them and so on.
Under this scheme each message is still just a file, but *I* don't own it, *Cyrus* does. And in fact *I* (the user) haven't got read-priviliges in the area where Cyrus keeps the messages (/var/spool/imap/user/)
And so:
Unless you have some sort of MDA to take care of final delivery, you probably don't want to pipe anything anywhere.
Just let Procmail write the file in your ~/Mail/inbox/new - or wherever Kmail expects to see new messages (I don't know. I haven't used Kmail in quite a while, and never like that...)
Hope I'm not confusing you with all this, but it seemed prudent to explain why I'm using pipes, and why it might not be appropriate for you
/Jon
-- Just say "know!"
I appreciate the detailed explanation! I think I understand a little better. -- "Yogi" CH Namaste Yoga Studio
C wrote regarding 'Re: [SLE] procmailrc' on Sun, Oct 03 at 10:18: [...]
Pipes is something I need to understand better than I do. I use simple pipes (like | less & | grep <item>) w/o totally understanding how they work. Guess I'll ry this example & see what happens. :-)
A pipe just connects stdout of the left process to stdin on the right process, so the right process essentially reads what the left process writes.
(While we're on the subj... I was hopig to also get the process using Mailder rather than mbox, and putting msgs in KMail's inbox, etc. Had it working, once, then it busted & I don't know what I did. Guess that's another post; right?)
To use Maildir instead of mbox in procmail, just put a slash on the end of the target mailbox name. Procmail will magically use maildir, then. Incidentally, I use: # Suse-linux-english list :0 * ^[sS]ubject:.*\[SLE\] .lists.suse/ I probably oughtta filter on the header, but this way I get any personal responses stuck into the list folder, too. It keeps my inbox cleaner, and makes context easier to follow. :) --Danny
On Monday 2004 October 4 17:21, Danny Sauer wrote:
To use Maildir instead of mbox in procmail, just put a slash on the end of the target mailbox name. Procmail will magically use maildir, then.
Incidentally, I use:
# Suse-linux-english list
:0
* ^[sS]ubject:.*\[SLE\] .lists.suse/
I probably oughtta filter on the header, but this way I get any personal responses stuck into the list folder, too. It keeps my inbox cleaner, and makes context easier to follow. :)
--Danny
Noted! Thanks, Danny! -- "Yogi" CH Namaste Yoga Studio
* Danny Sauer <suse-linux-e.suselists@danny.teleologic.net> [10-04-04 12:21]:
Incidentally, I use:
# Suse-linux-english list :0 * ^[sS]ubject:.*\[SLE\] .lists.suse/
you might want to revise as case is ignored by default: :0 *Subject:.*\[SLE\] .lists.suse/ -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos
On Monday 2004 October 4 18:31, Patrick Shanahan wrote:
* Danny Sauer <suse-linux-e.suselists@danny.teleologic.net> [10-04-04 12:21]:
Incidentally, I use:
# Suse-linux-english list
:0
* ^[sS]ubject:.*\[SLE\] .lists.suse/
you might want to revise as case is ignored by default: :0
*Subject:.*\[SLE\] .lists.suse/
-- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos Thanks to you, as well, Patrick! -- "Yogi" CH Namaste Yoga Studio
Patrick wrote regarding 'Re: [SLE] procmailrc' on Mon, Oct 04 at 13:32:
* Danny Sauer <suse-linux-e.suselists@danny.teleologic.net> [10-04-04 12:21]:
Incidentally, I use:
# Suse-linux-english list :0 * ^[sS]ubject:.*\[SLE\] .lists.suse/
you might want to revise as case is ignored by default:
:0 *Subject:.*\[SLE\] .lists.suse/
Oh yeah, thanks. I spend most of my time in perl, and get confused when there's no /i at the end of regexps. :) --Danny, same old dog, same old tricks
The 2004-10-04 at 12:21 -0500, Danny Sauer wrote:
Incidentally, I use:
# Suse-linux-english list :0 * ^[sS]ubject:.*\[SLE\] .lists.suse/
I probably oughtta filter on the header, but this way I get any personal responses stuck into the list folder, too. It keeps my inbox cleaner, and makes context easier to follow. :)
Mine is more complex. I end up with three mbox folders: $HOME/Mail/lists/suse-linux-e SLE emails only. $HOME/Mail/lists/in_dups duplicated emails (CCed) $HOME/Mail/lists/in_elresto direct emails. Therefore, the suse-linux-e mbox contains only email that was sent from SuSE server, not direct email or CCed to me. I have it as follows: * ^Original-Recipient: rfc822;robin1.listas.... { :0f * ^X-Mailinglist: suse-linux-e | /usr/bin/formail -bfi "Reply-To:suse-linux-e@suse.com" :0 a $HOME/Mail/lists/suse-linux-e # some other suse lists here ... # Move CCed mails elsewere :0 * ^TO_suse-linux-s@suse.com $HOME/Mail/lists/in_dups # repeat rule for other lists ... # The rest (direct mail) :0 $HOME/Mail/lists/in_elresto } The formail rule is for adding a local Reply-To header, so that Pine and Mozilla works. -- Cheers, Carlos Robinson
participants (8)
-
Bruce Marshall -
C Hamel -
Carlos E. R. -
Danny Sauer -
Jon Clausen -
Patrick Shanahan -
rkimber＠ntlworld.com -
Scott Leighton