Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!nirvo!kdg
From: kdg@nirvo.UUCP (Kurt Gollhardt)
Newsgroups: comp.mail.misc
Subject: Re: sigh (was Re: Short-circuiting a route)
Summary: Bang paths != source routes
Message-ID: <461@nirvo.UUCP>
Date: 18 Jul 89 01:45:36 GMT
References: <562@daitc.daitc.mil> <12167@polyslo.CalPoly.EDU> <VIXIE.89Jul5150330@bacchus.pa.dec.com> <1888@prune.bbn.com> <423@cwjcc.CWRU.Edu> <KARL.89Jul13210438@dinosaur.cis.ohio-state.edu> <12187@s.ms.uky.edu>
Reply-To: kdg@nirvo.UUCP (Kurt Gollhardt)
Organization: Nirvonics Inc., Plainfield, NJ
Lines: 63

Here's my .02 on bang paths as source routes:

In preface, let me say that I think any way in which rfc822 et al. can be
applied to the uucp world is "a good thing" (as long as it's correct and
feasible).  Thinking of bang paths as source routes and uucp maps as MX
records is, perhaps, a good starting point for thinking about some of the
issues; however, there are some problems with these equivalences which must
be kept in mind, and which may even make them impossible.

As I see it, there are two fundamental problems with bang paths which make
them definitely distinct from source routes:

1) Bang paths are not an explicit source routing syntax.

   While bang paths generated by the user at the source, are IMHO (intended
   as) source routes, an intermediate site along the path can't know whether
   a bang path it sees was entered by the user or generated by software.

   For instance, smail 2.5 will put out bang paths for all destinations, even
   for FQDNs (at least, as it's configured at my site).  The bang path put out
   by smail *is* intended (by smail) as a route specification, but it was not
   (necessarily) specified by the user as such, so it should not be considered
   gospel.  On the other hand, smail *does* leave the original form of the
   address in the To: line; unless, of course, the message had an (arbitrary)
   To: line in it, which smail then uses instead.

   It seems to me that To: lines can't be trusted (or, at least, expected;
   some mailers don't even put them on), which leaves the concatenation of the
   From_ envelope and the rmail args.  But the latter will always be a bang
   path, so you can't tell if the original user gave !'s or @'s.

2) Nodes in a bang path are not absolute, unique, names.

   In an internet source route, each system named un-ambiguously refers to a
   specific site.  In the uucp world, there may be two (or many) systems named
   athena, or hermes, or what-have-you.

   An internet source route means send this message from *THIS* system via
   *THAT* system to *THIS OTHER* system.  A uucp bang path, if interpreted as
   a source route, would mean: send this message from this system via *SOME*
   system named so-and-so to *SOME* system named such-and-such; in the world
   of the uucp maps, this could be interpreted uniquely, but the world of the
   maps is not the real world; there are systems out there which aren't on the
   maps, and they have to be considered, *especially* in the context of source
   routes.

Those, I think, are the (only?) 2 points where bang paths cannot be mapped to
the internet source route model.  This means that in order to apply the
internet routing model to uucp, one of two things must happen.  Either the
above two "problems" must be "fixed", or the model must be modified (for use in
the uucp world) to take these differences into account.  The latter is what
rfc976 attempts to address, in general, but it doesn't cover this particular
issue very much.

Of these two items, I think only the first one has any hope of changing in the
near future; perhaps through stricter handling of To:, or perhaps through a new
header such as Route-Via:.

-- 
  ==============                                          ==============
  #  Kurt Gollhardt                 Nirvonics, Inc. -- Plainfield, NJ  #
  #  ...!rutgers!nirvo!kdg            Software Design and Consulting   #
  ==============                                          ==============