Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!ihnp4!qantel!lll-lcc!lll-crg!seismo!sundc!hadron!jsdy From: jsdy@hadron.UUCP (Joseph S. D. Yao) Newsgroups: net.mail Subject: Re: sendmail configurations Message-ID: <581@hadron.UUCP> Date: Sat, 27-Sep-86 02:02:42 EDT Article-I.D.: hadron.581 Posted: Sat Sep 27 02:02:42 1986 Date-Received: Tue, 30-Sep-86 06:48:52 EDT References: <5600009@inmet> Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao) Organization: Hadron, Inc., Fairfax, VA Lines: 97 Summary: Repeat info & new info In article <5600009@inmet> cball@inmet.UUCP writes: >1) Every configuration which I've seen has the following: >>S0 >># first make canonical >>R$*<$*>$* $1$2$3 defocus >>R$+ $:$>3$1 make canonical The following is slightly modified from an earlier posting. As the documentation says or hints, there are essentially three major paths through the rule sets. They are: 3 -> 0 -> 4 [the doc forgets 4] 3 -> D -> 1 -> S -> 4 3 -> D -> 2 -> R -> 4 S and R are different for each mailer, and are specified as part of the M mailer specification. I have not been able to figure out what D is: nothing like that gets called by the sendmail on which I was working. 1 and 2 each consist of a commented-out rule. This leaves us with, really: 3 -> 0 -> 4 3 -> S -> 4 3 -> R -> 4 ... >S0 ># first make canonical >R$*<$*>$* $1$2$3 defocus >R$+ $:$>3$1 make canonical This seemed senseless to me, at first. After all, 3 just got called, didn't it? Why call it again, and waste the gobs of time (really!) that that takes? Well, it turns out that later on in ruleset 0 we find rules: R<@>:$* $@$>0$1 retry after route strip R$*<@> $@$>0$1 strip null trash & retry What are these doing? Right, they are returning the value of ruleset 0 called on the first wildcard pattern ($* matches all patterns including the null string). BUT, before we call 0, we want to call 3! So, we call 3 in 0! Brilliant, no? I didn't think so. I got rid of the $>3 rule, replaced the latter two RHS's with: $@>29$1 (only 30 sets are allowed: 0-29), and constructed rule set 29: S29 R$+ $:$>3$1 R$+ $:$>0$1 This, as you can now tell, just calls 3 and 0 once each, and returns whatever pattern results from that. This was entered in file zerobase.m4, just before S0, so that any use of S0 perforce includes S29. >2) The internet domain-style naming scheme inherently removes the >notion of a hosts' network from its name. ... > ... needs a mechanism to determine which network gets a given >piece of mail. Up to now, our site has had atomic hostnames and has >been able to use a sendmail class (pretty much) as follows: > /* The class 'S' includes all primary host names from host table*/ >CS/etc/hosts "%*s %s" I trust you mean FS/etc/hosts ... >R$*<@$*>$* $:$1<@$[$2$]>$3 # map aliases to primary names >R$*<@$=S$*>$* $#tcp$@$2$:$1<@$2$3>$4 # deliver mail to primary hosts > ... our host tables are reasonably active and cannot reasonably >be included directly in the configuration file. The problem is that >host names are no longer atomic since period('.') is both a sendmail >operator and part of every domain-style hostname. How can I correctly >identify tcp (or usenet) hosts in sendmail in order to select the correct >network? This is definitely a real problem. Many good authors don't realise that $=S matches exactly one token, and therefore cannot match any host.domain - style names (three+ tokens). But first: > I have solved the problem locally by modifying the sendmail >routine maphostname() to append ".tcp" when the calls gethostbyname(3) >or gethostbyaddr(3) indicate the host is reachable via TCP. This is rather clever, but involves (gasp) modifications to code. What I've been forced to resort to is twofold. First, at least internally, you should try to enforce a standard domain on your machines, which is only reasonable if they ARE all yours. More important for what you're trying to do, you'll have to have more than one list: L=hosts.lan, T=hosts.tcp, or whatever. Then you can test for <@$=L.$=D> or whatever, and appropriately invoke lan. I suggest that tcp be a default, since /etc/hosts with tcp is rather large ... -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised)