dsc@izimbra.CSS.GOV (where was george?) (08/18/88)
In article <4540@saturn.ucsc.edu> koreth@ssyx.ucsc.edu (Steven Grimm) writes: >standard set of diffs for sendmail so it looks stuff up in a pathalias >database? I am starting to modify sendmail on my own, but since look at either the `ida' enhancements which should be reappearing soon in comp.sources.unix according to paul vixie or take a look at the file `pub/uucpdomain.shar.Z' in the anonymous ftp directory on `uunet.uu.net'. the latter is used at rutgers (which does active rerouting) as well as seismo & uunet (which do not) and though i haven't updated the shar file since going to sendmail 5.59, the changes should patch fairly easily into that version. the supplied diffs add uucp hostname lookup operators, '${' & '$}', which are analogous to '$[' & '$]'. dsc
daveb@llama.rtech.UUCP (Dave Brower) (08/22/88)
In <23668@uunet.UU.NET> dsc@izimbra.CSS.GOV (where was george?) writes: >In article <4540@saturn.ucsc.edu> koreth@ssyx.ucsc.edu (Steven Grimm) writes: >>standard set of diffs for sendmail so it looks stuff up in a pathalias >>database? I am starting to modify sendmail on my own, but since > >look at either the `ida' enhancements which should be reappearing soon >in comp.sources.unix according to paul vixie or take a look at the file >`pub/uucpdomain.shar.Z' in the anonymous ftp directory on >`uunet.uu.net'. the latter is used at rutgers (which does active >rerouting) as well as seismo & uunet (which do not) and though i >haven't updated the shar file since going to sendmail 5.59, the changes >should patch fairly easily into that version. the supplied diffs add >uucp hostname lookup operators, '${' & '$}', which are analogous to >'$[' & '$]'. > Another way to do this is to run sendmail with smail 2.X, which is found at any number of comp.sources.unix archives. This is what the UUCP Project recommends. I am given to understand that there is another commonly used alternative, whose name escapes me at the moment. Uupath? Dunno, I'm sure some fan will correct me. -dB "Ready when you are Raoul!" {amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com <- FINALLY!
rick@seismo.CSS.GOV (Rick Adams) (08/23/88)
Please note that the method Comay referred to is a lot different that smail or uumail (and a lot more powerful). To begin with, the pathalias translation is part of sendmail, so there is no fork/exec to do the pathname lookup. However, the most important part of it is that it allows you to have a pathalias "route" like: ucbvax %s@ucbvax.berkeley.edu Now, if you're on the internet this is incredibly useful. You can turn a uucp path into an internet address BEFORE you decide what delivery agent to use. This is extremely useful in a complicated configuration. Also, because pathalias is general enough to handle routing domains, you could even do something like: .span %s.span@whatever.thespan.gatewayis.topleveldomain and therefor do pseudo-domain routing without hacking sendmail. If you just want to do uucp routing, smail or uumail is ok. If you want to get tricky and do something complicated BEFORE chosing a delivery agent, Comay's hacks are clearly the way to go. (not surprisingly, we used them here and I goaded him into doing them...) ---rick
vixie@decwrl.dec.com (Paul Vixie) (08/23/88)
I'd like to add to Rick's note: # If you just want to do uucp routing, smail or uumail is ok. If # you want to get tricky and do something complicated BEFORE chosing # a delivery agent, Comay's hacks are clearly the way to go. IDA-enhanced sendmail can do this kind of thing, and as Rick says, it is much better to be able to rewrite and reroute before you choose a delivery agent, since which delivery agent you use will depend on the domain or host you're trying to reach. (It does _not_ usefully depend on the syntax of the address - insisting that something go out over UUCP because you found a "!" is not going to buy very many cookies.) I don't know what Comay's hacks are like. I know about IDA, and I like it because it isn't pathalias-specific - you associate a DBM database with an identifying letter, and you can look things up in this database in the RHS. You can have more than one database open -- which I particularly like, since I can keep a database of UUCP exceptions (overriding MX), SMTP exceptions (overriding pathalias), and then pathalias. It's a very flexible way to get mail sent around, and it means I don't have to refreeze my config file whenever I add a UUCP neighbor. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013
chris@mimsy.UUCP (Chris Torek) (08/25/88)
In article <75@volition.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: >I'd like to add to Rick's note: > ># If you just want to do uucp routing, smail or uumail is ok. If ># you want to get tricky and do something complicated BEFORE chosing ># a delivery agent, Comay's hacks are clearly the way to go. > >IDA-enhanced sendmail can do this kind of thing, and as Rick says, it is >much better to be able to rewrite and reroute before you choose a delivery >agent, since which delivery agent you use will depend on the domain or host >you're trying to reach. ... Just as another note, it is possible to do this without modifying sendmail, although the method can only be described as a kludge. (Since sendmail refuses to distinguish between incoming mailers, the situation is even kludgier than it would have to be.) What you do is have sendmail `deliver' everything to a program that does the routing, then hands the message back to sendmail for *real* delivery. You have to pick some `unlikely' string to distinguish between first-time addresses and routed addresses (`host.ROUTING-TRASH'? :-) ). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
woods@ncar.ucar.edu (Greg Woods) (08/26/88)
In article <13206@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >What you do is >have sendmail `deliver' everything to a program that does the routing, >then hands the message back to sendmail for *real* delivery. That's what I do; the "program" in question is "smail", with a modification that causes it to recognize when the first hop in the generated route is really an Internet link, in which case it hands it back to sendmail for delivery by SMTP. All you have to do is make sure your sendmail.cf file will recognize those paths as Internet links, by having rules like Cslist-of-fake-uucp-links-that-are-really-Internet $=s!$+ $2@$[$1.$] # yes, I know this is oversimplified Then you need appropriate CNAME records in your name server for these "fake uucp" hosts, e.g. GATECH. IN CNAME GATECH.EDU. So it works like this: 1) address comes into sendmail of the form user@host.podunk.edu 2) If podunk.edu is in list of known Internet domains, deliver by SMTP 3) Hand off to smail 4) If generated route is through a real uucp site, queue via uux 5) Hand generated bang path back to sendmail, which hopefully will NOT pass it back to smail again and start an infinite loop :-) --Greg
vixie@decwrl.dec.com (Paul Vixie) (08/26/88)
I've got five articles to respond to in this group today, I'll try to keep it
short.
In article <13206@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
# have sendmail `deliver' everything to a program that does the routing,
# then hands the message back to sendmail for *real* delivery.
Someone else followed this up with a description of a local hack to smail
that uses this trick. I can see the need for this if you either have a
very large machine that can fork many processes per second, or if you don't
have or don't want sendmail source.
If you don't mind maintaining sendmail source code, you can get a very fast
and very elegant solution to this problem with IDA or something like it.
I understand why many people would prefer not to deal with modified sendmail
source code, though. Perhaps Berkeley can be convinced to include IDA in
Sendmail 5.60? I know L.L. (IDA's author) is willing...
--
Paul Vixie
Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP
Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul
Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013jsloan@wright.UUCP (John Sloan) (08/26/88)
From article <13206@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): : > have sendmail `deliver' everything to a program that does the routing, > then hands the message back to sendmail for *real* delivery. You have > to pick some `unlikely' string to distinguish between first-time > addresses and routed addresses (`host.ROUTING-TRASH'? :-) ). This is a kludge, but it works, and it works well if you're a binary only site. We have been using a program, "dnagent", since December of '86 that does just this. We recently replaced uumail with smail, and we hope to replace dnagent's functionality with smail sometime RSN, but for now it solves our problems. Dnagent appears to be a mailer to Sendmail. It receives a message, takes the recepient address, rewrites the envelope based on what it finds in a dbm database that is maintained with a combination of cron'ed scripts and manual intervention, and resubmits it to Sendmail. We were having it do translation of @ addresses into paths, but it turned out easier to let uumail/smail to that instead. Dnagent's not perfect but it solved our problems with routing domain-style addresses between CSNET, UUCP, and local machines. I'll include the man page here. DNAGENT(8) MAINTENANCE COMMANDS DNAGENT(8) NAME dnagent - RFC920 domain network mailer agent for Sendmail SYNOPSIS dnagent -b [ -l ] [ -ddb ] dnagent -a [ -l ] [ -ddb ] dnagent -l [ -ddb ] dnagent [ -x ] [ -f from ] [ -v ] [ -Ccf ] [ -ddb ] -u address [ address ...] mailagent [ arguments ] DESCRIPTION The Domain-Network Agent is an middle-end to the Sendmail program. When Sendmail identifies a host or organization domain which it cannot resolve internally, it delivers the message to the Dnagent mailer. Dnagent resolves destination addresses by querying a DBM database containing rewrite strings for a key which matches the host-domain portion of the address. If a match cannot be found, Dnagent retries the query with the next higher order portion of the domain (if one exists), scanning from left to right. If a match cannot be found before the address is exhausted, Dnagent can fetch a default rewrite string from the database. This rewrite string is applied only to the destination address(es) on the outer envelope as specified by Sendmail as arguments on the command line when it forks and executes the Dnagent mailer. Addresses in the RFC822 compliant headers in the text of the message are passed through undis- turbed. Rewrite strings may contain macros which are expanded to be the user portion of the address, the domain portion, that part of the domain which matched a key, and conditional expansions which depend upon whether the full domain and the matched key are the same. Once the addresses are rewritten, Dnagent resubmits the mes- sage, with the new outer envelope, to Sendmail for further processing. Several iterations may be made until Sendmail recognizes an address which it can resolve. The number of iterations can be tuned by adding additional rulesets to the Sendmail configuration file, or by making the rewrite strings in the Dnagent database more explicit. When different switches are applied to the Dnagent mailer, the same program may build, append, and dump the database. The database entries are derived from several sources: tables available from the CSNET Info Server, the USENET Pathalias database, and local entries. Sun Release 3.4 Last change: Thu Feb 4 10:26:32 EST 1988 1 DNAGENT(8) MAINTENANCE COMMANDS DNAGENT(8) A debugging mailer, Mailagent, is also included. Mailagent simply echoes all of its command line arguments and standard input to standard error. It is useful for debugging new mailers or examing the behavior of Sendmail. Both Dnagent and Mailagent have been in use as production software for nearly a year as of this writing. Options -b Read standard input for domain-rewrite string pairs and (re)build a new Dnagent database. -a Read standard input for domain-rewrite string pairs and add to an existing Dnagent database. -l List the contents of an existing Dnagent database to standard output. This can be combined with the -b or -a options. -u recepient [ recepient ... ] Read a message on standard input and submit to Sendmail to mail to a list of recepients, where each recepient is an address of the form user@domain. This is the form of the command that is used in the Sendmail mailer definition. -ddatabase Specify an alternative Dnagent database named database. The root name of the default database is /usr/spool/sites/dnagent. -x Use debug mode, tracing the parsing of each domain and dumping the resulting Sendmail command to standard out- put instead of executing it. -f sender Specify the from address as sender (passed along to Sendmail). -v Specify verbose mode on mail delivery (passed along to Sendmail). This is useful in debugging. -Cconfiguration Specify an alternative Sendmail configuration file to use (passed along to Sendmail). -oddeliverymode Spefify an alternative delivery mode (passed to Send- mail). This allows you to, for example, run all pri- mary mail delivery immediately, but to delay processing of Dnagent output until a Sendmail queue run. Sun Release 3.4 Last change: Thu Feb 4 10:26:32 EST 1988 2 DNAGENT(8) MAINTENANCE COMMANDS DNAGENT(8) Input Format Input to the build function of Dnagent consists of lines each containing a domain and rewrite string pair seperated by white space. The rewrite string is in printf format, with the addition of special string substitution parameters shown below. A domain does not include a leading period (unlike pathalias). A rewrite string can be any legal string that does not con- tain any printf control strings. For example, if you want to include a percent sign in your output address, you must dou- ble it ("%%"), just as you would in a printf string. The rewrite string may contain the following parameters, which will be filled in at run time with the appropriate informa- tion gleaned from the recepient address. $u User portion of the address. $d Domain portion of the address. $m Trailing portion of the domain that matched in the database. $% Same as "%$d" if $d!=$m, "" otherwise. $! Same as "$d!" if $d!=$m, "" otherwise. Example Input edu $u%%$d@CSNet-Relay.CSNET cs.wright.edu $u vlsi.ceg.wright.edu $u@poly.LOCAL cbosgd.att.com cbosgd!$!$u arthur.cs.purdue.edu cbosgd!ihnp4!purdue!$!$u asc.purdue.edu $u%%$d@CSNet-Relay.CSNET purdue.edu $u%%$d@CSNet-Relay.CSNET Sample Invocations dnagent -v -x -u jsloan@spots.wright.edu < /dev/null Test an address for resolution using debug and verbose mode. dnagent -b Build a Dnagent database from a list of domain-rewrite string pairs read from standard input. dnagent -l -d/usr/local/lib/dnagent Dump a Dnagent database to standard output, using a database different from the default. dnagent -C/usr/lib/test.cf -u jsloan@spots.wright.edu Resolve an address and pass along to Sendmail using a different configuration file from the default. Sun Release 3.4 Last change: Thu Feb 4 10:26:32 EST 1988 3 DNAGENT(8) MAINTENANCE COMMANDS DNAGENT(8) Sendmail Examples Here are some sample Sendmail classes, rules, and mailer definitions for Dnagent and Mailagent. For more complete examples, see the Wright State University SPOTS Sendmail Kit. # define top-level domains CICOM EDU GOV MIL NET ORG AU IL FR JP KR NL SE UK US # resolve RFC920 addresses in ruleset zero to Dnagent R$*<@$*$=I> $#dnagent$@$2$3$:$1@$2$3 user@domain.top # resolve test addresses in ruleset zero to Mailagent R$*<@$*TEST> $#test$@$2$:$1@$2 user@any.TEST # define Dnagent mailer Mdnagent, P=/usr/local/mail/dnagent, F=nsmDFef, A=dnagent -v -u $u # define Mailagent mailer Mtest, P=/usr/local/mail/mailagent, F=FDMxPf, A=email -g $g -f $f -x $x -h $h -u $u -q $q -j $j Background The domainization of the Internet specified in RFC920 has inspired other networks, such as CSNET and USENET, to adopt the same addressing standard. Internet sites have (nearly) real-time access to systems which support the RFC920 name server function. Sites on these other, affiliated, networks rely on source routing for the delivery of domain-addressed mail. Unfortunately this scheme poses problems for non- Internet sites using 4.2BSD Sendmail, the Berkeley mail routing mechanism, and which connect to more than one net- work (for example, CSNET/Phonenet and USENET). o Vanilla 4.2BSD Sendmail does not provide a table lookup scheme for RFC920-compliant domains in addresses. o Binary licensees may not be able to modify Sendmail to implement such a facility. Source licensees may lack the expertise to do so. o Tables of host names used in Sendmail to provide user- friendly resolution of simple addresses become large and cumbersome as networks such as CSNET, USENET, BIT- NET, etc. continue to grow. These tables are kept memory resident, so that Sendmail requires more and more virtual address space as it runs slower and slower. o Addition or modification of host entries is a poten- tially lengthy process, as the configuration must be Sun Release 3.4 Last change: Thu Feb 4 10:26:32 EST 1988 4 DNAGENT(8) MAINTENANCE COMMANDS DNAGENT(8) thawed and refrozen and the Sendmail daemon restarted. o Bouncing all unresolved messages to the CSNET relay may result in extra hops, even when the destination machine is a nearby USENET site. o Bouncing all unresolved messages to a USENET backbone site may result in extra hops until it reaches a USENET machine on the Internet. Some (most) USENET sites may not understand RFC920-compliant addresses. o While explicit resolution of domains may be possible in the Sendmail rulesets, as is done in the JANET Sendmail kit, such a solution can be unwieldy and could exhaust various resources. o While the resolution of domains through software replacing the normal mail utilities is possible, as is done in the smail program, such solutions often circum- vent the logic in the Sendmail configuration file, where much of the strategic decisions regarding routing may be made, and they are often specific to a particu- lar networking protocol, and so are not of as much use for sites with a variety of local area and wide area networks. (We may note that we have used smail quite successfully on machines which do not have Sendmail, and/or which are peripheral to our main campus mail relay). While better software will surely come along with time, non-Internet sites need a temporary, interim solution. Dnagent is an attempt at such a solution. Advantages o It requires no source changes other than to the Send- mail configuration file (which is distributed as source). o It allows domains to be mapped to arbitrary machines on either wide or local area networks. The mapping is more easily maintained than would be possible with a Sendmail-only solution. o It does not disturb the RFC920-compliant addresses in the message headers. o The Sendmail configuration file can be significantly shorter, usually resulting in a faster parsing of addresses. Disadvantages o Mail delivery can be slow, especially if several Sun Release 3.4 Last change: Thu Feb 4 10:26:32 EST 1988 5 DNAGENT(8) MAINTENANCE COMMANDS DNAGENT(8) iterations are necessary. Since Dnagent is not closely integrated into Sendmail, system overhead can be rela- tively high. o It is one more program and database that the system support staff must understand and manage. o Parsing and rewriting addresses in the message headers based on information in the database, either by Dnagent or Sendmail, is not an option. This could cause prob- lems with older mailers which require a UUCP flavored From_ line. Acknowledgements Dnagent was inspired by alias.c and newaliases.c by Eric Allman (Britton-Lee Inc.), opath.c by Eric Roskosm (Perkin- Elmer Corp.), and getpath.c and uumail.c by Stan Barber (Baylor College of Medicine). No code borrowed, but a lot of good ideas used. FILES /usr/spool/sites/dnagent.dir default Dnagent DBM database /usr/spool/sites/dnagent.pag default Dnagent DBM database SEE ALSO pathalias(1l), sendmail(8), uumail(8l) AUTHOR John Sloan <jsloan@SPOTS.Wright.EDU>, The SPOTS Group, Department of Computer Science and Engineering, Wright State University Research Building, 3171 Research Blvd., Ketter- ing, Ohio, 45420 John Sloan +1 513 259 1384 Wright State University Research Center jsloan%wright.edu@csnet-relay 3171 Research Blvd., Kettering, OH 45420 ..!ucsd!ncr-sd!ncrlnk!ncrpcd!wright!jsloan ...!osu-cis!wright!jsloan Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
jsloan@wright.UUCP (John Sloan) (08/26/88)
From article <13206@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): : > Just as another note, it is possible to do this without modifying > sendmail, although the method can only be described as a kludge. > (Since sendmail refuses to distinguish between incoming mailers, the > situation is even kludgier than it would have to be.) What you do is > have sendmail `deliver' everything to a program that does the routing, > then hands the message back to sendmail for *real* delivery. : It may be a kludge, but it's a worthwhile, and powerful, solution. We've been using, since December 1986, a program we developed, "dnagent", that does just this. Here is a portion of the man page. (Apologies: I posted an earlier response to this which included the entire man page. When I realized how long it was I tried to cancel the article. I think I succeeded.) The Domain-Network Agent is an middle-end to the Sendmail program. When Sendmail identifies a host or organization domain which it cannot resolve internally, it delivers the message to the Dnagent mailer. Dnagent resolves destination addresses by querying a DBM database containing rewrite strings for a key which matches the host-domain portion of the address. If a match cannot be found, Dnagent retries the query with the next higher order portion of the domain (if one exists), scanning from left to right. If a match cannot be found before the address is exhausted, Dnagent can fetch a default rewrite string from the database. This rewrite string is applied only to the destination address(es) on the outer envelope as specified by Sendmail as arguments on the command line when it forks and executes the Dnagent mailer. Addresses in the RFC822 compliant headers in the text of the message are passed through undis- turbed. Rewrite strings may contain macros which are expanded to be the user portion of the address, the domain portion, that part of the domain which matched a key, and conditional expansions which depend upon whether the full domain and the matched key are the same. Once the addresses are rewritten, Dnagent resubmits the mes- sage, with the new outer envelope, to Sendmail for further processing. Several iterations may be made until Sendmail recognizes an address which it can resolve. The number of iterations can be tuned by adding additional rulesets to the Sendmail configuration file, or by making the rewrite strings in the Dnagent database more explicit. When different switches are applied to the Dnagent mailer, the same program may build, append, and dump the database. The database entries are derived from several sources: tables available from the CSNET Info Server, the USENET Pathalias database, and local entries. John Sloan +1 513 259 1384 Wright State University Research Center jsloan%wright.edu@csnet-relay 3171 Research Blvd., Kettering, OH 45420 ..!ucsd!ncr-sd!ncrlnk!ncrpcd!wright!jsloan ...!osu-cis!wright!jsloan Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
kre@munnari.oz (Robert Elz) (08/27/88)
In article <89@volition.dec.com>, vixie@decwrl.dec.com (Paul Vixie) writes: > Perhaps Berkeley can be convinced to include IDA in > Sendmail 5.60? I know L.L. (IDA's author) is willing... Last I heard, Berkeley were convinced (though I don't know if anyone had convinced Eric, or if he cares any more). If you really want this to happen, get a current sendmail from Berkeley, get the IDA stuff put in it, and then send it back, with no great delay, so other changes won't have happened in the meantime. This will solve the real problem, of who exactly is going to do all the wonderful things that should be in the next BSD release. Liaise with Keith Bostic (bostic@okeeffe.berkeley.edu). kre