Xenix mail system

Chip Salzenberg chip at ateng.ateng.com
Sun Feb 12 07:26:30 AEST 1989


According to tif at cpe.UUCP:
>According to chip at ateng.uucp (Chip Salzenberg):
>>In article <694 at vector.UUCP>, chip at vector.UUCP (Chip Rosenthal) writes:
>>> Hey Chip ... what does your mail setup look like?
>>
>>/usr/bin/mail -----> execm ---.
>>			        |
>>	    Elm -----.          |             .----------> (user mailboxes)
>>		     |          v             |
>>	  uuxqt -----+-----> smail,rmail -----+----------> uux
>>	 	     |                        |
>>      recmail -----'                        `----------> deliver
>
>Hey Chip ...  (Sarcasm for humor only, i.e.  :-)  )
>(Firstly, I'm not familiar with the features of deliver)
>Unless deliver is real smart, that won't cover ALL the Xenix options.
[mention of Micnet deleted]

Deliver can handle just about anything.  This is because its "delivery files"
are shell scripts.  Therefore, anything you can express in a shell script can
be used to control mail messages.  For example, Micnet could be handled by
the system delivery file.  Assume that "fred" and "joe" are remote users on
machines "fredmach" and "joemach" respectively:

	# system delivery file
	# Use Micnet for fred and joe

	for u
	do
		machine=

		case "$u" in
		fred)	machine=fredmach ;;
		joe)	machine=joemach ;;
		*)	echo $u; continue ;;
		esac

		if [ "$machine" ]
		then
			cat $HEADER $BODY | remote - $machine rmail $u
		fi
	done

The Micnet-only machines would have a similar delivery file, but with an
additional case "*!*" to handle UUCP addresses.

Incidentally, the hostname is available to delivery files in the environment
variable $HOST (or is it $HOSTNAME?), so all machines can have identical
system delivery files with behavior that varies according to the host name.

>Anyway, for the micnet only machine, the right hand side of the diagram,
>in my system, is replaced by the original /usr/lib/mail/execmail (moved
>to execmail.x).  It has the smarts to find the real uucp machine and send
>the mail there (it actually goes through smail again on that machine).  The
>philosophy was to leave as much of the existing system intact as possible.

Well, that's fine.  It is not, however, necessary.  Deliver is flexible enough
to handle a mixed Micnet/UUCP network.  Combined with Smail 3 it's just about
all I can imagine needing, short of mind-reading.

>Now, did I just waste my time discussing a problem that deliver solves?

No waste.  It's an interesting problem.  Perhaps I can come up with a more
elegant solution if I think about it.  One thing that will help is my plan
to add a second system delivery file, one that is executed after the user
delivery files but before actual delivery takes place.  This would permit
user delivery files to output plain addresses, and then have them processed
just like incoming addresses.

Also, as separate programs, I'm planning to write an alias file lookup program
and a message header parser.  Currently I make do with grep, but it's not
sufficient to handle multi-line header fields.  Such is life in the big city.
-- 
Chip Salzenberg             <chip at ateng.com> or <uunet!ateng!chip>
A T Engineering             Me?  Speak for my company?  Surely you jest!
	  "It's no good.  They're tapping the lines."



More information about the Comp.unix.xenix mailing list