Subject: Can MATCH do this?

From: [email-masked] (Mark J. Bynum)
Date: Thu, 27 Apr 1995 13:33:42 -0400 (EDT)

I am on several mailing lists related to freebsd and I subscribe and
to new freebsd related mailing lists often. What I would like to do
is to have one rule in my procmailrc that would, given the appropriate
Sender line, hack it up and save it to freebsd-<listname>. For example,
mail with each of these different lines in the header:

Sender: [email-masked]
Sender: [email-masked]
Sender: [email-masked]

would get stored to:

freebsd-announce
freebsd-hardware
freebsd-hackers

Can MATCH do this?  I read the docs and it said MATCH would save the RHS
of what is was given, but I don't want the whole right hand side.  Hopefully
this can be done dynamically so that everytime I subscribe to a new freebsd
list (all from the same place) I won't have to go in and modify my procmailrc.

Thanks,

Mark Bynum

---

From: [email-masked] (Stephen R. van den Berg)
Date: Thu, 27 Apr 1995 20:50:05 +0200

>Sender: [email-masked]

What about:

	:0:
	* ^Sender: \/[a-z][email-masked]
	* MATCH ?? \/[a-z]+
	freebsd-$MATCH

Careful, though.  Case is preserved in MATCH.

-- 
Sincerely,                                  [email-masked]
           Stephen R. van den Berg (AKA BuGless).

"Be spontaneous!"

---

From: [email-masked] (David W. Tamkin)
Date: Thu, 27 Apr 1995 15:36:34 -0500 (CDT)

Stephen van den Berg suggested to Mark Bynum,

| What about:
| 
| 	:0:
| 	* ^Sender: \/[a-z][email-masked]
| 	* MATCH ?? \/[a-z]+
| 	freebsd-$MATCH

I haven't had much luck getting a later condition in a recipe to understand
a value of MATCH set in an earlier condition of that recipe.  This, though,
has worked for me, but it depends on there being no other Sender: headers
before the one from [email-masked] and runs the internal egrep engine
over the headers twice:

  :0:
  * ^Sender:[email-masked]
  * ^Sender: \/[a-z]+
  freebsd-$MATCH

This variant is rock solid and doesn't go to the extra work of rereading the
whole head, but it may not satisfy Mark's esthetic preference for "one rule":

  :0
  {
   :0:
   * MATCH ?? ^^\/[a-z]+
   freebsd-$MATCH
  }

The second condition may also be written as
* MATCH ?? \\/[a-z]+ or
* MATCH ?? .*\/[a-z]+
and [^-]+ may be substituted for [a-z]+ in case a future FreeBSD list
has a digit in its name.

---

From: [email-masked] (Gardner Cohen)
Date: Fri, 28 Apr 1995 17:45:38 -0700

David W. Tamkin wrote:

     :0:

   This variant is rock solid and doesn't go to the extra work of
   rereading the whole head, but it may not satisfy Mark's esthetic
   preference for "one rule":

     :0

I subscribe to a bunch of mailing lists that I convert into MH folders
(for use with gnus in mixspool mode; of course, I should be looking
into ding-gnus).

I have a file .groupmap that looks like this:

[email-masked]	lists/bikes/logistics
[email-masked]	lists/bikes/current
[email-masked]	lists/bikes/commute
[email-masked]	lists/procmail
[email-masked]	lists/procmail-announce
filmfest-owner@				lists/sfiff
owner-volcano@				lists/volcano
(40 or so other lines elided)

and have this grotesque section in .procmailrc.  I key off of the
envelope address, which is usually enough to uniquely identify mailing
lists, and deals with a large set of lists that don't use Sender:, or
X-Sender:, or X-Mailing-List:, etc.  There's extra processing to
remove (often nonunique) source route addresses that tend to creep
into bitnet mailing lists,
e.g. @uga.cc.uga.edu:[email-masked]

I can add most new lists by simply adding a line to the .groupmap
file; ones that defy the -owner- or -request- lines require modifying
the final regexp as well as adding a .groupmap line.

I'd be interested in hearing if there are more efficient ways to
accomplish this, but I'm not currently worried about the time my
workstation spends dispatching the messages that match these
conditions.  I hope this is reasonably efficient since the only header
examined (envelope) is checked only once, and uses ^^ for further
efficiency.

# generic processing of lists using a mapping file and envelope addresses
# extract address from <> if the envelope has it
# skip @thing: part
# look for owner-whatever
# look for whatever-owner
# look for whatever-request
# look for other dedicated list names that defy convention.
:0
* ^^From +\/[^ 	]+
{
	# I couldn't construct a regexp that would skip a leading '<'
	# with a source route and still MATCH the real address part,
	# so it's a lot easier to do this with cascading conditional
	# assignments.
	ADDRESS=$MATCH
	# strip leading <
	:0
	* ADDRESS ?? ^<\/.*$
	{
	   ADDRESS=$MATCH
	}
	# strip leading source route @domain.address:
	:0
	* ADDRESS ?? ^@[^:]+:\/.*$
	{
	   ADDRESS=$MATCH
	}
	# strip everything after @ or %, tack on an @
	:0
	* ADDRESS ?? ^\/[^%@]+
	{
	  ADDRESS=$MATCH@
	}
	# look up appropriate addresses in the .groupmap file
	:0
	* ADDRESS ?? ^(dispatch|depress|Caryl\.Johnson|sndprint|fab-ufo|owner-[^%@]+|[^%@]+-(request|owner))[%@]
	{
		LIST=`grep -i $ADDRESS $HOME/.groupmap|head -1`

		:0
		* LIST ??[^ 	]+[ 	]+\/[^ 	]+$
		.spool/$MATCH/.
	}
}

---

From: [email-masked] (Mark J. Bynum)
Date: Fri, 28 Apr 1995 21:42:28 -0400 (EDT)

> whole head, but it may not satisfy Mark's esthetic preference for "one rule":
Okay, maybe not one rule. Just so that is doesn't grow for every FreeBSD list
I subscribe to.

>    * MATCH ?? ^^\/[^-]+
procmail: Assigning "MAILDIR=/home/cs36/bynum/Mail/incoming"
procmail: Assigning "MATCH="
procmail: Matched "[email-masked]"
procmail: Match on "^Sender: \/[a-z][email-masked]"
procmail: [18370] Thu Apr 27 19:58:47 1995
procmail: No match on "\/[a-z]+"

Didn't work (sorry Stephen), it goes to the default mailbox.  Now on to
David's suggestion. I used the one that enabled future use for FreeBSD groups
that have letter in them. Like so:

	* MATCH ?? .*\/[^-]+
	freebsd-$MATCH
}

Here is the log:

procmail: Assigning "MAILDIR=/home/cs36/bynum/Mail/incoming"
procmail: Assigning "MATCH="
procmail: [9759] Fri Apr 28 18:35:04 1995
procmail: Matched "[email-masked]"
procmail: Match on "^Sender: \/[a-z][email-masked]"
procmail: Locking ".lock"
procmail: Error while writing to "/_UO2Gnu"
procmail: Error while writing to "/"
procmail: Unlocking ".lock"
procmail: Skipped "* MATCH ?? .*\/[^-]+"
procmail: Skipped "freebsd"
procmail: [9759] Fri Apr 28 18:35:05 1995
procmail: Skipped "-$MATCH"

Errors? These errors happen every time this rule is matched. I have no idea
what they mean. It seems that procmail is trying to write to the root
directory which of course it can't do. Any suggestions?

Besides, here is my entire .procmailrc:

# Please check if all the paths in PATH are reachable, remove the ones that
# are not.

PATH=$HOME/bin:$HOME/bin/sun4:/usr/bin:/usr/ucb:/bin:/usr/local/bin:.
MAILDIR=$HOME/Mail	# You'd better make sure it exists
DEFAULT=/usr/spool/mail/bynum
LOGFILE=$MAILDIR/from
LOCKFILE=$HOME/.lockmail
VERBOSE=yes
LOGABSTRACT=all
SHELL=/bin/sh

:0 Wh: msgid.lock
| formail -D 8192 msgid.cache

#### Mailing list operations

MAILDIR=$HOME/Mail/incoming	# You'd better make sure it exists

#:0:				# Anything from freebsd questions lists
#* [email-masked]
#freebsd-questions		# will go to $MAILDIR/freebsd-questions

#:0:				# Anything from freebsd hackers list
#* [email-masked]
#freebsd-hackers			# will go to $MAILDIR/freebsd-hackers

:0
* ^Sender: \/[a-z][email-masked]
{
	:0:
	* MATCH ?? ^^\/[a-z]+	
#	* MATCH ?? .*\/[^-]+    #does not work error while writing to "/"
	freebsd-$MATCH
}

#The condition may also be written as
#* MATCH ?? \\/[a-z]+ or
#* MATCH ?? .*\/[a-z]+
#and [^-]+ may be substituted for [a-z]+ in case a future FreeBSD list

:0				# Anything from trumpet.com.au
* (^Path|^From).*trumpet.com.au
{
	:0:                             # trumpet-test
	* ^Newsgroup.*trumpet.test
	trumpet.test

	:0:                             # trumpet-announce
	* ^Newsgroup.*trumpet.announce
	trumpet.announce

	:0:                             # trumpet-feedback
	* ^Newsgroup.*trumpet.feedback
	trumpet.feedback

	:0:                             # trumpet-bugs
	* ^Newsgroup.*trumpet.bugs
	trumpet.bugs

	:0:                             # Anything else from trumpet
	trumpet.questions
}

:0:				# Anything from/to procmail
* (^From|^Cc:|^To)[email-masked]
procmail			# will go to $MAILDIR/procmail

# Anything that has not been delivered by now will go to $DEFAULT
# using LOCKFILE=$DEFAULT$LOCKEXT

---

From: Brock Rozen <[email-masked]>
Date: Fri, 28 Apr 1995 20:38:56 -0700 (PDT)

Well,

What I do for my mailing lists is find what identifies THEM uniquely. I 
have some that use the SUBJECT line and some that use the TO line. Since 
you have to add each mailing list manually, this process shouldn't be so 
bad. Look at my rc file:

      	:0:              
      	* ^Subject: .*Israel Line    
      	Israel/News               

	:0:
	* ^Subject: .*backpage:
	Israel/News

        :0:
        * ^Subject: .*newsflash:
        Israel/News

	:0:
	* ^Subject: .*flashes:
	Israel/News
	
        :0:
        * ^Subject: .*Conference:
        Israel/News

	:0:
	* ^Subject: .*surveys:
	Israel/News
     	
	:0:
     	* ^TOShomronNews
	Israel/Shomron\ News\ Service
	
	:0:
	* ^TObetar
	Israel/Betar

	:0:
	* ^TOtagar
	Israel/Betar

	:0:
	* ^TOtalknow
	Israel/Talk\ Now

	:0:
	* ^TOsalaam-v-shalom
	Israel/Talk\ Now
	
	:0:
	* ^Subject: .*yesha news service
	Israel/Yesha\ News\ Service

I've distinguished between those with TO and those with Subject, 
depending on how the list is setup. Each list takes up three lines, and 
according to what mailbox they go into (this is my Israel mailbox, I have 
three others) I create a seperate .rc file to keep each one cut down and 
organized.

  ------------------------------------------------------------------------
  |  Brock Rozen  | InterNet: [email-masked]             |
  |               | CompuServe: 71614,240                                |
  |               | ImagiNation: 1304 & 148501                           |
  |----------------------------------------------------------------------|
  | For automated information on various subjects, send an e-mail to my  |
  |        InterNet address with SEND HELP on the Subject line.          |
  ------------------------------------------------------------------------

---

From: [email-masked] (David W. Tamkin)
Date: Sat, 29 Apr 1995 13:50:48 -0500 (CDT)

Mark Bynum wrote,

| Here is the log:
| 
| procmail: Assigning "MAILDIR=/home/cs36/bynum/Mail/incoming"
| procmail: Assigning "MATCH="
| procmail: [9759] Fri Apr 28 18:35:04 1995
| procmail: Matched "[email-masked]"
| procmail: Match on "^Sender: \/[a-z][email-masked]"
| procmail: Locking ".lock"
| procmail: Error while writing to "/_UO2Gnu"
| procmail: Error while writing to "/"
| procmail: Unlocking ".lock"
| procmail: Skipped "* MATCH ?? .*\/[^-]+"
| procmail: Skipped "freebsd"
| procmail: [9759] Fri Apr 28 18:35:05 1995
| procmail: Skipped "-$MATCH"
| 
| Errors? These errors happen every time this rule is matched. I have no idea
| what they mean. It seems that procmail is trying to write to the root
| directory which of course it can't do. Any suggestions?

| Besides, here is my entire .procmailrc:

 ...

| :0
| * ^Sender: \/[a-z][email-masked]
| {
| 	:0:
| 	* MATCH ?? ^^\/[a-z]+	
| #	* MATCH ?? .*\/[^-]+    #does not work error while writing to "/"
| 	freebsd-$MATCH
| }

You tried to put a comment line into the middle of a recipe; that won't
be supported until version 3.11.  Procmail assumed that <nothing># meant
the same as <nothing> on an action line, which is to say, save to a file
in /.  It couldn't do that, so it went on.  As the first line after a 
recipe ends, "freebsd-$MATCH" makes no sense (it is neither the colon-flagged
start of a new recipe nor a variable assignment), so procmail skipped that.

Maybe part of the problem is trying to rematch on $MATCH.  Try this:

 :0
 * ^Sender: \/[a-z][email-masked]
 {
   LONGNAME=$MATCH # note, that's LONGNAME with two N's

   :0:
   * LONGNAME ?? ^^\/[a-z]+
   freebsd-$MATCH
 }