Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!husc6!rutgers!apple!fair
From: fair@Apple.COM (Erik E. Fair)
Newsgroups: comp.mail.misc
Subject: Re: Getting the most out of pathalias
Summary: what I do here at Apple (part 1 of 4)
Message-ID: <23430@apple.Apple.COM>
Date: 6 Jan 89 08:15:56 GMT
References: <601@ur-cc.UUCP>
Organization: USENET Protocol Police, Western Gateway Division
Lines: 97

arpatxt is a waste of time; you have to maintain a list of duplicate
UUCP/and domain *component* names to prevent mis-routing when you try
to use arpatxt (tedious manual work). Also, NIC HOSTS.TXT will
eventually go away, and then where will you be? I've got a better hack
which I will describe below.

pathalias tries really hard to avoid hybrid addresses. In practice, I
never see any out of the UUCP maps, in part because of the rules that
the UUCP map coordinators apply when massaging the data before posting
it (I know; I'm the Northern California coordinator), and because
pathalias assigns DEAD (or worse) to anything that would generate that
kind of address.

The right thing to do with the pathalias output (all those paths) is to
build a dbm(3) database with them, and add the SEISMO/UUNET patch to
your sendmail source (it adds one new operator: ${name$} with some
slightly strange semantics that basically will look up that name in a
dbmified path database, and if successful, replace it with the path
found. You then have to run it through some cleanup rules, but it works
quite well, and it's an absolutely minimal intrusion into the sendmail
sources [it was written for 5.54 sendmail and slid right into 5.59 with
no change, to give you an idea]).

The effect of this here (with the particular way I've written the
sendmail config) is that if someone (here or elsewhere through here)
uses a path:

	foo!bar!bletch!user	(or bar!bletch!user@foo.UUCP)

sendmail will:

1) look up foo in class U (our UUCP neighbors) and send it on
	as normal if it's in there (no different than standard UUCP mail).

2) look up foo in the pathalias generated database and use the path
	found therein (special parsing goes on here for paths that begin:

		do.main!frob!nitz!user

	they get turned into:

		frob!nitz!user@do.main

	and sent on their merry Internet way (we're on the Internet,
	so this works; generation of such paths described below)).

3) failing 1 & 2, I error back thusly (with the #error mailer):

	Unknown UUCP host - not in the UUCP maps and not one of our
	UUCP neighbors

I do not believe that "rerouting" is a good idea so I don't.

Since I like the Internet, I use it as much as I can. To encourage
such usage (and cut back on the length of the UUCP paths generated by
pathalias) I run pathalias twice over the UUCP maps before generating
the dbm database used by sendmail. First pass is just for the raw
maps. Then I run the pathalias output through an awk script called
"mkglue" that generates a sizeable glue file. Then run pathalias again
over the raw maps with the glue file appended to the input.

The mkglue script walks through pathalias output looking for Internet
domain names (legal ones; I filter by top level domain name) and then
does two things: it reverses the equivalence statements, e.g.

	apple= apple.com

becomes

	apple.com= apple

and after all of these have been found, it produces a completely
connected network of the domain names, e.g.

	INTERNET= {
		apple.com,
		rutgers.edu,
		ucbvax.berkeley.edu,
		} (DEMAND+LOW)

The effect of this is that the paths generated tend to have their first
hop be Internet, rather than UUCP. It also causes UUCP references to
Internet sites to go Internet (if they declared the equivalence [NOT a
domain gateway] in the UUCP maps). It about halves the average path
length.

One other thing that I've tickled my sendmail config into doing
without adding a rule-per-site is domain forwarding with naming hack.
It should be pretty clear from the config (which I will post
separately) what's going on.

I don't really have the time to answer detailed questions by mail;
Apple is keeping me *very* busy. Experiment with the stuff I post as
you please - if you discover a bona fide problem, I'd love to hear
about it, but it's all strictly "as is", caveat emptor.

	Erik E. Fair	apple!fair	fair@apple.com