Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!bloom-beacon!mit-hermes!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.mail.uucp,comp.mail.misc
Subject: dynamic routing for UUCP mail
Message-ID: <915@bsu-cs.UUCP>
Date: Sun, 2-Aug-87 15:15:31 EDT
Article-I.D.: bsu-cs.915
Posted: Sun Aug  2 15:15:31 1987
Date-Received: Tue, 4-Aug-87 00:48:23 EDT
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 84
Summary: UUCP mail could be dynamically routed/rerouted; is this practical?
Xref: mnetor comp.mail.uucp:737 comp.mail.misc:453

Currently, UUCP mail routing has these possibilities:

o    The sending site (the person or the software) creates a route, and that
     route is adhered to by intermediate sites
o    Intermediate sites can choose to reroute (using smail's rerouting
     options) either only if the first host in the route is not recognized,
     or unconditionally

DISADVANTAGE:  Typically, UUCP sends the message to a complete route
when it leaves the site.  In general, following smail suggestions,
intermediate sites will not do any rerouting except when for some
reason they do not recognize the first host in the route.  Thus
intermediate sites will not try to improve the route because they
cannot know whether the user wants them to reroute the message or not.

Even if the message left the originating site without a complete route,
the very next site will either reject it (host not recognized) *or* use
smail to create a complete route -- so we are back to square one, where
a hard-coded route now exists and will be used by all other sites.

Now consider the following possibility for smail.  This assumes that all
UUCP sites are running smail (not currently true but feasible in the near
future)

o    The sending site finds the best route, of the form a!b!c!d!user,
     but simply sends the message to a!d!user

o    The forwarding site `a' now finds the best route; suppose it is 
     e!f!g!d!user (i.e. it could well be different from what the
     originating site calculated);  site `a' sends the message to
     e!d!user

o    If a forwarding site does not recognize the host in an address,
     it sends the message on to some other neighboring host that is
     believed to have a current pathalias database;  prior agreement
     would be needed to avoid loops

Each forwarding site thus receives a message with an address of the
form host!user, calculates the best route, but sends the message on
*without* including the entire route.

The result is that messages are dynamically routed, each host only
sending the message on in the correct general direction, without trying
to specify a full route.

However, if the user wishes to use a specific route, he or she simply
specifies the entire route.  When an intermediate site sees a route
rather than an address, i.e. one that includes more than one host name,
it does *not* recalculate the best route if at all possible but simply
sends the message to the next machine in the route.

ADVANTAGE:  Intermediate hosts can dynamically route messages using
their best current knowledge of their vicinity, but senders can still
choose to specify a complete route if they wish.

IMPLEMENTATION:  The change in smail would be quite simple:  Do all
routing/rerouting as usual, but just before handing outgoing messages
to uucp, check to see whether the incoming message was being sent to a
route (a!b!c!...!d!user) or an address (d!user).  If it was an address,
then strip everything between the first and last hosts in the
new route before invoking uucp.

The only obvious problem I see would be caused by the existence of
duplicate host names;  but since the UUCP Project apparently accepts
map entries for hosts with conflicting names, I think it's a safe bet
that this is not a significant problem.  If you are sending mail to a
site whose name duplicates that of another, you would simply have to
specify a complete route.

Another subtle point might be the handling of a destination host that
is not in the UUCP map.  Mail sent to x!y!user might be treated as
being sent to a route, even if the sender really wanted to simply make
sure x!y is used (x being in the maps) but with normal rerouting until
x is reached.  This could possibly be achieved by interpreting x+y!user
to mean:  treat x+y as a single host name unless you are x, in which
case send the message on to y!user.  (But pathalias lookups would still
be for ...x!y).  Again the change in smail should be simple.  We
would have to see if the presence of `+' confuses UUCP.

QUESTION:  Are there any unexpected pitfalls in this?  Would there be
some interaction with sendmail that would prevent incremental routing
like this?
-- 
Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi