Path: utzoo!mnetor!uunet!nbires!isis!aburt
From: aburt@isis.UUCP (Andrew Burt)
Newsgroups: comp.mail.uucp
Subject: Re: Duplicate site names
Message-ID: <2168@isis.UUCP>
Date: 29 Dec 87 16:24:58 GMT
References: <872@uop.edu> <3569@tut.cis.ohio-state.edu>
Reply-To: aburt@isis.UUCP (Andrew Burt)
Organization: Math/CS, University of Denver
Lines: 58

In article <3569@tut.cis.ohio-state.edu> karl@tut.cis.ohio-state.edu (Karl Kleinpaste) writes:
>robert@uop.edu writes:
>>   I posted this to another group, but since there is a discussion of
>>   duplicate names going here, what about tut?
>>   There is a finnish computer named tut, and recently I have noticed a
>>   north-american machine with the same name.

>That's us, on tut.cis.ohio-state.edu...
>...references to our Tut are always properly domain-qualified, it is not
>(or should not be) any problem...
>...and the only other place
>where his name is mentioned is in outbound Path: lines in news
>headers, where he shows up as a neighbor of osu-cis and bgsuvax, thus
		   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>assuring his uniqueness within the frame of reference.
 ^^^^^^^^^^^^^^^^^^^^^^^

There's also a tut.colorado.edu for what it matters.

The emphasized part (^^^^) is not necessarily true, however.  If one
sends mail to osu-cis!tut!user, and the path to osu-cis takes the message
through a machine with a so-called "smart mailer" that tries to reroute
mail "better" then the "smart mailer" may decide it knows how to reach tut 
better and may pick a different tut.

Real life example.  After the death of seismo, pathalias here decided rutgers
was the best way to reach most domainized sites.  I later sent mail to
(oddly enough) osu-cis!tut!user and received a bounced mail msg from tut
in Finland after a few days.  Tried again, same result.  Turned out
rutgers was being "smart".

I tried to sway Mel Pleasant toward a "smarter" algorithm such as
	if original-path has the form ...!site1!site2!user,
	and a "better" path to site2 can be found than via ...!site1,
	then *verify* that the site2 found in the maps is the same as the
	site2 meant in original-path by checking whether the site2 in
	the maps lists site1 as a neighbor.  If not, use original-path.

Clearly this adds more weight to the "smart" mailers, making them look up
map entries for each possible re-routing attempt (i.e., the smart system
is selflessly making net routing better at the expense of its own cpu time).

On the other hand, if you set out to do a job (no matter how selflessly
motivated), don't do half a job.

As I run a large mailing list and deal with many odd addresses, this kind
of behavior has really made life tougher.   Mailer problems have been keeping
me from getting the list regular for months.  (And don't say use a newsgroup,
we're talking about the Unix Security mailing list -- too touchy for general
consumption.)

My solution to this problem?  I declared rutgers a dead site for
pathalias purposes...
-- 

Andrew Burt 				   			isis!aburt

              Fight Denver's pollution:  Don't Breathe and Drive.