Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!lll-lcc!ames!amdahl!krs
From: krs@amdahl.UUCP
Newsgroups: comp.mail.uucp
Subject: Re: Bug (feature?) in smail 2.3
Message-ID: <7250@amdahl.amdahl.com>
Date: Tue, 26-May-87 16:12:49 EDT
Article-I.D.: amdahl.7250
Posted: Tue May 26 16:12:49 1987
Date-Received: Wed, 27-May-87 05:03:24 EDT
References: <2088@cxsea.UUCP> <239@cbstr1.att.com>
Reply-To: krs@amdahl.UUCP (Kris Stephens)
Distribution: world
Organization: Amdahl Corp, Sunnyvale CA
Lines: 28

In article <239@cbstr1.att.com> Karl.Kleinpaste@cbstr1.att.com writes:
>blm@cxsea.UUCP writes:
>
>   [...]  So a path like user@machine would make it down to getpath and
>   have the cost filled in from the path file, but something like
>   machine!user wouldn't.
>
>That's supposed to be a feature.  I haven't decided whether it's
>actually a bug or not myself.  The idea is that, if somebody is going
>to the trouble to hand smail a real, live UUCP path, then smail isn't
>going to mess with it.

I think that's a fine idea except (oddly enough?) on replies to netnews
or other mail.  Replying down a receipt path of mail, let alone news,
often fails (for me) without the optimized path.  I assume that's because
site_a knows how to call site_b, which allows the call but either doesn't
know how to call site_a back or disallows the call.  The "fine idea"
comment I started with revolves around stuck nodes:  if our connection to
site_c isn't working and normal path resolution to site_d is via site_c,
I think it's pretty important that I can specify an alternate route around
the failing/choked node.

...Kris
-- 
Kristopher Stephens, | (408-746-6047) |          {whatever}!amdahl!krs
Amdahl Corporation   |                |    -or-  krs@amdahl.amdahl.com
     [The opinions expressed above are mine, solely, and do not    ]
     [necessarily reflect the opinions or policies of Amdahl Corp. ]