Path: utzoo!attcan!telly!problem!compus!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!udel!princeton!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.mail.misc Subject: Re: Easy administered mailers (transfer agent) Message-ID: <8404@gollum.twg.com> Date: 7 Dec 90 18:14:03 GMT References: Reply-To: david@twg.com (David S. Herron) Organization: The Wollongong Group, Palo Alto, CA Lines: 128 In article 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 Or: domain-file: node.dom.ain: node.dom.ain routing-file: node.dom.ain: | uux - node!rmail 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 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 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 "}' 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, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- "bnews must die" -- From: Rick Adams