Path: utzoo!attcan!uunet!husc6!rutgers!bpa!manta!brant
From: brant@manta.pha.pa.us (Brant Cheikes)
Newsgroups: comp.mail.uucp
Subject: some (hopefully) useful comments about mail routing
Message-ID: <433@manta.pha.pa.us>
Date: 1 Oct 88 23:40:58 GMT
Reply-To: brant@manta.pha.pa.us (Brant Cheikes)
Organization: Soul of the Gnu Machine, Philadelphia
Lines: 67

I am persuaded by the many arguments eschewing dynamic routing (to
adopt Mr. Vixie's distinction of dynamic vs. passive routing).
Despite Mr. Lear's promises, I just cannot imagine there is any way to
ensure that all rerouting sites have data accurate enough on which to
base address rewriting decisions.  (an aside: I hear that the new
smail under development will not support dynamic routing which, if
true, renders this discussion moot.  Can anyone speak knowledgeably to
this point?)

Yet if we are to eliminate dynamic routing, the following problems (at
least) need solutions:

1. Sites must be able to maintain private links.  Just omitting the
links from the published maps will not prevent manual routing thru
private links.  This problem should be addressed by smail, I believe.
When I raised this point about private links, Mr. Vixie pointed out
that shell scripts could be used to ensure that private links were
kept private.  That approach seems wrongheaded to me; why not an
extension to smail that would, for example, prevent mail from going
out over a link unless that mail originated from a site/user listed in
an authorization file?  Mail over unauthorized links should be bounced
back to the originator.

2. We have acknowledged that network topology is in constant flux.
Local changes are sometimes usefully supported by dynamic routing.
For example: the published map for manta lists a DIRECT link to
drexel.  Say I'm told that drexel will be down for a week, so I
locally update my map listing drexel as DEAD.  What do I do now with
incoming mail that is routed thru drexel (NB: not DESTINED for drexel,
merely routed thru it)?  It seems improper for me to hold such mail
for a week, when a different, functional path to the destination might
exist.  If I can't reroute, I must bounce.  Therefore, smail (again
the appropriate mechanism) needs to be extended to bounce mail routed
over dead links.

3. Absurdly long paths, usually created by replies to news articles.
I don't have anything to offer here; the newsreaders cannot simply be
fixed to no longer use return-path, and sometimes long paths may be
useful (for testing, perhaps?).  Yet return-paths often don't, causing
mail to bounce unnecessarily thus increasing net traffic.  What to do?

There are others I am sure, but that's enough for now.  I think that
we all could spend our time more productively on this newsgroup trying
to identify and solve the problems created by either the elimination
of dynamic routing or the application of same, rather than continuing
the unproductive debate of one versus the other.  Mr. Lear, I gather,
is working on the latter, for which he is to be commended and wished
lots of luck (he'll need all he can get, I suspect :-).

To start such discussion, we should have working definitions of the
principles that allow/disallow dynamic routing.  How about:

Principle of PASSIVE-ROUTING: "I only know reliably about my
neighbors, but if someone asks me to next-hop to non-neighbor site
baz, I have the right to assume that the baz in question is the baz in
the maps and route accordingly."

Principle of DYNAMIC-ROUTING: "I always know the correct path to the
destination, and if I don't, someone along the new path I generate
does and will reroute accordingly."

Now, how do we make them work?
-- 
Brant Cheikes
University of Pennsylvania
Department of Computer and Information Science
Internet: brant@manta.pha.pa.us, UUCP: bpa!manta!brant