🚀 go-pugleaf

In article <tl9tgb1gcC@herkules.sssab.se> sveer@sssab.se (Sven L Eriksson) writes:
>I'm looking for a mailer that doesn't demand too much knowledge or
>work by the system administrator. Does anyone know about any such thing?

Well.. Shoot.. That leaves out MMDF, in its current state it's
not a trivially administered system.  So I don't get to pontificate
on that.  Ohwell..

You might think about writing some configuration management software
for an existing mailer rather than writing a new mailer.  I've recently
done this and, believe me, it's easier than writing a new mailer!


>... Sendmail is very
>powerful but if an experienced person needs 5 days ...
...
>Smail 2.5 is easier.  Just the aliases-file and a paths-file ...
>... But Smail 2.5 cannot do anything but local delivery and 
>remote delivery via UUCP....
...
>Smail 3.xx is promising. It does all we dream about and more....
>... And it has a GNU copyleft. (We want to adapt the mailer to
>the rest of our environment which we don't want to be free.)

Hmm.. Can't you include smail 3.x as a seperate package/product?

>Are there any more mailers I don't know of and that can be interresting?

Other than MMDF, no.

To complete the survey .. MMDF is very powerful.  It isn't easy to
learn, and would take an experienced person some time to learn
and configure for the local environment.  The problem, though, is
mostly one of (lack of) documentation, than ease of configuring
the system.  Once you know MMDF it's pretty easy easy to work with..

It helps that, as I see it, MMDF has a better overall *design* than
any of the others.  For instance, sendmail treats addresses as simple
character strings, but in fact addresses have a lot of structure within
them.  MMDF treats addresses as a data structure which just happens
to fit very closely to an RFC-822 source route, and can easily be
converted to a "pure" UUCP source route.  But since it's a data structure
the programs which manipulate it are in C.

Another good feature, which has some bearing on your proposed mailer
design, has to do with the routing.  In your proposed design you have
a one-stage lookup of domain name -> route.  In MMDF this is split
into two stages: 1) name resolution & canonicalization, and 2) route
determination.

These really are two different sorts of things.  Mixing them together
into one pile of information simply makes things confusing.

Name resolution:  For instance ..

	full.dom.ain: full.dom.ain
	full.dom:	full.dom.ain
	full:		full.dom.ain

Would provide mappings from "full.dom.ain", "full.dom" and "full"
to "full.dom.ain".  This isn't quite the way MMDF does it ...

If you want it to be a route ...

	full.dom.ain: full.dom.ain, route-last, ..., route-first

would make MMDF route the mail like 

	route-first!...!route-last!full.dom.ain!user
or	<@route-first,...,@route-last:user@full.dom.ain>

Route determination: You work only with full domain names in
	the table(s) for this.  On the LHS you list domain names
	you want to do routing for & on the RHS you list information
	used in the routing.

Using this two-step method you can easily have multiple names channeled
through one entry in the routing file.

> Delivery to remote nodes are made using programs. An example:
>
>	node.dom.ain : | uux - node!rmail <recipient>

Or:
domain-file:	node.dom.ain: node.dom.ain
routing-file:	node.dom.ain: | uux - node!rmail <recipient>

How about using a "$(name)" form to substitute values?  "printf" format
strings don't necessarily work well because `%' is a routing character
for some mail systems.

>	/host-a|host-b/ : | uux - host-c!rmail <recipient>

I think this looks ugly..  Especially if you were to be processing
pathalias output & tried to put all the hosts handled by one of
your neighbors into one regex..!

>And if you want the mailer to check with the UUCP system for known UUCP
>hosts:
>
>	/`uuname`/.UUCP : | uux - $1!rmail <recipient>

Why would you need to do this?  Instead, every time you edit your
Systems (L.sys) file -- or possibly every day/hour/week -- you run
a script like

	uuname|awk '{print $1 ": " $1 ".uucp"; print $1 ".uucp: " $s ".uucp"}'
	uuname | awk '{print $1 ".uucp: | uux - " $1 "!rmail <recipiend>"}'

and installs those into your domain & routing tables as appropriate?

You get the *same* information without having to run uuname all day long.
A table lookup, especially with a dbm-hashed database, is a *LOT* cheaper
than running a process..

>$1 is a notation for the first reg-exp used. In this case this reg-exp
>involves a command substitution. All words produced by this command are
>interpreted as alternatives as /host-a|host-b|...|host-n/. $1 expands
>to the matched word.

Careful .. you're heading down the same rosy path that sendmail went down.


-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- "bnews must die" -- From:    Rick Adams <rick@uunet.uu.net>