[comp.mail.uucp] Smail, Aliases & Programs

chris@vision.UUCP (Chris Davies) (10/20/89)

Smail 2.5, patchlevel 0, running with ELM as a front-end, on Altos Unix (AT&T
derived) Sys V.3.something.

I quote from the manual page for aliases(8):
-->     NAME
-->          aliases - alias file for smail
-->
...[stuff deleted]...
-->
-->          One difference between smail and sendmail is that smail
-->          doesn't handle stuff like mail to files or command
-->          execution.
-->
-->     VERSION
-->          @(#)aliases.8  2.5 (smail) 9/15/87

What I need (!!), before we start running smail instead of a brain-damaged and
hacked-around version of uumail, is a version of smail for Unix System V.3
which *will* allow me to create aliases of the form

	info-server	| /some/program/or/other

i.e. to have mail piped to a specified program.

Before I start (trying...) to hack the source around, has anyone already done
this?  If so, please let me know as I'd really like your modifications!!  :-)

No flames please.  If you lot out there know something that I don't, I really
would like to be told (and "why doesn't the manual page tell me so!!??")...

		Many thanks,
			Chris

PS.	Is smail 2.5 PL0 the most recent version/patch?
-- 
VISIONWARE LTD           | UUCP:     chris@vision.uucp
Leeds Business Park      | JANET:    chris%vision@uk.ac.ukc
Bruntcliffe Lane	 | BANGNET:  ...!mcsun!ukc!vision!chris
Morley, LEEDS LS27 0JG	 | VOICE:    +44 532 529292
England			 | FAX:      +44 532 526614     TELEX:  556283 SYSTIM G
----------------- "You call these opinons? Not VisionWare's!" -----------------

tp@mccall.uucp (10/24/89)

> What I need (!!), before we start running smail instead of a brain-damaged and
> hacked-around version of uumail, is a version of smail for Unix System V.3
> which *will* allow me to create aliases of the form
> 
> 	info-server	| /some/program/or/other

I've been on VMS for several years now, so I no longer have it lying
around, but what I did (using an earlier version of smail that didn't have
aliases at all) was rather than renaming smail to rmail and handing it the
mail directly, I wrote a shell script named rmail. It looked at its
parameter and checked it against an alias list. If it was found, it would
look to see if the first character of the alias was a pipe, and if so, exec
the appropriate program (remember the mail message itself is on stdin, so
execing the program would pass the message in to stdin of that program). I
also had it handling simple aliases and lists of aliases. If the alias
matched, but was not a pipe, it simply invoked smail with the alias names,
rather than the argument received. Finally, if the address is not an alias,
it simply exec'ed smail.
-- 
Terry Poot (800)255-2762, in Kansas (913)776-3683
The McCall Pattern Company, 615 McCall Rd., Manhattan, KS 66502, USA
UUCP: rutgers!ksuvax1!mccall!tp   Internet: tp%mccall@ksuvax1.cis.ksu.edu

chip@ateng.com (Chip Salzenberg) (10/25/89)

According to chris@vision.UUCP (Chris Davies):
>Smail 2.5, patchlevel 0, running with ELM as a front-end, on Altos Unix
>(AT&T derived) Sys V.3.something.
>
>What I need (!!), before we start running smail instead of a brain-damaged
>and hacked-around version of uumail, is a version of smail for Unix System
>V.3 which *will* allow me to create aliases of the form
>
>	info-server	| /some/program/or/other
>
>i.e. to have mail piped to a specified program.

Get the Deliver program.  Version 2.0 recently appeared in comp.sources.unix.
I wrote it to provide exactly the facility you want in the environment you
have.  But when you install Deliver you get lots more than just pipes.
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
"'Why do we post to Usenet?'  Naturally, the answer is, 'To get a response.'"
                        -- Brad "Flame Me" Templeton

bdb@becker.UUCP (Bruce Becker) (10/25/89)

In article <590@piglet.vision.UUCP> chris@vision.UUCP (Chris Davies) writes:
|[...]
|What I need (!!), before we start running smail instead of a brain-damaged and
|hacked-around version of uumail, is a version of smail for Unix System V.3
|which *will* allow me to create aliases of the form
|
|	info-server	| /some/program/or/other
|
|i.e. to have mail piped to a specified program.
|
|Before I start (trying...) to hack the source around, has anyone already done
|this?  If so, please let me know as I'd really like your modifications!!  :-)

	There is indeed a patch to smail 2.5 which permits
	this.  I'll try to persuade the author to allow it
	to be posted here.  I'm using it currently...

Cheers,
-- 
  ....	 Bruce Becker	Toronto, Ont.
w \**/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `/C/-e	 BitNet:   BECKER@HUMBER.BITNET
_/  >_	 "But... but.. reality isn't *real*..." - Pippy the Zkinhead

chip@ateng.com (Chip Salzenberg) (10/25/89)

According to tp@mccall.uucp:
>> 	info-server	| /some/program/or/other
>
>[...] what I did (using an earlier version of smail that didn't have
>aliases at all) was rather than renaming smail to rmail and handing it the
>mail directly, I wrote a shell script named rmail. It looked at its
>parameter and checked it against an alias list.

If anyone else is thinking of doing such a thing, be sure that the script
can handle _multiple_ parameters.  To support this necessary feature, the
script will have to copy the message to a temporary file, since it may be
fed to several different programs.

That's what Deliver does.  (You saw it coming, didn't you?)
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
"'Why do we post to Usenet?'  Naturally, the answer is, 'To get a response.'"
                        -- Brad "Flame Me" Templeton

chip@ateng.com (Chip Salzenberg) (10/26/89)

According to bdb@becker.UUCP (Bruce Becker):
>In article <590@piglet.vision.UUCP> chris@vision.UUCP (Chris Davies) writes:
>|What I need (!!) [...]
>|	info-server	| /some/program/or/other
>|i.e. to have mail piped to a specified program.
>
>	There is indeed a patch to smail 2.5 which permits
>	this.  I'll try to persuade the author to allow it
>	to be posted here.  I'm using it currently...

Remember security, people.  Do you always want all pipe aliases to be run
as uucp or root?  Think about it...
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
"'Why do we post to Usenet?'  Naturally, the answer is, 'To get a response.'"
                        -- Brad "Flame Me" Templeton

zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/27/89)

>|i.e. to have mail piped to a specified program.
>|
>	There is indeed a patch to smail 2.5 which permits
>	this.  I'll try to persuade the author to allow it


If you care about security, don't use it.  Use deliver or the lmail that
I wrote.


-- 
Branch Technology  <zeeff@b-tech.ann-arbor.mi.us>

jv@mh.nl (Johan Vromans) (10/28/89)

In article <590@piglet.vision.UUCP> chris@vision.UUCP (Chris Davies) writes:

Chris> What I need (!!) [...]
Chris>	info-server	| /some/program/or/other
Chris> i.e. to have mail piped to a specified program.

According to bdb@becker.UUCP (Bruce Becker):

Bruce> There is indeed a patch to smail 2.5 which permits
Bruce> this.  I'll try to persuade the author to allow it
Bruce> to be posted here.  I'm using it currently..

In article <254733A5.10634@ateng.com> chip@ateng.com (Chip Salzenberg) writes:

Chip> Remember security, people.  Do you always want all pipe aliases to be run
Chip> as uucp or root?  Think about it...

In article <9687@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:

Jon> If you care about security, don't use it.  Use deliver or the lmail that
Jon> I wrote.

Are you all talking about the same patch to Smail2.5? I know several of
them (some of them are insecure, others aren't).

Johan
--
Johan Vromans				       jv@mh.nl via internet backbones
Multihouse Automatisering bv		       uucp: ..!{uunet,hp4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands  phone/fax: +31 1820 62944/62500
------------------------ "Arms are made for hugging" -------------------------

david@ms.uky.edu (David Herron -- One of the vertebrae) (10/29/89)

In article <254733A5.10634@ateng.com> chip@ateng.com (Chip Salzenberg) writes:
>According to bdb@becker.UUCP (Bruce Becker):
>>In article <590@piglet.vision.UUCP> chris@vision.UUCP (Chris Davies) writes:
>>|What I need (!!) [...]
>>|	info-server	| /some/program/or/other
>>|i.e. to have mail piped to a specified program.
...
>Remember security, people.  Do you always want all pipe aliases to be run
>as uucp or root?  Think about it...
...

Yes, indeed.

MMDF has the syntaxes

	name:	user-name|command		for pipes
	name:	user-name//path			for files

in its alias files.  That feature had been there for a looooong time.
I had suggested it to the authors of v2.5 and they liked it, but I
don't know if the ifnroamtion for passed on to the v3 authors.  Nor do
I know when v3+ will be appearing anywhere.
-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- 
<- New official address:  attmail!sparsdev!dsh@attunix.att.com

chip@ateng.com (Chip Salzenberg) (10/31/89)

According to david@ms.uky.edu (David Herron -- One of the vertebrae):
>MMDF has the syntaxes
>
>	name:	user-name|command		for pipes
>	name:	user-name//path			for files
>
>in its alias files.  That feature had been there for a looooong time.

I like that syntax.  Of course, it's similar to deliver's, at least in
the file part.

Smail 3 typically runs pipe and file aliases in the context of the "owner"
of the alias file.  The owner is determined by the mail admin when Smail is
configured to use that file.  By the way, each user's ".forward" file is
owned by that user.
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
"'Why do we post to Usenet?'  Naturally, the answer is, 'To get a response.'"
                        -- Brad "Flame Me" Templeton

bill@twwells.com (T. William Wells) (11/13/89)

(A note to Jon Zeef: we seem to have problems communicating via
e-mail; umich or somebody around there has got some serious
problems. I've appended the headers from the bounce to this
message. I'm guessing that you can get them directed to whoever
should deal with them. Anyway, you seem to be able to send me
e-mail OK. Here's the question: I've received a request or two to
beta lmail, would you mind if I sent it off to them? And, did you
get those patches I sent?)

In article <14858@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
: I find Deliver to be plenty small and efficient, myself -- and shell
: scripts can be just as easy to install for the semi-casual user as any
: other type of program.

Well, this all depends on your point of view. Personally, I'd find
maintaining my mailing list using deliver's mechanisms a bit of a
bother. Whereas, with lmail, all I do is add a name to a list.

On the other hand, I suppose I could easily enough construct a
shell to read a file of names and run it into xargs or somesuch;
the point is that, with lmail, that kind of thing is already dealt
with.

Limited functionality programs like lmail can have the advantage
that getting them to do their limited functions requires little
effort. On the other hand, if you want to go outside their
limits....

: That doesn't mean it's not also wonderful that 'lmail' exists, or that
: Bill hasn't done a good job.  We don't really need to snipe about it.  :-)

I truly hope that no one is taking my comparison of the two
programs as sniping. But, in case anyone has, let me say this:
Deliver is a neat idea. Use it if it suits your needs.

: For what it's worth, it seems to me that the *truly* vanilla users don't
: need either program -- the vendor distributed mailers get the job done.
: It's at the moment where a user or admin pipes up and says "I wish I
: could do the following special thing with my mail..." that these added
: value programs come into their own.  When that happens, you *probably*
: have a user who can be trusted to play with shell scripts to suit his
: or her needs.

I could have used Deliver at the time, had I known of it. And then
I might not have worked on lmail. On the balance, I'd say we are
all better off: I have an lmail that does lots of useful things,
and there is also Deliver which also does lots of useful things.

: I know that for my mailing lists, the flexibility is an absolute godsend.

What sorts of things do you do with them that is out of the
ordinary? I'm sure both Chip and I would be interested in hearing
of features that would make people's lives easier.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

From novavax!uflorida!wuarchive!citi!umich!uucp Thu Nov  9 17:34:42 1989
Received: by twwells.com (smail2.5)
	id AA05547; 9 Nov 89 17:34:42 EST (Thu)
Received: by novavax.UUCP (smail2.5)
	id AA27582; 9 Nov 89 17:26:54 EST (Thu)
Received: by bikini.cis.ufl.edu (5.61ufl/2.30)
	id AA21357; Thu, 9 Nov 89 17:20:26 -0500
From: <uflorida!wuarchive!citi!umich!uucp>
Received: by mailrus.cc.umich.edu (5.61/gossip-1.1)
	id AA17682; Thu, 9 Nov 89 17:12:20 -0500
Received: by wuarchive.wustl.edu
	(5.61++/IDA-1.2.8) id AA11549; Thu, 9 Nov 89 16:06:42 -0600
Received: by mailrus.cc.umich.edu (5.61/gossip-1.1)
	id AA15605; Thu, 9 Nov 89 16:58:40 -0500
Message-Id: <8911092158.AA15605@mailrus.cc.umich.edu>
Date: 9 Nov 1989 16:51 EST
To: wuarchive!citi!wuarchive!uflorida!novavax!twwells!bill
Status: RO

remote execution        [uucp job umichC57d9 (11/9-16:51:16)]
	rmail b-tech!zeeff
exited with status 139


	===== stderr was =====
sh: 16679 Memory fault


	===== stdin was =====
>From wuarchive!uflorida!novavax!twwells!bill Thu Nov  9 16:57:04 1989 remote from citi
Received: by mailrus.cc.umich.edu (5.61/gossip-1.1)
	id AA15346; Thu, 9 Nov 89 16:57:04 -0500
Received: by wuarchive.wustl.edu
	(5.61++/IDA-1.2.8) id AA11421; Thu, 9 Nov 89 16:03:12 -0600
Received: by mailrus.cc.umich.edu (5.61/gossip-1.1)
	id AA15114; Thu, 9 Nov 89 16:55:21 -0500
Received: by bikini.cis.ufl.edu (5.61ufl/2.30)
	id AA20902; Thu, 9 Nov 89 17:02:01 -0500
Received: by novavax.UUCP (smail2.5)
	id AA13287; 9 Nov 89 06:09:00 EST (Thu)
Received: by twwells.com (smail2.5)
	id AA03048; 9 Nov 89 06:09:48 EST (Thu)
To: wuarchive!b-tech!zeeff
Subject: Re: Smail, Aliases & Programs
Date: 9 Nov 89 06:09:47 EST (Thu)
From: wuarchive!twwells.com!bill (T. William Wells)
Message-Id: <8911090609.AA03043@twwells.com>

bill@twwells.com (T. William Wells) (11/13/89)

In article <2558A19B.26552@ateng.com> chip@ateng.com (Chip Salzenberg) writes:
: According to bill@twwells.com (T. William Wells):
: >Deliver does much of its work by running shell scripts. Lmail
: >doesn't call anything external except to run commands on request
: >and to do remote mailing (and it batches remote addresses to
: >minimize the number of calls).
:
: Ah, yes.  Well, Deliver's design criteria did not include working well alone
: (though it can be done).  Deliver was intended for use with Smail 2, Smail 3
: or Sendmail.

That is also how I see lmail. But I also intended it to do as
much work as possible itself, because I'm an efficiency junkie.
:-)

: Perhaps more significant is that Deliver's use of shell scripts makes
: hacking your mail system much easier.  That ease of use is sometimes a
: more important win than efficiency.  For example:
:
:  o  Does your mailer not understand your network?
:
:     No problem; use Deliver to run the network's remote execution
:     program.  (Chip Rosenthal did this.)

I've been thinking of ways to do this with lmail, though my reason
has less to do with the structure of my local network as my desire
to have precise control of how my mail goes from here to there in
the global network.

As an example of this, I have a marked preference for storing
addresses as user@domain in my address lists. But this generally
means that my e-mail goes through uflorida, which manages to
munge the headers in such a way that certain sites can not read
it! So, what I want to do is to have mail destined for that site
be routed through uunet instead. Oh, I could fudge my pathalias
file, but that would really be a bear.

Instead, I'm thinking of adding stuff to lmail to let it do this,
so that I can just do simple configures and have it do what I
want.

The main reason I've not done this already is that I suspect that
to really do it right would mean reinventing sendmail. And that
is a slightly bigger job than I want to take on right now!

:  o  Do you want a mail to news gateway?
:
:     In the system delivery file, notice addresses that look like newsgroups;
:     hand those messages to the gateway program.  (I did this.)

This I can do easily enough. Just have aliases for the newsgroups
I want to gateway.

:  o  Want your mail delivered with a "Status:  O" header so your user agent
:     can tell which messages you haven't read?
:
:     No worries.  (Me again -- my user agent is Elm.)

Actually, I've had a slightly different interest: munging
outgoing mail headers. An example: if I mail to a local mailing
list, the To: line does not get a domain name. It works fine for
everyone else, of course!

This is a bug in my mailer, but it would be nice if someone
automatically appended the domain on outgoing mail. I could
probably fudge lmail to do this, but I suspect that smail is
really the right place.

: A note for you vaporware junkies:  Deliver 2.0 patch #2 will include
: logs for deliveries and errors.  The error log will include failed messages'
: headers.

Now _that's_ something I should be adding to lmail. Right now,
smail generates logging information, but that is not sufficient
for tracking mailing list stuff, which lmail handles.

: In conclusion:  I don't doubt that lmail can be more efficient than Deliver.
: But Deliver is no pig, either.  And the real question is, which is more
: valuable -- your computer's time, or yours?

The answer is "yes". :-)

Seriously. Over 80% of my waking hours are spent working with this
computer. Something that takes my computer's time takes *my* time.
And, of course, for my purposes, configuring lmail is simpler
than configuring Deliver would be. So, for *my* particular
purposes, I save time both ways. Your milage may differ. :-)

---

Hey, I just had a thought: there is little reason for me not to
add features that would permit easy integration of the two. I
could look for .deliver files in user's home directories and, if
found, run deliver for them instead of attempting normal delivery.

I have an alias bad-mail to which undeliverable mail is sent. The
way that works is this: just before returning a failure code to
(presumably) smail, I attempt mailing to bad-mail. This way I get
to see what kinds of bounces happen on my system. I could easily
add an alias, say try-mail, which is similar to this, except
that, if mail to try-mail succeeds, no error code is returned.
(Actually, that was the way I originally coded bad-mail, but I
found redirecting the mail overly onerous.)

One could modify the call to smail to call Deliver instead, if one
wanted remote mail to get processed by it as well. (For my uses,
I wouldn't: I'd assume that, once things got to the remote
address stage, all the important processing was already done. But
I expect others will have different purposes.)

The effect of all this would be that lmail would get first dibs
on the message and so, for the easy stuff, you get the advantages
of its efficiency and of its easy configurability. But for the
more complex stuff, Deliver gets to do its magic.

What do you think?

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

chip@ateng.com (Chip Salzenberg) (11/16/89)

According to bill@twwells.com (T. William Wells):
>According to chip@ateng.com (Chip Salzenberg):
>:  o  Do you want a mail to news gateway?
>:
>:     In the system delivery file, notice addresses that look like newsgroups;
>:     hand those messages to the gateway program.  (I did this.)
>
>This I can do easily enough. Just have aliases for the newsgroups
>I want to gateway.

Sure.  That's easy enough.  But what I meant by "notice" is to examine
the address and see if it looks like _a_ newsgroup:

    for u
    do
	case "$u" in
	news-*)
	    group=`echo $u | sed -e 's/^news-//' -e 'y/-/./'`
	    cat $HEADER $BODY | mailnews-gateway $group
	    echo DROP ;;
	*)
	    echo "$u" ;;
	esac
    done

As you can see, one routine handles _all_ newsgroups.

>Actually, I've had a slightly different interest: munging
>outgoing mail headers. An example: if I mail to a local mailing
>list, the To: line does not get a domain name.

Mm.  Not too hard.  In the system or post-user delivery file:

    for u
    do
	case "$u" in
	fake-mailing-list)
		( header -nvf To $HEADER
		  echo "To: real-mailing-list@mydomain"
		  echo ""
		  cat $BODY ) | smail -t
		echo DROP
		;;
	*)      echo "$u" ;;
	esac
    done

With this trick in place, you send mail to the fake-mailing-list.  Deliver
then mangles your mail header and hands the mangled message over to Smail,
which then delivers to real-mailing-list.

>: Which is more valuable -- your computer's time, or yours?
>The answer is "yes". :-)

I knew we could agree about something.  :-)

>Hey, I just had a thought: there is little reason for me not to
>add features that would permit easy integration of the two. I
>could look for .deliver files in user's home directories and, if
>found, run deliver for them instead of attempting normal delivery.

I like this idea.  Treat it as if the user's name were aliased:

	user:   "user|/usr/bin/deliver user"

In fact, I'd think the alias file reader might be the place to check for
whether .deliver exists.

>I have an alias bad-mail to which undeliverable mail is sent.
>I could easily add an alias, say try-mail, which is similar to this,
>except that, if mail to try-mail succeeds, no error code is returned.

Hm.  Neat.  Of course, you must have some way to interpolate the (unknown)
address into an alias.  I'll assume it's the character "@".  The typical
lmail->deliver configuration might then be:

	try-mail:       "root|/usr/bin/deliver @"
	bad-mail:       "root/Badmail"

-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>

chip@ateng.com (Chip Salzenberg) (11/16/89)

According to bill@twwells.com (T. William Wells):
>Well, this all depends on your point of view. Personally, I'd find
>maintaining my mailing list using deliver's mechanisms a bit of a
>bother. Whereas, with lmail, all I do is add a name to a list.

Deliver can arrange to be just that simple to use:

	case "$u" in
	mailing-list)
		awk '{print $1}' /usr/local/lib/mailing-list-file
		;;
	*)
		echo "$u"
		;;
	esac

>I truly hope that no one is taking my comparison of the two
>programs as sniping. But, in case anyone has, let me say this:
>Deliver is a neat idea. Use it if it suits your needs.

And for an opposing view:  Lmail provides enough functionality for most
purposes, and I'm glad its authors are writing and posting.

>remote execution        [uucp job umichC57d9 (11/9-16:51:16)]
>	rmail b-tech!zeeff
>exited with status 139
>
>	===== stderr was =====
>sh: 16679 Memory fault

Looks like Jon Zeeff's lmail has a null pointer dereference.  :-) :-)
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
    "Did I ever tell you the Jim Gladding story about the binoculars?"

zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/16/89)

In article <2561CDFB.4258@ateng.com> chip@ateng.com (Chip Salzenberg) writes:

>>remote execution        [uucp job umichC57d9 (11/9-16:51:16)]
>>	rmail b-tech!zeeff
>>exited with status 139
>>
>>	===== stderr was =====
>>sh: 16679 Memory fault
>
>Looks like Jon Zeeff's lmail has a null pointer dereference.  :-) :-)

If you look at it more closely, you should notice that it is site umich
that was having a problem.  They don't run lmail.








-- 
Jon Zeeff    Branch Technology  <zeeff@b-tech.ann-arbor.mi.us>
Fax:         (313) 995-1931     <zeeff%b-tech@iti.org>

bill@twwells.com (T. William Wells) (11/18/89)

In article <2561AFCE.2065@ateng.com> chip@ateng.com (Chip Salzenberg) writes:
: According to bill@twwells.com (T. William Wells):
: >According to chip@ateng.com (Chip Salzenberg):
: >:  o  Do you want a mail to news gateway?
: >:
: >:     In the system delivery file, notice addresses that look like newsgroups;
: >:     hand those messages to the gateway program.  (I did this.)
: >
: >This I can do easily enough. Just have aliases for the newsgroups
: >I want to gateway.
:
: Sure.  That's easy enough.  But what I meant by "notice" is to examine
: the address and see if it looks like _a_ newsgroup:
:
:     for u
:     do
:       case "$u" in
:       news-*)
:           group=`echo $u | sed -e 's/^news-//' -e 'y/-/./'`
:           cat $HEADER $BODY | mailnews-gateway $group
:           echo DROP ;;
:       *)
:           echo "$u" ;;
:       esac
:     done

So, with this one, someone can mail to news-comp-mail-uucp and it
goes to this newsgroup?

Neat. I doubt I could do that sort of thing with lmail unless I
were to add some kind of wildcarding or regular expressions. And I
think that that goes way beyond what I'd want to do. And besides,
there's already a solution. :-)

: As you can see, one routine handles _all_ newsgroups.
:
: >Actually, I've had a slightly different interest: munging
: >outgoing mail headers. An example: if I mail to a local mailing
: >list, the To: line does not get a domain name.
:
: Mm.  Not too hard.  In the system or post-user delivery file:
:
:     for u
:     do
:       case "$u" in
:       fake-mailing-list)
:               ( header -nvf To $HEADER
:                 echo "To: real-mailing-list@mydomain"
:                 echo ""
:                 cat $BODY ) | smail -t
:               echo DROP
:               ;;
:       *)      echo "$u" ;;
:       esac
:     done
:
: With this trick in place, you send mail to the fake-mailing-list.  Deliver
: then mangles your mail header and hands the mangled message over to Smail,
: which then delivers to real-mailing-list.

But that means that local users use a different address from
everyone else! Before I'd do that, I'd set up the global mailrc
to do the alias. (BTW, whether intentional or not, my mailer
(mailx) substitutes aliases before putting the address on the To:
line, so my current fix, since I'm the only one local posting to
my list, is tolerable. But if any of my other users want to use a
mailing list, I'm going to have to do something about this.)

What I'd like to have is, if the To: address in locally generated
mail does not contain an @ or !, to have my domain appended to
it. While I don't know Deliver well enough to construct the
script, I'm sure it can be done.

But I think that this would best be done in smail rather than
Deliver or lmail since smail sees all mail, whereas lmail or
Deliver only sees it if it is a local address. The point being
that if I mail to list,user@domain, fixing things in those would
fix the mail sent to the list, but would not fix it in the mail
sent to user@domain.

: >Hey, I just had a thought: there is little reason for me not to
: >add features that would permit easy integration of the two. I
: >could look for .deliver files in user's home directories and, if
: >found, run deliver for them instead of attempting normal delivery.
:
: I like this idea.  Treat it as if the user's name were aliased:
:
:       user:   "user|/usr/bin/deliver user"

That was the idea. (Oh yes, there is no : in the alias file; a
name starting in column 1 indicates a new entry.)

: In fact, I'd think the alias file reader might be the place to check for
: whether .deliver exists.

I'm not sure what you mean. In my code, I'd add the change to the
alias expander: if a local address does not have forwarding set,
I'd check for .deliver and, if it is present, alias the user name
to the Deliver command.

: >I have an alias bad-mail to which undeliverable mail is sent.
: >I could easily add an alias, say try-mail, which is similar to this,
: >except that, if mail to try-mail succeeds, no error code is returned.
:
: Hm.  Neat.  Of course, you must have some way to interpolate the (unknown)
: address into an alias.  I'll assume it's the character "@".  The typical
: lmail->deliver configuration might then be:
:
:       try-mail:       "root|/usr/bin/deliver @"
:       bad-mail:       "root/Badmail"

More likely, what I'd do is to append the list of failed names to
the command, without any special interpolation character. The
reason is this: if I add a general way to interpolate the address
into the command, the address interpolated would be the aliased
address. Which, in this case, would be try-mail! Whoops.

So I need to have a mechanism for interpolating just those
addresses which delivery failed for. Since that would be a
special case kludge just for try-mail and bad-mail, there is no
reason for being "nice". Which is why I'd just append the names
to the command.

I already have the list of invalid names, I use it for delivering
bad-mail. When I deliver to bad-mail, I add an X-bad-address: to
the mail headers so that I can see what went wrong. Of course, I
wouldn't do that for try-mail.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

bill@twwells.com (T. William Wells) (11/18/89)

In article <2561CDFB.4258@ateng.com> chip@ateng.com (Chip Salzenberg) writes:
: According to bill@twwells.com (T. William Wells):
: >Well, this all depends on your point of view. Personally, I'd find
: >maintaining my mailing list using deliver's mechanisms a bit of a
: >bother. Whereas, with lmail, all I do is add a name to a list.
:
: Deliver can arrange to be just that simple to use:
:
:       case "$u" in
:       mailing-list)
:               awk '{print $1}' /usr/local/lib/mailing-list-file
:               ;;
:       *)
:               echo "$u"
:               ;;
:       esac

Awk! For my system, I'd use instead of the awk line:

	sed 's/#.*//' </usr/archive/objectivism/archive/members \
	   | tr '\011 ' '\012\012' \
	   | sed '^$d'

which would give me comments and multiple names per line, not to
mention would probably _still_ be faster than the single call to
awk!

Since lmail's mailing list files are just forwarding files, any
kind of alias can go in them. For example, in mine, there is an
alias to append mailing list messages to a file. I could also run
them through a filter or another mailing list file if I wanted to.

I assume that by adding the appropriate commands right after the
awk, I could get Deliver to do the same thing.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

chip@ateng.com (Chip Salzenberg) (11/21/89)

According to bill@twwells.com (T. William Wells):
>According to chip@ateng.com (Chip Salzenberg):
>:       case "$u" in
>:       news-*)
>:           group=`echo $u | sed -e 's/^news-//' -e 'y/-/./'`
>:           cat $HEADER $BODY | mailnews-gateway $group
>:           echo DROP ;;
>
>So, with this one, someone can mail to news-comp-mail-uucp and it
>goes to this newsgroup?

Yes.  I'm using a variant of this script on ateng for the local "ate.*"
hierarchy.  Messages to "ate-*" or "ate.*" become local articles.  I've not
installed a general "news-*" alias because I don't want one yet. :-)

>Neat. I doubt I could do that sort of thing with lmail unless I
>were to add some kind of wildcarding or regular expressions. And I
>think that that goes way beyond what I'd want to do. And besides,
>there's already a solution. :-)

I see your point... though shoehorning in Henry Spencer's regexp routines
shouldn't be much of a trick.

>What I'd like to have is, if the To: address in locally generated
>mail does not contain an @ or !, to have my domain appended to
>it. While I don't know Deliver well enough to construct the
>script, I'm sure it can be done.

No problem.  Here's one specialized for a mailing list.  If you want a more
general one, let me know.

	case "$u" in
	mailing-list)
		TO=`header -f To $HEADER`
		case "${SENDER} ${TO}" in
		*[!@]*)
		    echo "$u" ;;
		*)
		    # Local mail to local address
		    ( header -nvf To $HEADER
		      echo "To: mailing-list@mydomain"
		      echo ""
		      cat $BODY ) | smail -t
		    echo DROP
		    ;;
		esac
		;;
	*)      echo "$u" ;;
	esac

>But I think that this would best be done in smail rather than
>Deliver or lmail since smail sees all mail, whereas lmail or
>Deliver only sees it if it is a local address.

Well, it should be done in Smail, yes.  But it's eminently reasonable for a
user of Smail 2.5 to have Deliver handle _all_ mail, local and remote.  For
UUCP addresses, Deliver will invoke uux, but you might want to do some fancy
special-case routing first -- just the kind of thing Deliver is best at.

>If a local address does not have forwarding set, I'd check for .deliver
>and, if it is present, alias the user name to the Deliver command.

Yes, that's what I meant.  :-)

>:       try-mail:       "root|/usr/bin/deliver @"
>:       bad-mail:       "root/Badmail"
>
>More likely, what I'd do is to append the list of failed names to
>the command, without any special interpolation character.

Sounds reasonable to me.  You may want to consider a try-mail that's not a
pipe to be in error.  If you really want it in a mailbox you should have
used bad-mail instead.
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
    "Did I ever tell you the Jim Gladding story about the binoculars?"

bill@twwells.com (T. William Wells) (11/23/89)

In article <25687B9B.29705@ateng.com> chip@ateng.com (Chip Salzenberg) writes:
: According to bill@twwells.com (T. William Wells):
: >So, with this one, someone can mail to news-comp-mail-uucp and it
: >goes to this newsgroup?
:
: Yes.  I'm using a variant of this script on ateng for the local "ate.*"
: hierarchy.  Messages to "ate-*" or "ate.*" become local articles.  I've not
: installed a general "news-*" alias because I don't want one yet. :-)

I can bet. :-)

: >Neat. I doubt I could do that sort of thing with lmail unless I
: >were to add some kind of wildcarding or regular expressions. And I
: >think that that goes way beyond what I'd want to do. And besides,
: >there's already a solution. :-)
:
: I see your point... though shoehorning in Henry Spencer's regexp routines
: shouldn't be much of a trick.

Not much of a trick. But lmail has to run root, which usually
means setuid, and so the less complex it is the better. It is big
enough as it is, so I'm not adding new features that require
radical rewrites and the like.

: >What I'd like to have is, if the To: address in locally generated
: >mail does not contain an @ or !, to have my domain appended to
: >it. While I don't know Deliver well enough to construct the
: >script, I'm sure it can be done.
:
:...
:
: >But I think that this would best be done in smail rather than
: >Deliver or lmail since smail sees all mail, whereas lmail or
: >Deliver only sees it if it is a local address.
:
: Well, it should be done in Smail, yes.  But it's eminently reasonable for a
: user of Smail 2.5 to have Deliver handle _all_ mail, local and remote.  For
: UUCP addresses, Deliver will invoke uux, but you might want to do some fancy
: special-case routing first -- just the kind of thing Deliver is best at.

Well, it depends on what you want. I have this thing about not
spending precious CPU cycles and disk accesses, thus I'd want to
call as few programs as possible. So I'd prefer to let smail deal
with what it can.

: >:       try-mail:       "root|/usr/bin/deliver @"
: >:       bad-mail:       "root/Badmail"
: >
: >More likely, what I'd do is to append the list of failed names to
: >the command, without any special interpolation character.
:
: Sounds reasonable to me.  You may want to consider a try-mail that's not a
: pipe to be in error.  If you really want it in a mailbox you should have
: used bad-mail instead.

I suppose that is so; however, I'm sure someone fill find a
reasonable use for a mailbox or whatever and there is no technical
reason for forbidding it, so I won't.

One complexity I have to decide on: after aliasing, there are four
different kinds of aliases. The pipe and file name aliases are
obviously not appropriate to send off to Deliver; local names
obviously should be. The open question is what to do with remote
names.

A remote name can fail only if the call to smail fails. Now, one
can argue two ways about that: 1) if smail fails, there is
something sufficiently wrong that sending the addresses off to
Deliver won't fix it (or that sending them off to Deliver should
not fix it). And 2) maybe Deliver can do something with the
addresses to make them reasonable.

Comments?

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

chip@ateng.com (Chip Salzenberg) (11/29/89)

According to bill@twwells.com (T. William Wells):
>In article <25687B9B.29705@ateng.com> chip@ateng.com (Chip Salzenberg) writes:
>: Shoehorning in Henry Spencer's regexp routines shouldn't be
>: much of a trick.
>
>Not much of a trick. But lmail has to run root, which usually
>means setuid, and so the less complex it is the better. It is big
>enough as it is, so I'm not adding new features that require
>radical rewrites and the like.

I just want to applaud this attitude.  Feeping creaturism is an insidious
disease, and it must be resisted at all costs.  Especially in setuid root
programs like lmail and Deliver.

By the way, did I mention that I've added logging to Deliver?  :-)
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
	  "The Usenet, in a very real sense, does not exist."