Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!caip!sri-spam!gds
From: gds@sri-spam.ARPA (The lost Bostonian)
Newsgroups: net.news,net.news.adm,net.mail
Subject: Re: ihnp4 problems
Message-ID: <6618@sri-spam.ARPA>
Date: Thu, 28-Aug-86 21:20:46 EDT
Article-I.D.: sri-spam.6618
Posted: Thu Aug 28 21:20:46 1986
Date-Received: Fri, 29-Aug-86 01:19:32 EDT
References: <782@laidbak.UUCP> <41334@beno.seismo.CSS.GOV> <1727@ihlpa.UUCP> <6571@sri-spam.ARPA>
Organization: the Bay Area, for now
Lines: 24
Xref: mnetor net.news:1999 net.news.adm:670 net.mail:1069

I did some additional thinking and research about the problem.  There is
an acceptable rerouting scheme I failed to mention earlier -- path
optimization.  Example:

To: a!b!c!d!e!user

passes through a and b ok, arrives at c.  c has both d and e as
neighbors.  It is acceptable for c to send the mail direct to e.  If the
originating machine has tables that show c has links to d and e, it is
conceivable that a might rewrite the To: line to a!b!c!e!user, but
questionable that it should (after all, this is based on possibly old
data).  However, it is not OK for b to deliver to something like
f!g!e!user, because c!d!e is fully specified.  I believe this is the
problem we are discussing.

By the way, I read RFC 976 to see if it sheds any light on these
scenarios.  It makes no specific comments on whether a fully-specified
To: line should be rerouted, however To: lines with domain forms in them
can (and probably are) being rerouted.  I don't have a copy of smail,
but I am assuming that it works according to RFC 976.

[RFC 976 -- UUCP Mail Interchange Standard, written by Mark Horton]

--gregbo