🚀 go-pugleaf

In article <849@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes:
>This started when Phil mentioned that both AMD and AT&T have a
>machine named neptune.  Actually, there's only a name conflict if you
>call both machines neptune.  AMD's machine is neptune.AMD.COM (now
>that Phil has installed smail), and AT&T's machine is
>neptune.foo.bar.bletch.ATT.COM.

  The "magic of smail" also creates some other problems. For example, I just
found out the hard way that there are two machines named "solar" (I gather
from some comments in some map entries that this has been known for some
time, but I just found out today and it bit me BADLY). One is at Stanford,
and we have a direct uucp connection to them. Unbeknownst to me, there is
also a "solar" at AT&T that has a direct connection to cbosgd, the gateway
into some of those foo.bar.bletch.ATT.COM domains you mention. So, when
I changed our L.sys file to increase the frequency of our connection to
"solar" (due to user demand here), and changed my local map entry accordingly,
and regenerated my pathalias output/smail input database, I thought it worked,
because people who mailed from here to user@solar.uucp got their message
sent over the direct link as desired, as opposed to previously when it went
over some convoluted path through seismo (which, it now occurs to me, may
very well have ended at the wrong "solar" anyway). Unfortunately, my messages
to mark@cbpavo.MIS.OH.ATT.COM got routed to Stanford by smail, and bounced 
back. In order to fix the problem, I have to edit BY HAND the map files and
excise references to the AT&T "solar". Yes, I can still mail to the AT&T one
if I send to solar.ATT.COM, so you are right that smail removes ambiguity in
DESTINATION host names. However, ambiguous INTERMEDIATE host names becomes a 
serious problem, because a user can send the mail via the wrong intermediate 
host and lose the message, despite the fact that a "path" to the destination
supposedly exists! And this happens even when the destination host is 
specified with a domain address!
  Therefore, I think it is more important than ever to eliminate ALL duplicate
host names from uucp, or at least from the map postings, or we're going to see
lots of incorrectly routed mail as smail and other domain routers like it
become more and more common. As for me, I have no choice but to manually
edit the map postings every month, or do something else equally kludgy like
running pathalias with the cbosgd!solar link declared DEAD (and then there's
no guarantee that mail to other places within AT&T might not get routed to
Stanford anyway because of OTHER links that AT&T's solar might have). This
is a headache for me, but nearly as serious as the problem that occurs when
such duplicate names exist but are not KNOWN about.

--Greg
-- 
UUCP: {hplabs, seismo, nbires, noao}!hao!woods
CSNET: woods@ncar.csnet  ARPA: woods%ncar@CSNET-RELAY.ARPA
INTERNET: woods@hao.ucar.edu