NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/mail/uucp/2048

Internet Message Format | 1992-11-11 | 19.3 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!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: 12 Nov 92 08:59:05 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Elegant Communications Inc., Ottawa, Canada
Lines: 465

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> [e-mail] (Chris Lewis) wrote:
>>In article <[e-mail]> [e-mail] (Bruce Lilly) writes:
>As you can see from the headers above, the Followup-To was set
>to news.admin.misc.  I neither made nor now make any implication
>about whose "fault" it was.  I overrode it, as I stated.

I think that this is a "feature" in my Pnews (trn 2.2) - I didn't do it
explicitly.  I have to investigate.

Sorry for the confusion.

>Perhaps I'm mistaken, but I believe that the point of
>Followup-to is to place the follow-up(s) in one specific newsgroup,
>rather than to perpetuate the cross-posting. In any event,
>that's what happens using trn; the follow-up ended up with a
>single Newsgroups header entry of "news.admin.misc".
>I substituted what I felt to be the most appropriate newsgroup,
>viz. comp.mail.uucp. It wasn't an oversight on my part; I did it
>intentionally. If you think I did something wrong, please let me
>know. (perhaps via email or in news.software.readers)

The idea usually is that if there's no Followup-to line,
you add one and leave the Newsgroup line alone.  Then everybody
who saw the posting you're following up to, will see yours too,
and have the opportunity to "follow" it back into the group
that you've added the Followup-to for.  Given my (rather bogus)
Followup-to, it would have been best to reconstruct the original
Newsgroup line then add the Followup-to.  Otherwise, people
who saw the earlier stuff would think the thread simply died...

>Enough administrivia.

Yes.

>>>Pathalias will generate a ``backlink'' even if one half of the
>>>link is not explicitly listed in the maps.

>>pathalias will indeed generate a backlink, but a backlink with
>>cost of DEAD.  Even if the forward link isn't marked terminal.

I've been corrected (thank you).  The implicit backlink is 100*DEAD.

>>Long ago pathalias considered each link bidirectional at the same
>>cost, but the versions that you need to operate with the current
>>generation of maps do not do this.

>>If you don't believe me, try it.  You'll want to play with the -l
>>and -c options to see the costs.
>
>I believe you--I know what pathalias does.  But I don't really
>``want to play with the [...] -c option'' as the internal
>calculations used by pathalias to select the least ``cost'' path
>are irrelevant...

On the contrary, they're *entirely* relevant.  Because that's
what pathalias uses to calculate the routes.  The goal is to
make the backlink as high a cost as possible, because there
will *always* be at least an implicit backlink if the forward link
is mentioned in the maps at all.  (hold your "shouldn't be in
the maps at all" until later...)

>>Here is a simple test:

>>    foo        uunet
>>    uunet    ecicrl
>>    boo        ecicrl

>>No explicit backlink from ecicrl to uunet.  (I should point out that
>>I do *not* have a link to uunet, private or otherwise)

>>Here is the output of "pathalias -c -l boo" (print costs, "local site"
>>is "boo"):

>>    0    boo    %s
>>    4000    ecicrl    ecicrl!%s
>>    100000000    uunet    ecicrl!uunet!%s
>>    100000000    foo    ecicrl!uunet!foo!%s

>And there it is: a path even though the link was not explicitly
>declared.  Without the "-c" option to pathalias, it looks just
>like any other path. With the given input, the only way to get
>from "boo" to "uunet" is via "ecicrl". Patahlias will generate
>such a path whether or not the "ecicrl"->"uunet" link is declared:

I chose the input merely to show what the costs were.  Because it's
obvious that there'd be no other possible link from boo to foo than
thru the implicit backlink.  If you're running with a set of maps
this small, of *course* that backlink will be used.  But in the
real case, when you're running with at least a piece of the real
maps this is unlikely.  You'd only be caught carrying email for people
who have no other advertised route whatsoever with the outside world.
This did happen to me.  A single site not a member of the
domain park.  Not even directly connected to me.  I was able to
fix things for them.  On the other hand, if I'd explicitly declared
the link, probably even DEAD, I'd have been carrying much more.

>echo "foo\\tuunet\\nuunet\\tecicrl\\nboo\\tecicrl\\necicrl\\tuunet(DEAD)" | pathalias -l boo
>
>boo    %s
>ecicrl    ecicrl!%s
>uunet    ecicrl!uunet!%s
>foo    ecicrl!uunet!foo!%s

>Voila! Exactly the same paths. (the ``costs'' used by pathalias in
>its internal calculations are irrelevant)

Nope.  Try this:

    foo        uunet
    uunet    ecicrl
    boo        ecicrl
    ecicrl    a(DEAD)
    a    b(DEAD)
    b    uunet(DEAD)

the path from boo to uunet is ecicrl!a!b!uunet.  If you add uunet(DEAD)
to ecicrl's entry the route becomes ecicrl!uunet.  It preferred a
thrice-dead path to the implicit backlink.  The undead lives! ;-)

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.

The costs are relevant.

If, as I do, you have several other machines listed in your map entry, this
becomes particularly critical.  In my case I have several (free)
routes to long-haul links, but my service provider is so good,
and the company pays for it (to obtain good turnaround for business
purposes), I choose to have all stuff directly addressed to me go thru
the paid link.  On the other hand, I have several other machines that
will route through me (because they have no alternate route) to the
free (but slower) long-haul links.


>>>A backlink may indicate other problems with the maps, e.g. a
>>>site whose map entry has not been updated when another site
>>>mentioned in its map has been removed from service, or the link
>>>disconnected.

>>This is irrelevant to this scenario.  The scenario is that
>>you are marked terminal to your email service, and you don't
>>advertise the backlink at all.

>Allow me to clarify (real examples from (reasonably) current
>maps):

[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.
    - how can we tell?  By bounces.  A priori analysis
      is pointless.
    - can we believe ...!pitt!sir-alan!devon!...?  Are
      you being asked to?  If pathalias chooses
      to route that way (does it?) you'll either get
      a bounce or it'll work and maybe somebody will
      get mad and fix the problem by marking pitt->sir-alan
      terminal...
    - where is ispin?  Do you think pathalias cares?
      If the link is legitimate, does it matter?

Actually, by my reading of the maps, the only likely bogus link
is util20 because its map entry is 1989.  The others are 1992,
and are likely to be up to date.  There's probably nothing
unusual about it.  devon and sir-alan are participating in
exactly the same scenario I've proposed - devon->sir-alan is
terminal, and no specified backlink - the costs imply that
it's a long distance link.  This is reasonable.  Pitt?
I dunno.  DAILY is fairly high - could be the same intent as
the devon/sir-alan situation.  Frankly, it could as easily
be something reasonably carefully crafted to funnel stuff
to sir-alan via long-haul links, but to *tend* to prevent the
links being used as intermediate hops.

Let's say the backlinks are bogus.  Aside from the fact
that implicit backlinks are more expensive, and pathalias *might*
route differently, routing might just turn out to use them anyways.  How
are you going to find out?  By something bouncing - pathalias
certainly isn't going to try to tell you that it "looks suspicious".
DEAD isn't likely to help - in fact, it can only make routing thru
these more likely.  What will your response be - DEAD or not?
Send mail to the postmasters asking them to clarify the situation
and fix their maps.  Explicit DEAD makes no difference - except
making pathalias slightly more likely to *use* the explicit DEAD
links.

A priori guessing is pointless.  Pathalias certainly doesn't
try.  After the bounce it makes no difference - the link is busted
DEAD or not.  DEMAND or not.

>>Furthermore, explicitly marking the backlink DEAD doesn't help
>>if somewhere else there's a cheaper cost for the backlink.

>Ditto for leaving the link out of your map entry. The *only*
>difference between a missing link (no pun intended)
>and a link explicitly delared with a symbolic ``cost'' of DEAD
>is that one can safely assume that the presence of the latter is
>due to somebody intentionally putting it there. In the case of a
>missing link, one does not know whether the corresponding
>reverse link which is declared is a mistake, or whether some
>part of the map(s) is missing, or whether the asymmetry is due
>to an oversight in either failing to add to the maps a link that
>exists or a failure to remove from the maps a link that is no
>longer valid. Indeed, the asymmetry is a pointer to a possible
>error in the maps.

All is entirely true, but the only way you find out about this
is when you get a bounce - *that* is what tells you there's
an error.  You don't have to do any deducting or inducting
or anything else - the bounce means it's bogus.  DEAD doesn't
help pathalias at all, and the bounce is all *you* need to know.

>To paraphrase you:
>Furthermore, explicitly marking the backlink DEAD doesn't hurt.
>[ the paths generated are precisely the same ]

As I noted before, I got corrected.  An implicit backlink
is 100 times higher cost than DEAD.  So the paths aren't
neccessarily the same.

>>    dead {machinea!machineb}

>>in your local map override file - you're not allowed to do
>>this in the public maps (at least, last time we tried), so
>>you're screwed.

>[ordinarily, I'd say go look at d.AProject, but it's a small file...]

Yes I know.  You'd think that using the maps since *before* pathalias
and the UUCP Mapping Project (yes, there were maps before then.
And there was a different, very slow, program to generate paths),
and having written and distributed map unpacking software since
1986 would tend to make sure I knew.

I should have been clearer.  You aren't allowed to put "dead{}"
entries in individual site maps.

Mel Pleasant has distributed a program that many (most?  all?)
of the coordinators use to automatically validate map submissions.
It is *extremely* picky.

In 1988/9 one of our machines went down for an extended period of
time and we tried to "reserve" the name by doing a dead on it.
[In retrospect, this was silly.] Our local map coordinator's daemon
bounced it right back.  I've sent off a test to our new
coordinator and we'll see very shortly what it has to say.

>zcat ~uucp/uumap/d.AProject.Z

You mean you're not using unpackmaps?  Tsk tsk.  You'd say:

    uuwhere -r d.AProject

;-)

>[Actually, I'm surprised d.AProject is so small; surely there
>are many more known bad or unreliable paths.]

It's never been very big.  With latencies up into the multiple-months,
it's not that useful.  It's intended for the maintainers to "fix"
major bogosities that slipped thru audit (however much they do).
Ie: Australia decides to route everything through a machine nobody
has ever heard of, and actually doesn't exist...  Back in the
old days, you should have seen some of the routing.  We saw
routes that were from one part of the SF bay area to another
via Korea, Japan and Europe.

>>>If the link in fact exists, it should be listed in the maps.

>Consider for a moment why the UUCP maps, pathalias, smail2.5,
>etc. exist in the first place.  Back in the bad old days, it was
>frequently necessary to generate a path by hand. This, of
>course, was prone to typographical errors and was generally a
>pain in the neck (among other places). Another method often
>used, and equally unreliable, was replying along usenet news
>Path header paths. Thanks to the UUCP Mapping Project and Peter
>Honeyman (pathalias' author) we now have a much easier-to-use
>method of generating (usually) reliable paths.

>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.

>>Mentioning a link in the maps should be considered an open
>>advertisement for others to use it unless explicitly marked DEAD
>>(or terminal, but that's giving permission to use it to get
>>to the other site, just *not* beyond it).  Aside from issues of
>>unreasonably high volume (eg: MBAS usage), you can have no complaint
>>if someone automatically pathalias-routes through you.  Your
>>only recourse is to get the map entries fixed.

>possible recourse(s) if somebody sends mail to your site,
>intended for delivery to a site to which you refuse to deliver:
>1)    bounce the mail with a note explaining that mail cannot
>    be delivered via your system.
>2)    drop the mail on the floor
>3)    reroute via a less-objectionable route if one exists
>    (else use option 1 or 2)

I've mucked smail 2.5 to do (1) and (2)...  The problem being,
of course, that in at least some of these cases you've already
paid for the transmission, and your "recourse" ain't.

>>There's absolutely no reason to explicitly advertise a link that
>>you don't want people to traverse.

>Reason #1: as a sanity check against the reverse link.  Q.E.D.

Nope.  It doesn't prevent pathalias from routing thru it.  In fact
it may make it more likely.  If the reverse link gets used, DEAD
doesn't help, you gotta fix your (or somebody else's) map anyways.

>>Nope.  You can't override a "terminal".  You have to remove it.
>>Try it out.

>foo    uunet
>uunet    ecicrl
>boo    ecicrl
>ecicrl    <uunet>(DEAD)

>So: "foo" should be unreachable from boo, n'est ce pas?

[It is reachable]

>but apparently not prohibited... [Looks like we were both wrong
>about that]

With -c, you see it's the same cost as an implicit backlink.  And
since there's no alternate routes...  This isn't surprising.

>foo    uunet
>uunet    ecicrl
>boo    ecicrl
>ecicrl    <uunet>(DEAD)
>delete {ecicrl!uunet}
>ecicrl    uunet
>ecicrl    far
>far    uunet

[produces:]

>boo    %s
>ecicrl    ecicrl!%s
>far    ecicrl!far!%s
>uunet    ecicrl!uunet!%s
>foo    ecicrl!uunet!foo!%s

>Looks like a "delete" directive followed by a redeclaration
>(perhaps in a local input file) suffices.

The "ecicrl!uunet" has to be in a local input or it defeats the purpose.
If it's published, the DEAD and delete are no-ops, and you've just opened
the link all the way.

If you can get away with deletes in the maps, you don't need
the "ecicrl <uunet>(DEAD)" at all.

>My point: smail, pathalias etc. are only useful if the input to
>pathalias, viz. the UUCP maps, accurately reflect reality.
>Missing information, outdated information, and deliberately
>distorted (dis-)infomation all contribute to making these
>programs less useful.

DEAD doesn't help, and my proposal isn't dis-information.  What
then?

>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.
It does recommend that you join get a domain and join the UUCP zone,
which puts you in the d.* files, for the explicit reason that you
won't have to register other machines inside your domain.  HOWEVER,
the README is grossly out of date.  The d.* files (except for
d.AProject and d.Top) are NOT USED ANYMORE.  The UUCP zone is
effectively in the u.<country>.? files (ie: u.can.1 as opposed to
u.can.on.1).  Ie: "get a domain, and put your domain in the zone
files".  This is *not* being out of the UUCP maps at all.

I suggest you go read the Email Software Survey FAQ - I can
quote authorities with the best of em... ;-)

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.
    2) every bit of mail to you *must* traverse the Internet.
       Otherwise, nobody'll know where your MX points.
    3) You can't participate in local networks properly.

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.

Now, if you're a 100% leaf, so your only link is to the paid site,
yeah, this'll work.  But I don't operate that way.  And many
others don't wish to either.

>If one is concerned about misuse of one's resources by ignorant
>or inconsiderate people, e.g. transfer of huge files via email,
>one should take appropriate action to curb that misuse; in the
>example given, one could enforce a message size limit
>(sendmail does that by default, and the limit is easily
>configured on a per-mailer basis).

This doesn't help if you've already received it via UUCP over
your metered link.  Your spool may already be blown.  And it's
already cost you bux.

>Feeding garbage into pathalias (including by omission) doesn't
>solve any problems; it only creates other problems.

To paraphrase, "where's the garbage?"
--
Chris Lewis; [e-mail]; Phone: Canada 613 832-0541
Psroff 3.0 info: [e-mail]
Ferret list: [e-mail]