Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ncr-sd!greg
From: greg@ncr-sd.UUCP
Newsgroups: comp.mail.misc
Subject: Re: routing in the user agent
Message-ID: <1758@ncr-sd.SanDiego.NCR.COM>
Date: Sun, 27-Sep-87 03:53:33 EDT
Article-I.D.: ncr-sd.1758
Posted: Sun Sep 27 03:53:33 1987
Date-Received: Sun, 27-Sep-87 22:01:26 EDT
References: <7333@e.ms.uky.edu> <1631@umix.cc.umich.edu>
Reply-To: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel)
Organization: NCR Corporation, Rancho Bernardo
Lines: 55

>In article <7333@e.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident
	E-mail Hack) writes:
>>  [discussing what he perceives as problems in Mush]
>>	1. It wants to do routing ... That feature can be turned
>>	   off, but still it doesn't belong in a User Agent.

To which the infamous Peter Honeyman (honey@citi.umich.edu), replies in
	article <1631@umix.cc.umich.edu>:
>the UA is precisely where routing belongs, where it can be as smart as
>you like since the user can inspect and modify the result.

I think you are both right and both wrong.  There are certainly some aspects
of generating a valid return address that belong in the user agent, including
inspecting the path that the the router proposes to use, but on the other hand,
I don't think that the user agent is the right place for making the actual
routing decisions.  That should be done by an agent of the system administrator
(or other management) as they are the ones that should have the final say in
allocating the resources.

Note that there are several issues here.  One is re-writing the destination
given by the user (or extracted from a header, or whatever) into a valid
address.  This would include tasks like taking a partially-qualified name and
changing it into a fully-qualified domain name, modifying a path relative to
somewhere else into a self-relative path, or converting a path into an address
(I know, it's not always possible to do, but a partial job would be better
than none).  This is clearly the job of a user agent.  Another job is the
delivery of the mail.  In most cases (Peter is an exception), the user doesn't
care how the mail is delivered, as long as it \is/ delivered.  This job is
better left to a delivery agent, that is, a router, that enforces the policy
decisions of management.  Another way of saying this is that the routing
decisions should be left to someone who knows more about the routes; this
person is almost \never/ the user.

What I would like to see would be some way of capturing the routing descisions
(not only local decisions, but also considerations about other machines) in a
way that a user agent could make use of them, and then to be able to look at
the proposed routes and amend the addresses if desired.  And I would like the
descisions to be maintained centrally; that is, the user agents all use the
information in the same way.  And that it would be easy to change a things
around.  About the only way I see of doing this is for someone to implement
a library (or at least, a library interface) that does all of these things,
and make it so easy to use that all user agents \want/ to use it.  But do I
think this is possible?  Naaahhhh.....

Hmmm, this is getting a little long; I'd better quit before what I am trying
to say gets lost in the fog.  The basic point that I am trying to make is
that to say that routing (decisions/information) belongs \only/ in the user
agent or \only/ in the delivery agent is too narrow a position.  Routing is
a job that often can use some direction from the user, but on the other hand,
it is too (dangerous/costly/error-prone) to leave completely in the hands of
the average user.  Rather than argue about where the decision should be made,
I'd rather that we discuss how to distribute the functionality so that the
user can see what is intended for his mail and can influence the process.
-- 
-- Greg Noel, NCR Rancho Bernardo     Greg.Noel@SanDiego.NCR.COM