🚀 go-pugleaf

In our ongoing saga of whether full Internet semantics should be
applied to !-paths as source routes, edguer@alpha.ces.cwru.edu writes:
>  You are quite correct.  You should try to deliver the mail directly to a.b 
>  or else return a failure, WITH THE EXCEPTION OF AN MX RECORD.
>  ...
>  Option three is to say that it should try to deliver mail to site "b"
>  using the information available to it, treating pathalias data as
>  just another form of MX record.  When looking up a name via the
>  Domain Name Service (DNS) we accept an MX record to be the equivalent of
>  a host record for ALL mail purposes (including source routing).
>  What this option asks us to do is treat a pathalias record as the equivalent
>  of a host record for mail purposes.

You left out an extremely important aspect of MX records and so forth,
which is the delivery algorithm, as specified in the RFCs, especially 974:
	Find the MX records.
	Delete those MX records which "don't qualify" (worse
		precedence than self, self-references, etc).
	Deliver to the best MX host:
		Find its A record.
		Open SMTP to it.
		Deliver.

Allowing for the following equivalences...

SMTP/DNS	UUCP/comp.mail.maps
--------	-------------------
A records	entries in Systems/L.sys files
MX records	pathalias data, usually as compiled into /usr/lib/uucp/paths

...I submit that the RFC delivery algorithm requires that active
reroute of the first hop must occur at each relay point along the path
to the destination.

[Ooo!  What'd he say? :-]

MX records are dealt with before A records.  This is _not_ optional.
Therefore, one _must_ reroute the first hop.  It is accepted that an
empty MX list may be found, in which case a one-entry MX list is
substituted consisting of the indicated remote system with a maximal
preference.  This means that either the first hop shows up in one's
paths file, or it must be present in one's Systems file, or both.  If
it is present in one's paths file, whatever path is there takes
precedence.  (It is a simple matter, of course, to ensure that one's
paths for direct UUCP neighbors are one hop long.)

   Notice, this does not imply that we 
   should short circuit (actively reroute) a source-route just because there 
   is an MX (pathalias) record for a host.  It should still go to each host
   along the route.

On the contrary, _if_ you wish to apply such strict Internet
semantics, this does indeed imply exactly that.  One _must_
accommodate the MX specifications before attempting anything else.  If
the MX specifications are wrong, then one is free to ignore them in
order to route around their errors (see 974's discussion of looping
problems and table inconsistencies, and the need to flush caches); but
one must accommodate them nonetheless.  The mail will still get to
each host specified in the path, but it may take quite a number of
extra hops to get there.

I argue that this is patently silly; that a _requirement_ to reroute
actively at each relay is consummately wrong, and hence is to be
ignored.  Therefore, I conclude that !-paths must not be source routes
if source routes require such mechanisms.

That is the real goal I have in mind - to demonstrate that Internet
standards do not apply to UUCP !-paths except in rather limited
fashions, such as those defined by (the extremely short) RFC976.  All
that 976 does is to say that an Internet source route <@a,@b:c@d>
should be converted to a!b!d!c (section 3.a, page 7).  It says little
more about these sorts of issues, and does not suggest that complete
source route semantics apply thereafter.

If !-paths are not source routes, then the RFCs do not apply; if they
do not apply, then I may do with them as I see fit.  Some see fit to
perform GRR; I see fit to perform DARR.  Neither is email-immoral, but
one can now discuss what might be preferable, in the absence of
documented standards.

--Karl

PS- GRR = General Rabid Rerouting; DARR = Domain Absolutist Rabid
Rerouting (i.e., strip to rightmost FQDN [fully-qualified domain name]).