Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.7 9/23/84; site nsc.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!nsc!chuqui
From: chuqui@nsc.UUCP (Zonker T. Chuqui)
Newsgroups: net.mail
Subject: path optimizing in sendmail
Message-ID: <1836@nsc.UUCP>
Date: Tue, 6-Nov-84 05:50:51 EST
Article-I.D.: nsc.1836
Posted: Tue Nov  6 05:50:51 1984
Date-Received: Wed, 7-Nov-84 08:07:49 EST
Distribution: net
Organization: The Warlocks Cave, Western Annex
Lines: 54

I'm starting to look seriously at doing some limited path optimizing in
sendmail. At this point I'm only willing to deal with addressing that
doesn't have to deal with ambiguous addresses. I'm initially looking at
doing the following:

1) bang addresses take precedence, and are not optimized. This means that
anything with a bang isn't touched.

2) .UUCP domain addresses are optimized only if they aren't part of a
larger bang address.

The basic philosophy is this-- if the user sends me a bang address I will
send it his way, assuming he knows what he is doing. If he is sending me a
domain address he wants me to find the best way there. This means that 
nsc!ihnp4!foo isn't optimized, but nsc!foo@ihnp4.UUCP is. Something like
'nsc!ihnp4!laura@utzoo.UUCP' also isn't optimized because the bang take
priority-- I'm assuming that the sender wants ihnp4 to optimize the route,
either because ihnp4 knows of a different utzoo than me, or because the
sender knows that ihnp4 knows a better path than I do.

There are certain address cases that I don't think are appropriate to
handle under this, such as 'nsc!utzoo@ihnp4.UUCP!laura', for example. Any
address where the domain isn't the final resolvable address part is, as 
far as I can tell, illegal and should be aborted. If I can forward it with
bang syntax, I will, but I don't plan on resolving this myself-- I don't
see a good way of doing so.

This doesn't support domains other than .UUCP for now, but I think it could
be extended at a future time without too much trouble-- right now I'm still
not comfortable enough with the addressing ambiguities to play with it. 

One thing I'm looking at as a way of implementing this in a flexible format
is to implement something similar to shell backquotes in the .cf file to 
tell sendmail to call a specific program with an address as input and use
the output of the program as the new form. This could reduce the complexity
of sendmail files by allowing us to offload address rewriting into
specialized C program rather than in the .cf, which is inherently slow. I
can see creating a rewriting program (rather than rule) for .ARPA domains
that mails the program to the nearest ARPA site, for example, or using a
path generating program to reconcile subdomains by teaching them how to get
to .ATT, or .SUN, or wherever.

I'm interested in hearing what my approach may break out in the real world
before I get started, and any other comments you might have. My overriding
priorities is to not break existing software, at least not without knowing
what I'm doing, but I also don't want sendmail doing hidden optimization,
the user should be able to override it if he wants to...

chuq
-- 
From the Department of Bistromatics:                   Chuq Von Rospach
{cbosgd,decwrl,fortune,hplabs,ihnp4,seismo}!nsc!chuqui  nsc!chuqui@decwrl.ARPA

  I'd know those eyes from a million years away....