NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/unix/sys5/r4/566

Internet Message Format | 1992-11-20 | 3.6 KB

Xref: sparky comp.unix.sys5.r4:566 comp.mail.misc:3752
Newsgroups: comp.unix.sys5.r4,comp.mail.misc
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!machine!chinet!les
From: [e-mail] (Leslie Mikesell)
Subject: Re: Email header problems on SVR4.
Message-ID: <[e-mail]>
Organization: Chinet - Public Access UNIX
References: <[e-mail]> <[e-mail]>
Date: Thu, 19 Nov 1992 19:23:05 GMT
Lines: 66

In article <[e-mail]> [e-mail] (Rich Skrenta) writes:

>Smail's configuration files contain arguments and hooks to a vast array
>of internal built-in rules.  I don't like this sort of design, since
>it means that if the designer didn't happen to forsee every single rule
>I want, I'm out of luck.

But it also gives you the hooks to external programs if you are willing
to take the efficiency hit.  You can use an external programs as
routers as well as transports.

>In other words:  I'd rather work on the rules themselves, than to
>have the rules out of reach in an executable, and only be able to
>change the arguments to them.

No problem.  Besides when you have the source, nothing is "out of
reach".

>I know how to do these things in Unix with xargs and su and regexp's.
>What variable names do the smail config files use?  How many of these
>little built-in hooks are there?

Generally enough - and I do some oddball stuff.   And when there aren't
enough, you can always run an external program.  What do you do when you
want to specify the uid that a file should be written as, or an executable
executed as?

>Most of your justification for smail is based on efficiency arguments.
>I'd actually rather not have to sort my paths file.  The fact that a
>mail daemon is running all the time with cached tables gives me the
>creeps.  It bugs me to have to compile a sendmail configuration file.

Efficiency is important to me. But equally important is the fact that
the delivery process is predictable and I can use "smail -v 200 address"
to see a verbose description of every step of what can be a very
complex process.  If any portion of the process isn't working I can
count on the delivery being deferred and eventually getting a descriptive
notification.  Even if part of a mailing list is delivered and part
isn't due to a configuration error, smail has a pretty good chance of
being able to pick up where it left off when the error is corrected
and deliver to the remaining addresses.

And, by the way, you don't have to sort your files - smail will do
a linear search if you want, and it stat()'s the files it has cached
before each run so it will automatically pick up changes to them.

>The SMTP daemon should start up, eat its message, dump it into /bin/rmail,
>and go away.  The mailer should be talking SMTP to other sites no more
>than it should be talking uucp over tty's.

Heh, let's see what happens to your glued-together programs if PIPEDEV
happens to fill up someday.

>Efficiency just isn't important for most sites.  Let monster sites run
>MegaMail, The Executable.  I want my mail system to be built out of
>simple little scripts and programs I can understand.

Simple scripts lose their simplicity real quick when you combine them
since the ways they can fail increase geometrically.  I'll bet that
if someone made a random typo in your "little" configuration file
and in one of my "complicated" smail files, I could find and fix
mine faster because there would be a fair chance that smail would
tell me what was wrong.

Les Mikesell
  [e-mail]