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

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

Xref: sparky comp.unix.sys5.r4:536 comp.mail.misc:3722
Newsgroups: comp.unix.sys5.r4,comp.mail.misc
Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!ncar!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: Tue, 17 Nov 1992 19:03:05 GMT
Lines: 79

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

>What I find tragic is that the R4 mailer could have been really great.
>Not doing RFC-822 headers, and being short-circuited by useless bloat
>ruined it.

Well personally I like the anarchistic nature of relative addresses
and agree that mailers should not be forced into a strict scheme
conrolled by someone else.  Realistically though, you need something
to understand and generate RFC-822 headers when you want them.

>I've used smail 3 and it's certainly a powerful mailer.  The neat thing
>about the upas style is the vast power you get from one simple, relatively
>short configuration file.  I remember smail 3 having a bunch of big
>configuration files and a thick manual needed to understand them.

But the inherent problem is that you need external databases for any
real work and external programs to perform the transformations. And
when any transformation occurs you have to start over at the top so
you can end up running lots of processes to expand a list.  Smail
does each step internally so it can be much more efficient at the
recursion.

>I'm not criticising smail; it's an industrial-strength mailer.  But
>regex-style rewriting makes some things really easy.  Some stylized
>examples from my mailer:

More concise maybe - I'm not sure about easier.  (I'm not against
regexps at all - they would make a nice addition to Smail's more
intimate knowledge of mail addressing)

>    Map all mail for foo.com to bar.com:
>        rewrite '(?*)@foo.com'    '\[e-mail]'

An appropriate "paths" entry.

>    Make mail for bozo deliver locally instead
>        rewrite '(?*)@bozo'    '\1'

Can't be done - smail never looks at the local part of the address
unless the host portion resolves to the local machine. (1)

>    Give address of the form <box-number>@mailbox-service.host to
>    my mailbox-server script:
>        deliver '([0-9]+)@mailbox-service.host'  'script \1'

You would have to assign a transport to this host either with a
special router that matched it or with a "methods" lookup, then
define the transport to run your script.  But you couldn't constrain
the legal addresses to the numeric set - the transport script would
have to check and generate the bounce (1)

>    stupid.host doesn't have SMTP or uucp-over-tcp.  Deliver mail
>    to it with rsh:
>        deliver '(?*)@stupid.host'  'rsh stupid "/usr/bin/rmail \1"'

Same as above.

(1) There is a provision to run an external program as a router, and it
can optionally return a transport as well as the transformed address.  That
approach could handle these situations at the cost of starting an
external process per address.

I think those are pretty unusual address handling requirements anyway.  I
have a lot of mail to local lists where the lists are maintained in the
form of local aliases and the aliases are maintained in a form that
just gives the host!user and thus requires a path lookup.  Suppose a
list expands to 100 aliases. How many external programs will the
r4 mailer have to run to resolve the real user names and the paths to
their hosts, and can it perform the delivery by grouping the expanded
addresses by the "next-hop" sites instead of generating a copy per
address?

If you need the regexp functions and have both the r4 mailer and smail3
it should be possible to let the r4 mailer do the regexp transformations
first and hand anything left over to smail for final processing.

Les Mikesell
  [e-mail]