🚀 go-pugleaf

In article <277A64CD.4C4B@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:

>In any case, the importance of (1), (2) and (5) is undeniable.  Thus I
>still object to the rewriting of RFC822 addresses into bang paths.

How would you handle the RFC822-legal path!user@domain syntax when
handing it to a uux-ed rmail?  It is almost certain to mean something
different to at least some of the uucp sites in the forwarding path
and it will certainly be destroyed by any site that chooses to prepend
its uucp name.

>I agree that it is usually possible to determine the original RFC822
>address given only a bang path a la RFC976.  Information loss is not
>the only issue, however.  In the address "bang!path!dom.ain!user", the
>_added_ information ("bang!path") is the problem, because it is very
>often an incomplete, pessimal or unreliable route.

Philosophically, I don't like any form of rerouting other than to the
specified "next-hop" host, but realistically it is probably better
to re-route to the right-most FQDN.  That should only fail under
a couple of circumstances: (1) the user really wanted the specified
routing for testing or avoiding a known problem with the usual routing.
(2) the end point has a name with a period in it but can't be found
by your routing technique.  The second problem could mostly be avoided
by forcing the address to be resolved before throwing away the specified
route (but this is not possible if a smart-host handles routing but
a secondary site is making the decision unless at least a list of top-level
domains is kept everywhere).  As for the first problem, it would be nice if
there were some syntax for specifying that you really want the given
route to be used so they could be handled differently than the paths
generated by newsreaders, etc..

Les Mikesell
  les@chinet.chi.il.us