NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/mail/uucp/2119

Text File | 1992-11-22 | 5.3 KB | 115 lines

Newsgroups: comp.mail.uucp
Path: sparky!uunet!psinntp!monymsys!sonyd1.Broadcast.Sony.COM!blilly.UUCP!bruce
From: [e-mail] (Bruce Lilly)
Subject: domains in the UUCP maps (was Re: Are costs relevant ? (was Re: UUCP map entries))
References: <[e-mail]>
Organization: Bruce Lilly
Date: Mon, 23 Nov 92 00:34:04 GMT
Message-ID: <[e-mail]>
Summary: taking the domain gateways out (alone) won't help; adding more may well do so
Reply-To: [e-mail] (Bruce Lilly)
Lines: 102

In article <[e-mail]> [e-mail] (Christophe Wolfhugel) wrote:
>
>I have some of my correspondants in the US who are UUCP connected to
>an Internet mail relay host, but they fully process the maps, which
>means for this site, due to the top-level aliases, will directly
>generate a path like:
>
>...!uunet!mcsun!corton!grasp.insa-lyon.fr!wolf
>
>Whereas the logic would have excpected just ...!uunet!grasp.insa-lyon.fr!wolf
>which would have allowed MX routing on the Internet part of the travel.
>And in this particular case it avoid relays and uses different lines.
>
>This is one of the reasons I'm fully *against* top-level domains aliasing
>why the hell has this been done (map coordinators, you may answer this
>question). I don't remember this has been discussed in this group, or in
>others.

Do you object to all aliases involving domain names, or only the
ones that declare gateways for top-level domains?

In any event, the real issue is what is done with the
pathalias-generated paths.  In the case of a path like the one
above, if the first site in the path is a neighboring site whose
MTA can handle domain addresses, the path could be shortened to
"grasp.insa-lyon.fr!wolf" before being handed to that site,
since the RFC976-style domain addressing is sufficient. The full
path would only be used when being passed to a neighboring site
whose MTA cannot handle embedded domains (as the first
component) or whose MTA must see one of that site's immediate
neighbors as the first component of a path, or whose MTA would
return domain-addressed mail back to my site (because it cannot
determine how to deliver via another route). That processing of
the path is what I do (via sendmail.cf and some ancillary
databases) at the sites which I administer. I know it's done
elsewhere as well (I recall seeing an article several years ago
written by Karl Kleinpaste while he was still at OSU regarding
the same subject (eliding leading bang paths in addresses
containing domains)).  Frankly, directly using the
pathalias-generated paths is probably counter-productive; if a
site in the path is down (temporarily or permanently), either
the message will (eventually) bounce, or manual intervention
will be required by one of the administrators, or the mail will
never be delivered. I choose to pass the message to the next
site which is closer to the destination (the one of my
neighboring sites which appears as the first node in the
pathalias-generated path) with enough addressing information to
indicate the recipient. It is then up to that neighboring site
to determine how to forward the message one more hop closer to
its destination. That provides sufficient flexibility so that
mail can be rerouted arouned failed nodes.

Without some mechanism for getting the domain name into the path
in the first place, the full uucp node-name path would be used.
Without declarations for domain gateways, the pathalias input
would have to have connection data which explicitly lists the
domain name, e.g.
corton    grasp.insa-lyon.fr
to generate a path like the example. Note that the declaration
of aliases such as
foo = foo.bar.com
is insufficient, since pathalias will generate paths using the
node name as known to its predecessor. I.e. the map input

foo = foo.bar.com
bar foo(LOCAL)

will result in a path of ...!bar!foo!..., while

foo = foo.bar.com
bar foo.bar.com(LOCAL)

will result in a path of ...!bar!foo.bar.com!....

It's probably A Good Idea for sites to use the latter domain
forms in their map entries, provided their site can handle
RFC976-style path-embedded domains, however the domain gateway
declarations do serve to get domains into paths, which can then
be shortened to eliminate the leading routing information as
described above.

The " ...!uunet!grasp.insa-lyon.fr!wolf" form might well be
generated by pathalias if the d.Top map file (of top-level
domains and their gateways) included .fr as well as the subset of
top level domains (and pseudo-domains) which is currently in
that file. Another means of getting pathalias to generate the
shorter form is to include input describing the Internet
connections, similar to what the now-obsolete arpatxt program
used to do.  I believe that there's a version of pathalias that
uses DNS resolver queries (internally in pathalias) to achieve
the same result. Unfortunately for those of us without Internet
connections, there is no authoritative map input file
distributed that describes the Internet connections. It is
possible, however, for individual sites to fashion such a file
from publicly available information, including the comments in
the map files (unfortunately, there's no consistent format for
comments indicating Internet connectivity), plus the Internet
host table, plus local knowledge.

--
    Bruce Lilly        blilly![e-mail]
                    ...uunet!sonyusa!sonyd1!blilly!bruce