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

Internet Message Format | 1992-11-17 | 11.8 KB

Path: sparky!uunet!utcsri!torn!nott!cunews!revcan!ecicrl!clewis
From: [e-mail] (Chris Lewis)
Newsgroups: comp.mail.uucp
Subject: Re: UUCP map entries (long) (Was Re: Any easy way to filter this type of UUCP traffic?)
Message-ID: <[e-mail]>
Date: 17 Nov 92 08:10:12 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Elegant Communications Inc., Ottawa, Canada
Lines: 281

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> [e-mail] (Chris Lewis) wrote:
>>In article <[e-mail]> [e-mail] writes:
>>>In article <[e-mail]> [e-mail] (Chris Lewis) wrote:

>>Even a DEAD link is cheaper than the implicit backlink.  So if your
>>goal is to keep the cost high, you can either leave it implicit,
>>or equivallently, define it 100*DEAD.

>If the link exists, and can be used for mail routing for UUCP
>sites, it ought to be in the maps. Put 100*DEAD or 1000*DEAD if
>you like.

But that's the whole point.  Links aren't always bidirectional.
And even if they are technically, policy may impose that they
aren't to be used for mail routing - failing your second test.

So why list 'em?  In fact, if you *do* list 'em, pathalias -vv won't
find them, so you'll end up with routing thru links that people don't
want you to and there's no way to find out without hand-viewing
pathalias cost output.  Redundant data.  More data to get wrong
or out of date.  And if the forward link goes away, and the
other guy doesn't delete his 100*DEAD you'll still have bogus links
in both directions.  Ie: more failure modes.

>>[Bruce describes "sir-alan", a situation where a system moved, and
>>some of the unidirectional links to or from it are possibly
>>bogus.  This example has been brought up before.]

>>>So, what do we have? Considering only site "sir-alan" and those
>>>sites in the u.usa.pa.? maps that declare connections to
>>>sir-alan, we have:

>>>sir-alan    ispin(DAILY), util20(DAILY)
>>>util20    sir-alan(POLLED)
>>>pitt    sir-alan(DAILY)
>>>devon    <sir-alan>(EVENING+FAST)

>>>The sir-alan <-> util20 link looks like it's OK ("ispin" doesn't
>>>appear to be in any of the map files--at least not the ones I
>>>have here.).   But what about sir-alan -> pitt and
>>>sir-alan -> devon ? Do those links exist (they're not declared)?
>>>More to the point: do the pitt -> sir-alan and devon -> sir-alan
>>>links really exist? (sir-alan was at one time located in
>>>Pennsylvania, BTW) How can we tell without sending all sorts of
>>>test messages? Can we really believe that the path
>>>"...!pitt!sir-alan!devon!..." will work (pathalias will generate
>>>such a path unless there's another way to get between pitt and
>>>devon (without backlinks))? And where is "ispin"?
>>
>>>[Believe me, there are many, many more examples of such, shall we
>>>say ambiguities in the UUCP maps.]
>>
>>I don't see anything particularly wrong with this set of
>>maps when taken in their entirety.  In fact, devon and sir-alan
>>do seem to be using the same "terminal"/no-backlink method I've
>>suggested.  The costs of both pitt and devon to sir-alan are both
>>consistent with a long distance link which is still being maintained,
>>and that sir-alan may even be conciously blocking stuff downstream of
>>him going via devon or pitt by not listing the backlinks.

>>As to your questions:
>>    - does sir-alan->pitt or sir-alan->devon exist?
>>      Probably.

>Probably not.

You mean you don't know?  Those map entries are relatively
recent.  I'd believe them more than by ad-hoc reasoning about
existant or non-existant backlinks.

>>    - how can we tell?  By bounces.  A priori analysis
>>      is pointless.

>Can you guarantee that a bounce will be generated?

By bounces I really meant non-delivery and potential bounce.
Spending time reading map data means nothing in the face
of what links *actually* exist.

>As somebody who seems to be concerned about the costs of
>electronic mail, you should appreciate the value of being able
>to generate a usable route the first time (``a priori
>analysis'').

A priori analysis meaning a human being examining the pathalias
data before pathalias does.

>>    - can we believe ...!pitt!sir-alan!devon!...?  Are
>>      you being asked to?

>Yes. The maps so indicate (part of the path being a backlink).

Pathalias *really* generates ...!pitt!sir-alan!devon!...?
From what I saw of the rest of those maps, there were
much lower cost alternatives to 100*DEAD.

>>        If pathalias chooses
>>      to route that way (does it?) you'll either get
>>      a bounce or it'll work [...]

>or everything will end up in a bit bucket somewhere with no
>notification to the sender or intended recipient.

Again, bounce in a generic sense.

>>    - where is ispin?  Do you think pathalias cares?
>>      If the link is legitimate, does it matter?

>Since there is currently no "ispin" registered in the maps, it
>is possible for anybody to register a site with that name. If
>that hypothetical registered site has no connection to sir-alan,
>pathalias may generate unusable paths. Unusable paths may be
>generated any time there is a duplicate UUCP node name in the
>pathalias input (i.e. the same name referring to two or more
>distinct machines).

You're making the (implicit) assertion that a #N line constitutes
a "registration".  Is it?  Have you got confirmation?  Very few of
the unpacking packages are capable of creating a proper #N list.
I don't even think the latest version of uuhosts (1.65?) manages
to handle #N properly (won't list multiple names in a #N).
(Unpackmaps does.)  The only other software that I know of that
does anything other than discard comments is uuhosts 2.0 (not
really related to uuhosts 1.65).  But that's very recent, and
doesn't really unpack things.

A looser definition makes a lot more sense: if it's mentioned
in the maps (as in, pathalias generates any line with that site
as the destination), then the name is taken.  Everybody
who runs full maps thru pathalias can determine that.

Though, obviously, the UUCP Mapping Project isn't consistently
doing that either....

>Note that it is possible to pre-process the pathalias input to
>remove some bad data which will/may generate unusable paths. The
>ideal solution is for the map data to be correct in the first
>place.  There are a number of indicators that something is awry
>with map data, including a missing link which results in a
>backlink for which there is no other explicitly declared path.

Yeah, but if they're explicitly 100*DEAD, pathalias -vv
won't find them for you will it?

>>>Ah, but as with any program, the output generated by pathalias can
>>>be no more reliable than the data fed to it (GIGO).

>>Thanks for the history lesson.  You've not yet managed to
>>demonstrate that DEADing the backlinks as opposed to leaving
>>them implicit make it any less GI.  In fact, it can only make
>>it *more* likely you'll trip over it.  It doesn't help
>>pathalias route smarter.  And it doesn't help you when something
>>bounces.

>``DEADing''? Is there such a word? I never said it.

No, you didn't use that word.  I never said you did.  It's merely
a shorthand for explicitly marking it DEAD (or worse).  Which is
what you wnat.  Don't try to misdirect the discussion off into the
weeds.

>Explicitly declaring an extant link is normal practice. If
>nobody declared any UUCP links there wouldn't be UUCP maps.

Now you're getting silly.

>Lack of a declaration for a link for which there is a reverse
>link is an indication of bad data in the maps.

You're making the assumption that all links are bidirectional.
They are not.  Again: you *cannot* tell whether there is a reverse
link.

>Removing the
>one-sided link, then, removes a possible source of bad paths.

And it's just as likely that you're removing a perfectly good link.

>Unfortunately, because some people don't bother to declare
>extant links, this method can't be used (more precisely, it can
>be used, although many existing paths would be removed from the
>pathalias output).

Even if everybody declared all "extant" links, this completely
ignores the issue of non-extant reverse links.  By your rules
you're still stuck with bogus paths.

>>>If one is concerned about others using a pay-by-the-minute link,
>>>such as uunet, one should get a domain name (uunet will do that
>>>for it's customers) and use it, and stay out of the UUCP maps
>>>entirely. [reread that last bit, then read the README file which
>>>is periodically posted to comp.mail.maps]

>>uuwhere -r README doesn't really say anything like this at all.

>``
># Please note that the purpose of this map is to allow mail routers
># within UUCP to work properly.  The eventual direction is to make the
># map smaller (through the use of domains), not larger.  As such, sites
># with lots of local machines connected together are *strongly*
># encouraged to join the UUCP Zone.  Through the use of a domain, you
># need only register your domain gateway system(s) with the UUCP Mapping
># Project.  Properly configured, all of your internal nodes will hide
># behind the gateway(s).
>''

Sorry Bruce, the quoted bit doesn't support what you said.
It talks about organizations with many sites registering only their
domain gateway in the UUCP zone.  Which *are* in the UUCP maps.
This doesn't cause individual sites to omit their entries from the
maps altogether either.

Besides, the commentary is grossly out-of-date - it still
refers to d.* files.

In fact, if the person sending mail to you doesn't have their
smart-host on the internet, or smart-hosted in turn to an internet
system, if you're site isn't in the maps, pathalias-only routing sites
cannot reach you at all.

>>You can, of course, omit your systems completely from the UUCP
>>maps and rely on MX forwarding by your metered site.  But this does
>>several very undesirable things:

>>    1) every bit of mail to you *must* traverse the paid link.
>>       Regardless of whether you have cheap local links.

>No, the local sites can have additional pathalias input data to
>indicate the non-published links.

You mean I have to tell the several thousand machines in eastern
Ontario and environs what they should put in *their* local maps?  That
ain't gonna fly at all.

>>    2) every bit of mail to you *must* traverse the Internet.
>>       Otherwise, nobody'll know where your MX points.

>No, if UUCP-only sites "foo.com" and "bar.org" are both
>connected to uunet, who is the primary mail exchanger for those
>sites, then mail from foo.com to bar.org need not traverse the
>Internet. (for example)

Minority case: you've smart-hosted to their MX, and v-v.  That
means I can reach all of about 50 sites (of >20,000), and not
necessarily all of those 50 sites could reach me.

Whoopie.  And besides, that's the paid link!

>If "foo.com" and "bar.org" have a UUCP link between them, each
>can directly route mail to the other; it is unnecessary for
>either site to have an entry in the published UUCP maps. (as
>another example which demonstrates the errors in statements 1
>and 2 above)

So another 6 sites (of 19,950+) can reach me.  Whoopie again.

Wow.  A whole .2 percent of the non-Internet part of the net
can reach me without going thru the Internet.  And .03% doesn't
have to go over the paid link.

I'm not impressed with the efficacy of this solution.

>>    3) You can't participate in local networks properly.

>Wrong. see above.

Are not.  Unless there's a (probably automated) mechanism for
sending out local network maps.

>>If I did that, sending a piece of mail to the guy down the street
>>would cost money to the metered site, not to mention travel an
>>extra 500 miles.

>A conclusion based on erroneous assumptions.

Nope.
--
Chris Lewis; [e-mail]; Phone: Canada 613 832-0541
Psroff 3.0 info: [e-mail]
Ferret list: [e-mail]