Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!gds
From: gds@sri-spam.istc.sri.com (The lost Bostonian)
Newsgroups: comp.mail.headers,comp.mail.uucp
Subject: Re: smail
Message-ID: <9825@sri-spam.istc.sri.com>
Date: Mon, 19-Jan-87 21:23:32 EST
Article-I.D.: sri-spam.9825
Posted: Mon Jan 19 21:23:32 1987
Date-Received: Tue, 20-Jan-87 18:54:09 EST
References: <14227@amdcad.UUCP> <3232@cbosgd.ATT.COM> <1442@blia.BLI.COM> <14308@amdcad.UUCP>
Organization: the Bay Area, for now
Lines: 25
Keywords: decwrl, UUCP novice
Xref: mnetor comp.mail.headers:93 comp.mail.uucp:153

Mark Horton posted a useful message on why autorouting should be
disabled with smail.  If you are doing autorouting and you don't fully
understand the dynamics of it, you should reread his message, then go
read the code that implements rerouting under smail.

I haven't looked at smail but I imagine the algorithms used for smail
rerouting are pathalias table driven.  A proper network routing
algorithm requires near real-time connectivity information so that costs
can be computed, links declared up/down, etc. with little interference
to any given message.  Pathalias table data could be months out of date,
not to mention just plain incorrect.  The uucp network is far too
autonomous for autorouting to be done, period.

Whether it is ok to optimize (cutting out intermediaries in the
uucp-path) is debatable.  I am inclined to say it is, because a site may
have specific reasons for using a shorter path (it may be cheaper in $$
to connect to a host further down the path).  I am opposed to mailers
that rewrite the path entirely.

Unfortunately I don't have the time or energy to write a mail router,
much as I'd like to.  I have a strong interest in communications routers
(I've worked with some on the Internet) and would like to approach the
problem in our heterogeneous environment.

--gregbo