[comp.mail.misc] Info on IDA Sendmail kit / pathalias

salzman@rdlvax.RDL.COM (Gumby) (09/19/87)

Has anyone out in netland installed the IDA sendmail enhancement kit?
I've got it running on our system, but it doesn't seem to be working
exactly as it should in terms of its use of certain DBM files. One
annoying thing is that the sendmail.cf file that it comes with insists
on tacking on .UUCP to anything with a bang path that does not have a
domain attache to it (i.e. psivax!woof will end up woof@.psivax.UUCP
according to its rewriting rules). What I end up doing is mapping
psivax.UUCP to psivax in the uucp/xtable database. The thing is, it
says as a comment in the sample uucp/xtable file that mapping .UUCP
to anything else is NOT necessary -- wrong! That's no big deal really.
What I would like it to do is DROP the .UUCP when it sees it anywhere!
What's it doing there anyway? I can hack the master config file, but
one of the nice things about the IDA kit is that you don't and shouldn't
need to hack that!

NOTE: I've tried sending mail to the author of the IDA sendmail kit
but it bounced back and said that he doesn't exist anymore. If you're
out there, please resond (please :-).

Next question. Are there any Internet sites out there using pathalias
databases to deal with their UUCP connections (in any way shape or
form)? What I have happening is the generation of long paths for
sites that may be only a hop or 2 away (with the help of the Internet).
Example: sending to weinreb@aecom.yu.edu may generate a path like
sdcrdcf!burdvax!seismo!aecom!weinreb when I know that I could just as
well address it aecom!weinreb@seismo.css.gov or weinreb%aecom@seismo.css.gov.
The thing is, how can you tell pathalias to recognize the fact that you're
on the Internet and to recognize ALL other hosts that are on the Internet
and use optimal paths based on that??!! A tall order I'm sure. I suppose
one way would be to write an awk script that uses /etc/hosts as input
and produces pathalias input. And now you've got one HUGE pathalias database
that has all the Internet hosts (registered ones -- this doesn't include
hosts accessible via the name server) and all registered UUCP hosts.
Any insight on that? Is that the way it's basically being done (if it
is at all?). One day we can maybe have a mail system that you can
address in a generic sort of manner and it will know how to get
to the destination and know how to get there the best way, without
administrative interference. Wouldn't that be nice?! :-).

Thanks in advance for any suggestions/info.....

-- 
* Isaac Salzman - Systems Analyst/Admin.                      ----     
* Research Development Labs (RDL)                            /o o/  /  
* 5721 W. Slauson Ave., Culver City, CA. 90230               | v |  |  
* AT&T: +1 213 410 1244, x118                               _|   |_/   
* ARPA: salzman@rdlvax.RDL.COM                             / |   |
* UUCP: ...!{psivax,csun,sdcrdcf,ttidca}!rdlvax!salzman    | |   |     

honey@umix.cc.umich.edu (Peter Honeyman) (09/20/87)

isaac is looking for help with internet gateways in pathalias.  some
time ago, i hacked up a hosts.txt -> pathalias filter, called arpatxt.
i posted it to net.sources about 18 months ago, but it never caught
on.  this may have been

	o because arpatxt lacked a man page, or

	o because pathalias had to be told in an obscure way on the
	  command line what to expect, or

	o because pathalias' handling of private host definitions was
	  still pretty raw (so were domains, for that matter), or

	o because arpatxt wasn't that useful for non-internet sites, or

	o because arpatxt + pathalias needs a lot of hand-holding,
	  especially in identifying name conflicts between the internet
	  and the usenet map, or

	o because pathalias is stubborn in its refusal to generate
	  routes like aecom!weinreb@seismo.css.gov, which makes some
	  people unhappy.

to my knowledge, princeton!marc and i were the only active arpatxt
users until recently, and things were pretty laid back.  but about a
week ago, sun!david popped up with a bug report and some fresh ideas.
lots of mail, ftp-ing, and sccs id's ensued and most of the problems
mentioned above were fixed.  in fact, just by coincidence, i posted
arpatxt, now elevated to a pathalias tool, to alt.sources this
evening.  see pathalias.1 for details.  (pathalias is also up for grabs
in ~ftp/pub/honey/ on citi.umich.edu.)

the last problem, dealing with addressing syntax, gets to the heart of
mailer science.  and although pathalias has a lot to say about the
issue, i get the feeling isaac is not going to like the policy.
(unless seismo.css.gov!aecom!weinreb is satisfactory, and even that is
frowned on with pathalias -D, of which i am enamored.  in any event,
isaac should probably be mx-ing for aecom.yu.edu in the first place.)

	peter

diamant@hpfclp.HP.COM (John Diamant) (09/21/87)

> The thing is, how can you tell pathalias to recognize the fact that you're
> on the Internet and to recognize ALL other hosts that are on the Internet
> and use optimal paths based on that??!! A tall order I'm sure.  I suppose
> one way would be to write an awk script that uses /etc/hosts as input
> and produces pathalias input. And now you've got one HUGE pathalias database
> that has all the Internet hosts (registered ones -- this doesn't include
> hosts accessible via the name server) and all registered UUCP hosts.
> Any insight on that? 
> -- 
> * Isaac Salzman - Systems Analyst/Admin.                      ----     
> * Research Development Labs (RDL)                            /o o/  /  
> * 5721 W. Slauson Ave., Culver City, CA. 90230               | v |  |  
> * AT&T: +1 213 410 1244, x118                               _|   |_/   
> * ARPA: salzman@rdlvax.RDL.COM                             / |   |
> * UUCP: ...!{psivax,csun,sdcrdcf,ttidca}!rdlvax!salzman    | |   |     

I think you're approaching the problem the wrong way.  The UUCP world uses
pathalias for routing.  The ARPA Internet world is moving to using domain
servers and MX records to do that.  The right answer is to get UUCP sites that
have registered domain names to have MX records installed at forwarding
machines on the Internet.  Then, any site that is on both UUCP and Internet
should try to use the domain server first, and only use pathalias if that
fails.  Inside HP, we are trying to set something like that up by providing
a utility that will allow you to configure for a particular domain or address
whether to use the domain server or not.  After that step is finished,
pathalias could be called if the address hasn't resolved yet.  This way,
Internet sites get the benefit of efficient delivery via MX records, and UUCP
only sites use whatever is in the pathalias database.


John Diamant
TSBU				UUCP:  {hplabs,hpfcla}!hpfclp!diamant
Hewlett Packard Co.		ARPA Internet: diamant%hpfclp@hplabs.HP.COM
Fort Collins, CO

fair@ucbarpa.Berkeley.EDU (Erik E. Fair) (09/26/87)

In the referenced article, diamant@hpfclp.HP.COM (John Diamant) writes:

	The right answer is to get UUCP sites that have registered
	domain names to have MX records installed at forwarding
	machines on the Internet. Then, any site that is on both
	UUCP and Internet should try to use the domain server first,
	and only use pathalias if that fails.

Ah, but what of the case where I use a UUCP name for an Internet
host (e.g. I say "ut-ngp!user" and the pathalias generated database
spits back "ngp.utexas.edu!user")? The call to search the pathalias
generated database had better not be in a sendmail mailer definition,
where I've already committed to delivering by something other than
SMTP. It has to be somewhere in the address canonicalization routines,
which requires hacking on sendmail.

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu

honey@umix.cc.umich.edu (Peter Honeyman) (09/27/87)

yeah, that's a small problem with sendmail: as delivered, it doesn't
allow you to run arbitrary programs/scripts on addresses.  frankly,
many people find it a lot easier to munge headers in c or sh than in
sendmail's rule language, possibly the most brain-damaged language ever
invented, yes, rob, even worse than postscript.

i suppose it's possible to make the local mailer a router that looks at
the address and passes the message back to sendmail ... maybe not.

i've seen sendmail hacks (from waterloo?) that let rewrite rules munge
addresses with $>program.

	peter

diamant@hpfclp.UUCP (09/27/87)

> In the referenced article, diamant@hpfclp.HP.COM (John Diamant) writes:
> 
> 	try to use the domain server first,
> 	and only use pathalias if that fails.
> 
> The call to search the pathalias
> generated database had better not be in a sendmail mailer definition,
> where I've already committed to delivering by something other than
> SMTP. It has to be somewhere in the address canonicalization routines,
> which requires hacking on sendmail.
> 
> 	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu

This is a good point.  However, in the HP version of sendmail, this doesn't
require a change to the source.  The reason is that our version allows you
to invoke an external program just like a ruleset, using "<" instead of ">."
For example, here is a rule that calls pathalias ($P is set to the pathalias
binary) on UUCP syntax addresses:

DP/usr/bin/uupath
R$+<@$-.UUX>		$:$<P$2!$1		pathalias routing

I believe that this is an HP-only enhancement at this time, but I could
be mistaken.  At any rate, with that, it is trivial to add a call to
pathalias in ruleset 0 if that is what you want.  I would say you should only
do that on "!" paths, though, to allow the MX records to take precedence
when available on domain addresses.


John Diamant
TSBU				UUCP:  {hplabs,hpfcla}!hpfclp!diamant
Hewlett Packard Co.		ARPA Internet: diamant%hpfclp@hplabs.HP.COM
Fort Collins, CO

dplatt@teknowledge-vaxc.ARPA (Dave Platt) (09/28/87)

Posting-Front-End: GNU Emacs 18.41.7 of Fri Aug 28 1987 on teknowledge-vaxc (berkeley-unix)


In article <20962@ucbvax.BERKELEY.EDU>, <honey@citi.umich.edu> writes:

    i suppose it's possible to make the local mailer a router that looks at
    the address and passes the message back to sendmail ... maybe not.

Yah... I've done it, sort of.  My hack (I call it "pathfinder")
doesn't pass the message "back to sendmail", though;  it passes the
message forwards, into another incarnation of sendmail, with a new
address.  I use "pathfinder" to locate the "best" path from my
machine (which is on the Internet) to arbitrary hosts on the UUCP
net, via one of about 15 different gateway systems.  Works pretty
well, in practice;  its biggest single drawback is that the message
passes through sendmail twice, thus generating two sets of syslog
entries.  Second biggest drawback is that only a single gateway is
selected for each message, and if that gateway's down, the message
sits in the local queue until it comes back up;  it's impossible to
reroute the message (e.g. by changing the topology files and rebuilding
the paths database) without manually removing it from the queue.

A better approach would be for the addressing lookup to occur within
sendmail, and for there to be several alternative paths (with costs)
for each destination host.  This would require more hacking with the
guts of sendmail's address-rewriting rules than I'm really comfortable
with, so I've deferred any such work until after the next appearance of
Comet Kohoutek.

torben@dorsai.ics.hawaii.edu (Torben N. Nielsen) (09/29/87)

In article <1692@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes:
>yeah, that's a small problem with sendmail: as delivered, it doesn't
>allow you to run arbitrary programs/scripts on addresses.  frankly,
>many people find it a lot easier to munge headers in c or sh than in
>sendmail's rule language, possibly the most brain-damaged language ever
>invented, yes, rob, even worse than postscript.

Agreed. The language is primitive and when you first start looking at it,
it looks impossible. But you can do a lot with it. The ability to run
arbitrary programs/scripts on addresses would be nice to have. But it might not
be necessary if we could agree to a real separation of concerns between UA
and MTA.

>i suppose it's possible to make the local mailer a router that looks at
>the address and passes the message back to sendmail ... maybe not.

I don't see any reason why it wouldn't be possible. I just don't think it's
desirable. I've always been taught that one should separate concerns as well
as possible; i.e., write well-defined modules that cooperate across clear
interfaces. There's enough ``intelligence" in local mailers now.

>
>i've seen sendmail hacks (from waterloo?) that let rewrite rules munge
>addresses with $>program.
>
>	peter

Read:

	Mail Processing at UIUC, Report No. UIUCDCS-R-86-1289

According to that document, this was first done by Gary Murakami at AT&T.

							---torben

dudek@ubglue.UUCP (09/30/87)

In article <1692@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes:
>i suppose it's possible to make the local mailer a router that looks at
>the address and passes the message back to sendmail ... maybe not.
>
>i've seen sendmail hacks (from waterloo?) that let rewrite rules munge
>addresses with $>program.
>
>	peter

Yes, it is possible, and is how I arranged pathalias to work on Harvard.
The only tricks are to be sure and avoid indefinite recursion, and to be
prepared for two sendmail invocations for every rewritten address.
I avoided recursion by appending ';nopath' to uucp paths which had
already been pathaliased - this of course required sendmail configuration
support to pass this through ruleset 3 in the right place, and to strip it
in ruleset 0 after it was used to suppress another call to pathalias.
Any of you who received bounces from Harvard of the form 'host!user;nopath
Unknown host' now know where it comes from.

Sendmail changes to allow arbitrary rewriting of addresses by programs
should be better all around, but if you lack the proper mods feel free
to peruse the stuff in 'mail/sendmail.cf.tar' anonymously ftp-able from
harvard.harvard.edu.

	Glen Dudek
	ex-postmaster@harvard.harvard.edu