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

Internet Message Format | 1992-11-18 | 5.3 KB

Xref: sparky comp.unix.sys5.r4:550 comp.mail.misc:3735
Newsgroups: comp.unix.sys5.r4,comp.mail.misc
Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.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: Wed, 18 Nov 1992 18:19:00 GMT
Lines: 108

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.

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.  If you are running sysVr4 you should have a decent
paging mechanism and shouldn't worry about large executables or
how many links they have.  When you have a running copy, executing
any of the links will automatically do the right thing with shared
text.

>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.  (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.

>> >    Make mail for bozo deliver locally instead
>>
>> Can't be done - smail never looks at the local part of the address
>> unless the host portion resolves to the local machine. (1)
>
>I'd be surprised if this was true.  I want to hide hosts behind
>a mail hub all the time.  What if your paths file mapped mail for
>bozo onto the localhost?

Hiding a complete host is built-in.  You just supply a list of
names that the local machine considers to be itself and it
checks those before doing any routing operations.  If it matches
the next steps are "directors" rather than "routers" to perform
the aliasing and forwarding steps.  I thought "bozo" was a user
instead of a hostname in your example.

>I remember seeing someone over in comp.mail.sendmail asking
>if he could customize his bounce messages, and have a copy of
>the bounced mail saved.  This is the sort of thing that is trivial
>to do in R4 mail, but nearly impossible in other mailers unless the
>capability has been directly supported.
>
>For example, I have different bounce messages and behaviors for
>"unknown local user" vs. "no such host in this domain".

These are built-in, but generally appropriate.  You do have an option
to send a copy of all bounces to the postmaster, or just the headers.
Problems relating to configuration errors are always spooled and
deferred.  As I recall, the r4 mailer was happy to just discard
everything.  There's an option to forward messages to unknown
hosts to another machine and a similar but separate option for messages
to unknown local users.

> [grouping by host]
>You are right, the R4 mailer is weak in this area.  But this problem
>is easy to work around for mailing lists on leaf sites.  I ran a list
>of 150 or so addresses just fine under R4.

Mine "look" like leaf lists, but because of host hiding the addresses
expand to a few dozen people on each of several machines one of
which is connected by a slow satellite link.  It's important to me
to be able to hold the groups together.

>I even got the admin for my feed to stick a short "zrmail" script
>into /usr/bin:
>
>    #!/bin/sh
>    uncompress | rmail $*
>
>so I could send compressed mail.
>
>    deliver    'host!(?*)'    'compress | rmail - -r host!rmail (\1)'
>    deliver '([^!]+)!(?*)'    'rmail - -r \1!rmail (\2)'
>
>A one line change to my config file to add compressed mail!

So it takes 5 or 6 lines in an smail "transports" definition, but you
get to specify the limits for how many addresses may be used in
a single invocation and how many characters may be in the command line,
along with the address format and the uid to execute as.

>I'll admit that smail3 is probably better in many ways.  But being
>able to wire in new capabilities like fake hosts, new lookup
>mechanisms and transports in seconds without looking at a manual
>is just great.

Agreed, but both systems have those capabilities.  The "looking at the
manual" part is pretty subjective.

Les Mikesell
  [e-mail]