Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!ll-xn!mit-eddie!gatech!ukma!david
From: david@ukma.UUCP
Newsgroups: comp.mail.uucp
Subject: Re: Bug (feature?) in smail 2.3
Message-ID: <6762@a.ms.uky.csnet>
Date: Wed, 3-Jun-87 10:09:59 EDT
Article-I.D.: a.6762
Posted: Wed Jun  3 10:09:59 1987
Date-Received: Sat, 6-Jun-87 03:55:04 EDT
References: <2088@cxsea.UUCP> <2089@cxsea.UUCP> <1217@epimass.EPI.COM>
Reply-To: david@ms.uky.csnet (David Herron -- Resident E-mail Hack)
Distribution: world
Organization: U of Kentucky, Mathematical Sciences
Lines: 60
Keywords: REROUTE considered (sometimes) harmful

In article <1217@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes:
>1. ...
>   the UUCP Project does not keep the map current (I'm not blaming
>   them, it's a tough job), it is out of date on the day it's posted.

*grin*, we try...  There's times I'm glad I only take care of KY. :-)

>2. REROUTE believes that there are no duplicate UUCP names. ...
>
>   To use Phil Ngai's example, there is an AT&T site named neptune
>   and an AMD site named neptune.  But there's no name conflict;
>   the AMD site neptune does not appear in the UUCP map and its official
>   name is neptune.amd.com.  If someone mails to amdcad!neptune!user,
>   this is a different neptune than the AT&T one, and mailers shouldn't
>   be f*king with the address.

This is the part I couldn't let pass by.

If amdcad wants to have their neptune able to send and receive mail
without hassles, then they should arrange it so that mail will be sent
to amdcat!neptune.amd.com!user.  (i.e. putting that out in headers when
mail is sent out, announcing in the maps either the existance of a
gateway for .amd.com or the existance of neptune.amd.com itself, etc).

If they do anything else, they're asking for trouble.

>3. You make it impossible for users to avoid machines that are down.
>   ihnp4, for example.  Somebody posts a message "avoid ihnp4" but
>   there's no way any of your users can.

My own strategy is to route to the first host mentioned in the path
which I am given.  This is merely a convenience, so that if I have some
address from a well-known-site, then I don't *have* to find the path to
that well-known-site.  Looking down the path beyond the first site is
not kosher because you don't *know* if those names you see there
actually refer to the ones you have in your database.  That is, unless
you do some edge analysis a la peter honeyman.

To be honest tho....  I don't quite practice what I just preached.  I
run MMDF here, and the uucp channel sort-of breaks those rules.  When
it receives a message it collapses the From_'s, looks down that path
for sites in its' data base (assuming only .uucp places) and stops at
the first one it doesn't know.  Then it re-writes the header so that
the From: says unk1!unk2!...!user@known.UUCP.  For the rmail arguments
it does exactly what I describe above.  I don't quite agree with its
strategy, but I don't have the time to change it...


>4. You make it impossible to test specific UUCP connections with loop
>   tests.

I would go along with this, however I haven't needed to do this for at
least a year.  I can't even remember the last time I had to do this.
And I am a heavy user of e-mail.

-- 
----- David Herron,  cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet
----- (also "postmaster", "news", and the Usenet map maintainer for Kentucky.)
----- bsmtp-users@ms.uky.csnet for bsmtp discussion
----- bsmtp-users-request@ms.uky.csnet for administrivia