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

Internet Message Format | 1992-11-19 | 3.9 KB

Xref: sparky comp.unix.sys5.r4:555 comp.mail.misc:3742
Newsgroups: comp.unix.sys5.r4,comp.mail.misc
Path: sparky!uunet!ornl!rsg1.er.usgs.gov!darwin.sura.net!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!cbnewsk!pegasus!hansen
From: [e-mail] (Tony L. Hansen)
Subject: Re: Email header problems on SVR4.
Organization: AT&T
Date: Thu, 19 Nov 1992 17:20:39 GMT
Message-ID: <[e-mail]>
Summary: SVR4.2 (destiny) mailer is better
Keywords: SVR4.2, mail
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (tony.l.hansen)
Lines: 67

< In article <[e-mail]> [e-mail] (Rich Skrenta) writes:
<< upas doesn't fork for each rewrite, BTW.  I bet my mailer is done with
<< local delivery before smail3 has finished paging in.  Down with
<< monolithic megabyte executables with 10 links!  :-)

< You don't fork for each rewrite but you have to for each transformation
< that requires an external process, and you have to repeat each of those
< processess until there are no more new addresses produced.

<< I can add a paths file with one line:
<<
<<    alias    '(?*)@([^@]+)'    'sed -n -e "s/^\2[ \t]*//p" /usr/lib/paths'

< Note the fork/exec that will happen here.  And for the equivalent alias
< file lookup, and for lists.  And that you have to loop through this again
< for every expansion that the lists and alias lookups produce. Also, you
< are doing a linear search, where smail knows how to use dbm or sorted
< files, or yellow pages.

With SVR4.2 mail, it's possible for all of that to be cut down to a single
fork/exec. For example, the line to invoke the alias processor in SVR4.2
mail looks essentially like this:

'.+'  '[^!]+'  'Translate T=1;B=*; R=|mailalias -r -p' '%n'
                          ^^^ ^^^               ^^
               A   B                C

The part marked A indicates that all translations are to be considered
complete and should not be passed through this command again. The part
marked B indicates that the command is to be executed with as many arguments
as will fit onto the command line. The part marked C is an argument to the
alias processor that says that it should recursively expand its aliases.

And yes, mailalias uses sorted and hashed files whenever possible. And if
mailalias doesn't do what you want, just plop in another alias processing
tool in its place.

< With smail, not only can you do all the steps in a single process you can
< configure it to run in daemon mode where sending a message simply writes
< the spool file and a daemon process periodically wakes up to deliver them.
< This can dramatically smooth the load on a busy machine while imposing
< only a minute or two of delay on the worst case deliveries.

This would be a useful feature.

< (Yes, I know you could invoke programs that do those things as well, but
< it's starting to get complicated).  And when you run smail as a daemon it
< will cache some of it's lookup data instead of reopening the files for
< every message. Also, you can ask for debugging information and get it for
< every step taken.  It's pretty hard to manage that when you've tied
< together a collection of external programs.

There's a definite different philosophy involved with both upas and R4 mail.
Yes, everything can be built into a single program. But look what has to be
done in order to change how it works: you can't build on other tools to help
the process. I believe that the latter matches the UNIX philosophy much
better.

Yes, you can sometimes get better performance from a monolithic program.
Isn't it better, though, to spend your time tuning the more general program
to handle using its tools more efficiently? That way the performance of the
entire system is improved. The use of external tools then becomes a minor
matter.

                    Tony Hansen
                [e-mail], [e-mail]
                att!pegasus!hansen, attmail!tony