Subject: filtering

From: [email-masked] (Darci Chapman, Paradise Cowgirl x5930)
Date: Fri, 25 Mar 1994 13:09:54 -0800

Hello, all!

First, I want to publicly thank all of you who have written in response
to my queries about Reply-To: lines, impad problems, etc. You all are 
definitely a helpful bunch! 

So, I know that recently I either read somewhere in the pine documentation
or on this list that while filtering within pine is not built-in, there 
are ways to do it: procmail or ??? 

I'm a currently zmail user, subscribe to (too) many lists and run several
lists; I'm really going to need some way of filtering all my incoming
mail, even if it means downloading my entire remote inbox and then doing
it locally.

Reccommendations, anyone?

Thanks again!

>>-Darci->

-- 
------     Darci L. Chapman   -   Northwest Natural Gas   -   [email-masked]
\  --/---                Boycott Rush Limbaugh oranges!
 \ \/   /Don't support discrimination and bigotry -- don't support the OCA! 
  \/\  / (I do not speak for the Gas Company, and They do not speak for Me)    
     \/ <a href="http://vector.casti.com/QRD/.html/People/Darci">About Me</a>
"What would happen if the far right held a campaign and nobody came?" -Lee Lynch

---

From: David L Miller <[email-masked]>
Date: Fri, 25 Mar 1994 14:00:47 -0800 (PST)

Darci,

Personally, I use "filter" from the Elm distribution.  It is pretty easy to
get working and does what I need fairly well.  Procmail is more powerful, but
it does come at a price of more cryptic syntax.  Deliver is another
possibility, but I haven't looked at it very much.  All of these programs 
divert the incoming messages before final delivery, so there should not 
be any extra downloading.

I hope that helps!

--DLM

|\ |  |\/|  David L. Miller    [email-masked]  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing, JE-20
4545 15th Ave NE, Seattle WA 98105, USA

---

From: Ed Greshko <[email-masked]>
Date: Sat, 26 Mar 1994 09:42:23 +0800 (TPE)

> are ways to do it: procmail or ??? 

	The two methods that come to mind are "procmail" and "filter".
The "filter" program comes as part of the "elm" distribution.  Both
of them function is similar fashion.  That is, you make an entry in
your .forward like, "|/usr/lbin/filter".  Then, based on a set of
rule you've defined you mail is delivered to the appropriate folder,
or fed to another process, or deleted if that's what you want.

	The rule language of "procmail" is more flexible.  It allows
for chaining rules.  I'd started out using "filter" and still do...
mostly since I don't really need the flexibility of "procmail".
That, and I too busy (read lazy) to change.  Had I started with procmail...
I don't think I would consider changing to "filter".

					Regards,
						Ed
 
Edward M. Greshko			Control Data Taiwan
Voice: +886-2-715-2222 x287		6/F, 131 Nanking East Road, Section 3
FAX  : +886-2-712-9197			Taipei, Taiwan R.O.C

---

From: [email-masked] (Jay Schuster)
Date: Fri, 25 Mar 94 23:41:51 EST

> are ways to do it: procmail or ??? 

We run deliver here.  I like deliver over other choices because it uses
scripts to determine where the mail goes, and not `yet another
configuration language'.  Of course, that same reason can make it
unfriendly to novice users (who wouldn't have a very hard time learning
just enough sh to get simple stuff working).

-- 
Jay Schuster <[email-masked]>	uunet!uvm-gen!banzai!jay, attmail!banzai!jay
The People's Computer Company	`Revolutionary Programming'

---

From: "Robert A. Hayden" <[email-masked]>
Date: Sat, 26 Mar 1994 00:15:20 -0600 (CST)

I'm wondering if it might be possible (and don't hit too hard) for future 
versions of pine to include filter with it.

Here's why.  Many sites have chosen pine over elm as their mail reader.  
So when someone says "we shoudl install this program even though it comes 
with elm", there can be a lot of administrative headaches.

If it came with pine, it would be all considered "one package" and would 
get installed without each student having to find filter (archiing for 
filter won't help) compile the whole elm set, and install the program in 
their private account.

Just a quick thought at some ingodly AM hour.

____        Robert A. Hayden          <=> [email-masked]
\  /__          -=-=-=-=-             <=>          -=-=-=-=-
 \/  /   Finger for Geek Code Info    <=> Political Correctness is
   \/  Finger for PGP 2.3a Public Key <=> P.C. for "Thought Police"
-=-=-=-=-=-=-=-
(GEEK CODE 1.0.1)  GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
		       n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)

---

From: David L Miller <[email-masked]>
Date: Sat, 26 Mar 1994 08:33:55 -0800 (PST)

Robert,

This is certainly worth some consideration.  Here are some thoughts:

	o Filter is certainly simpler than procmail, but is it simple
	  enough for Pine's primary target audience (the very novice)?

	o How much extra customer support overhead would it generate?

	o Filter only supports the Berkeley mailbox format.  This could
	  be a severe limitation for sites and users preferring other 
	  formats.

Discussion?

--DLM

---

From: [email-masked] (Bill Campbell)
Date: Sat, 26 Mar 1994 09:24:15 -0800 (PST)

>     enough for Pine's primary target audience (the very novice)?
I would suggest looking at Chip Salzenberg's deliver program.  This is
much simpler for the novice to use than deliver.  Each user can put a
program in $HOME/.deliver that determines the disposition of each
incoming mail message.  The program can be anything from a simple
shell script 'echo $user' to an arbitrarily complex program.

Deliver usually receives the mail through a .forward or alias of the
form: "|/usr/lib/mail/deliver usrname" (deliver gets very picky if
usrname is root and runs at sub-root priviledges).  It has separated
the message into two files, $HEADER, and $BODY, and set several
environment variables with useful things like sender and destination
addresses.  It also provides a utility function to select specified
headers from a file easily using expressions like:
    dests=`header -f to -f apparently-to -f cc $HEADER`

The user program communicates with deliver via standard output with
simple things like:
    echo $user          # deliver to the user's normal mailbox.
    echo DROP           # deep six this mail.
    echo $mailpath      # deliver to an arbitrary mail address
    echo $user:filename # store in a specific mailbox file.

The .deliver program can do anything it wants beyond this.  I use it
to filter mailing-list traffic by comparing incoming Message-Id with a
history file to eliminate duplicates, then to archive the traffic by
mailing list name.  Traffic other than mailing lists is archived by
system/user.

>   o How much extra customer support overhead would it generate?
Probably a lot less than a program like filter since the .deliver
program is usually a shell script or perl program so the user doesn't
have to learn a new language.

>     be a severe limitation for sites and users preferring other
Deliver understands Berkeley and mmdf.

Bill
--
INTERNET:  [email-masked]   Bill Campbell; Celestial Software
UUCP:              camco!bill   8545 SE 68th Street
FAX:           (206) 232-9186   Mercer Island, WA 98040; (206) 947-5591

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 26 Mar 1994 18:53:51 +0100 (MET)

> 	  enough for Pine's primary target audience (the very novice)?

No.  Not least because it doesn't really work.  Its man page lists
capabilities it doesn't have, and some things are buggy (at least I ran
into trouble trying to use "contains" rules and the syntax didn't seem to
be as flexible as the man page said).  I use filter, but I say "filter -r"
every single time I change my setup at all.

--Arnt

---

From: "Robert A. Hayden" <[email-masked]>
Date: Sat, 26 Mar 1994 12:08:33 -0600 (CST)

> 	  enough for Pine's primary target audience (the very novice)?

I think it's simple enough.  There is no need to bother with crazy outside 
scripts like with procmail or deliver (thus, no need to even know HOW to 
make a script or learn Yet Another Scripting Language).  There is also a 
fairly complete filter refereance manual that comes with elm that could 
be included (doc/filter.guide or something like that in the elm 
distribution).  By placing that alongside the tech-notes (or, I suppose, 
building it into pine like the help system), you can get fairly complete 
documentation to the users.

Filtering isn't exactly a novice activity, but it doesn't have to be the 
programmers dream/nightmare that procmail or deliver is.

> 	o How much extra customer support overhead would it generate?

Some, but the well written guide could/should be pointed to first.  And 
advanced filter questions (setting up file servers, for example) could be 
pointed towards elm forums.

> 	  be a severe limitation for sites and users preferring other 

This is a problem, unfortunately with no easy solution.  
	A)  We could include filter and just warn people that it will
	only work with berkeley.  Perhaps pointing other systems to 
	procmail and/or deliver.  This is nice because pine is actually 
	saying "Here's a program you might find useful.  If not, here's 
	some other outside ones that may also work."  It points it out 
	as an only mildly supported program.

	B)  We could hack filter to work with others (could be icky)

	C)  We could write up our own filter program with the simplicity 
	of filter and the ability to handle other systems.  Nice, but 
	time consuming and the pine people probably have better things
	to do.

---

From: "Robert A. Hayden" <[email-masked]>
Date: Sat, 26 Mar 1994 12:12:25 -0600 (CST)

> shell script 'echo $user' to an arbitrarily complex program.

But that assumes that the users know how to even write that simple shell 
script.

We have to remember that we are moving into the age of communications, 
where people utilize these computer systems not to program, but to talk.  
Many don't know the first thing about shell scripts or other forms of 
programming.  Their only goal is to read and write information among 
themselves.

Filter, while being limited, has the benefit of the fact that it is also 
very easy to implement (granted, it isn't newbie stuff, but it also 
doesn't require any time to learn scripting techniques and the like)/