chuqui@nsc.UUCP (Zonker T. Chuqui) (11/06/84)
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....brian@sdcc3.UUCP (Brian Kantor) (11/09/84)
> I'm starting to look seriously at doing some limited path optimizing in > sendmail. > 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... What I have decided to do (as soon as I have time [heh heh heh]) is to add path optimization to sendmail in this form: if the options line in .mailrc says noopt then do nothing if the address has a bang in it (farkle!wombat!plaid) then leave it alone. if the address is in internet format (brian@wombat) or in internet form with a domain that we can talk to directly (such as plaid@nsc.uucp), I will look it up in a routing table (built from uucpmaps, host tables, and holy water) and substitute the address that we think is the best path. if the address is in internet format for a domain where we don't know the host but we do know the domain server (such as gnu@raphael.sun.uucp) we will ship it to that domain server (in this case it would be addressed as ...ucbvax!sun!gnu@raphael). if the address is in internet format but we don't know the host (or domain & host if both are specified) then we'll bounce it back to the sender with some sort of chastizing message. For replies to news articles, which seem to account for about 1/2 of our off-site traffic, we will first do the above with the 'From:' line. If that does not resolve to a usable address, then we'll start looking at the rightmost site name in the 'From ' line and work leftwards until we find a site name we can get to with fewer hops, and send it that way. If that doesn't work, it will just be sent with the address originally provided. I haven't even started to design much of this. So don't ask for a copy of the code because I'm likely to get hit by a car before I get it done. Glad to discuss it with anyone, if they would like. From the lonely keyboard of: decvax\ brian@sdcsvax.arpa akgua >--- sdcsvax --- brian ucbvax/ Kantor@Nosc