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

Text File | 1992-11-09 | 15.1 KB | 437 lines

Newsgroups: comp.mail.uucp
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!daver!hico2!sonyd1.Broadcast.Sony.COM!blilly.UUCP!bruce
From: [e-mail] (Bruce Lilly)
Subject: UUCP map entries (long) (Was Re: Any easy way to filter this type of UUCP traffic?)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Bruce Lilly
Date: Tue, 10 Nov 92 03:34:13 GMT
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Lines: 425

In article <[e-mail]> [e-mail] (Chris Lewis) wrote:
>In article <[e-mail]> [e-mail] (Bruce Lilly) writes:
>>[silly redirect overridden; this is a UUCP mail issue, not a
>>news administrative issue]
>
>[The original post was x-posted to news.admin.misc.  Which is somewhat
>silly, but certainly ain't my fault as you imply.

From: [e-mail] (Chris Lewis)
Newsgroups: news.admin.misc,comp.mail.uucp,comp.mail.sendmail,comp.mail.misc
Subject: Re: Any easy way to filter this type of UUCP traffic?
Message-ID: <[e-mail]>
Date: 7 Nov 92 06:39:56 GMT
References: <[e-mail]> <[e-mail]>
Followup-To: news.admin.misc
Organization: Elegant Communications Inc., Ottawa, Canada

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.

>However, you also removed comp.mail.sendmail and comp.mail.misc.
>Which makes it a good bet that the original poster doesn't see the
>replies.  So, I've done the *proper* thing of putting comp.mail.sendmail
>and comp.mail.misc back in, and then redirecting followups to
>comp.mail.uucp.  Which is what you (or I, I guess) shoulda done in the
>first place.]

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)

Enough administrivia.

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

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

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)

>>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):

# u.usa.in.1 created by [e-mail] on Tue Oct 27 07:09:15 EST 1992
[...]
#N    sir-alan
#S    SCO ODT 1.1
#O    Bloomington Public Access UNIX
#C    Michael L. Squires
#E    [e-mail] or [e-mail]
#T    [phone]
#P    546 N. Park Ridge Rd., Bloomington, IN 47408
#L    39 08 N / 86 31 W city
#R    "sir-alan" is a public access/BBS/archive site.  Dial-up at
#R    812 333-0450
#U
#W    Michael L. Squires ; Fri May 1 14:00:00 EST 1992
#
sir-alan    ispin(DAILY), util20(DAILY)

[...]
# u.usa.in.1 EOF

file {u.usa.pa.1}
#    start of u.usa.pa.1: Sat Sep 26 12:49:22 EDT 1992
#    maintained by [e-mail]
#    Please send all updates/new-entries
#    to: uucpmap@rutgers.{uucp,edu}

[...]
#N    devon.lns.pa.us, devon
#F    hobbes.cert.org, rutgers.edu
#S    LAN Tech 80486/33 PC; ESIX System V/386 Release 4.0.3a
#O    Personal System
#C    Paul Sutcliffe Jr.
#E    [e-mail]
#T    [phone]
#P    113 Hampden Drive, Mountville, PA, 17554-1838
#L    40 02 N / 76 18 W city
#R    registered in the US domain
#U    cbmvax dastari gizmonic ncoast sojurn vogon1
#W    [e-mail] (Paul Sutcliffe Jr.); Sun Sep 20 14:05:32 EDT 1992
#
devon    .devon.lns.pa.us
devon=    devon.lns.pa.us
#
devon    cai-usd(DAILY+FAST), <cbmvax>(EVENING+FAST), dastari(POLLED+FAST),
    fauxpa(POLLED+HIGH), frontinc(POLLED+HIGH), gizmonic(POLLED+FAST),
    mbitow(EVENING+HIGH), <ncoast>(EVENING+FAST), rehab1(DEAD),
    <rutgers>(EVENING+FAST), <sei>(EVENING+FAST), <sir-alan>(EVENING+FAST),
    sojurn(POLLED+FAST), sonata(DAILY+FAST), <util20>(POLLED+FAST),
    vogon1(POLLED+FAST)

[...]
#    end of u.usa.pa.1: Sat Sep 26 12:49:27 EDT 1992

file {u.usa.pa.2}
#    start of u.usa.pa.2: Sat Sep 26 12:49:35 EDT 1992
[...]

#N    pitt
#S    VAX-11/780;  4.3 BSD
#O    University of Pittsburgh, Computer Science Dept.
#C    Robert Hoffman
#E    pitt!hoffman
#T    [phone]
#P    306 Alumni Hall, Pittsburgh, PA 15260-3803
#L    40 26 N / 80 00 W city
#R
#U    amanue blue.cis.pitt.edu cuphub darth gatech grgzfla k3ive
#U    n3igw nss w2xo widener winfree yfn.ysu.edu
#W    pitt!hoffman (Bob Hoffman); Mon Feb 10 09:55:56 EST 1992
#
#    POLLED means they call us.
#
pitt    .cs.pitt.edu
pitt    .pitt.edu
pitt    =vax.cs.pitt.edu
pitt    allegra(DAILY), amanue(DAILY), bellcore(DAILY), bovik(POLLED),
    cisunx(DIRECT), cuphub(DAILY), darth(DIRECT), davykrz(POLLED),
    devel(DEMAND), dithridge(POLLED), dvr-pgh(POLLED),
    edinboro(DAILY), fdrpc(POLLED), gcc(POLLED), grgzfla(POLLED),
    holly(POLLED), investor(DIRECT), k3ive(POLLED), kd4nc(DAILY),
    n3cvl(POLLED), n3igw(DAILY), n8emr(DAILY), nelslab(DIRECT),
    neoucom(DAILY), nss(POLLED), psuvax1(DAILY), santiago(DEMAND),
    setech(POLLED), sir-alan(DAILY), taz(POLLED), telerama(POLLED),
    thumper(WEEKLY), trib1(POLLED), w2xo(DEMAND), washpenn(POLLED),
    willett(POLLED), winfree(DAILY), wmcs(DAILY), wqed(POLLED),
    wvucsb(DAILY), peakpa(DAILY)

[...]
#    end of u.usa.pa.2: Sat Sep 26 12:49:41 EDT 1992

file {u.usa.pa.3}
#    start of u.usa.pa.3: Sat Sep 26 12:49:47 EDT 1992
[...]

#N    util20
#S    Tandy 4000LX XENIX 386
#O    Utilities Engineering, GE Erie, PA
#C    Barry Capell, voice phone [phone]
#E    util20!barry
#T    [phone]
#P    GE Co., 2901 East Lake Road, Bldg. 4-1, Erie, PA 16531
#L    41 37 N / 80 08 W
#U
#W    M.L. Squires/B.H. Capell ;  Mon Aug 27 10:31:37 EST 1989
#
util20    =peng
#
util20    devon(DAILY), ncoast(DAILY), homer(POLLED), sir-alan(POLLED),
    util4(POLLED)

[...]
#    end of u.usa.pa.3: Sat Sep 26 12:49:51 EDT 1992

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

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

To paraphrase you:
Furthermore, explicitly marking the backlink DEAD doesn't hurt.
[ the paths generated are precisely 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...]

zcat ~uucp/uumap/d.AProject.Z

# d.AProject - [e-mail] - Wed Oct  7 16:21:36 EDT 1992
#
#  This is the UUCP Mapping Project's miscellaneous data file.  Here you'll
#  find temporary patches which, because of this file's name, will become part
#  of the input to pathalias.  In general, we will use this file to keep
#  pathalias from generating known bad or unreliable paths.
#
#
dead    {nrcaer}
dead    {phri}
dead    {samsung}
dead    {sun!ico}
dead    {uunet!cnix}
#
# end d.AProject

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

If you have a known unreliable path (perhaps because mail via
that path is intentionally dropped on the floor), perhaps you
should bring that known unreliable path to the attention of the
UUCP Mapping Project folks :-) (please read on before you do
so)

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

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

>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.  You can't override a "terminal".  You have to remove it.
>Try it out.

[ for clarity ]
echo "foo\\tuunet\\nuunet\\tecicrl\\nboo\\tecicrl\\necicrl\\t<uunet>(DEAD)"

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

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

echo "foo\\tuunet\\nuunet\\tecicrl\\nboo\\tecicrl\\necicrl\\t<uunet>(DEAD)" | pathalias -l boo

boo    %s
ecicrl    ecicrl!%s
uunet    ecicrl!uunet!%s
foo    ecicrl!uunet!foo!%s

Hmm... ``If the ``to'' host in a link is suppounded by angle
brackets, the link is considered \fIterminal\fP, and further
links beyond this one are heavily penalized...'' [Also sprach
Peter Honeyman in the pathalias man page]

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

Let's try again:

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

echo "foo\\tuunet\\nuunet\\tecicrl\\nboo\\tecicrl\\necicrl\\t<uunet>(DEAD)\\necicrl\\tfar\\nfar\\tuunet" | pathalias -l boo

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

and:

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

echo "foo\\tuunet\\nuunet\\tecicrl\\nboo\\tecicrl\\necicrl\\t<uunet>(DEAD)\\ndelete {ecicrl!uunet}\\necicrl\\tuunet\\necicrl\\tfar\\nfar\\tuunet"  | pathalias -l boo

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.

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.

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]

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

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

--
    Bruce Lilly    [news.admin should have been renamed
            "noise.adnauseum" a long time ago]
--
    Bruce Lilly        blilly![e-mail]
                    ...uunet!sonyusa!sonyd1!blilly!bruce