Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!cheops.cis.ohio-state.edu!karl From: karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) Newsgroups: comp.mail.misc Subject: Re: sigh (was Re: Short-circuiting a route) Message-ID: Date: 17 Jul 89 21:14:45 GMT References: <562@daitc.daitc.mil> <12167@polyslo.CalPoly.EDU> <1888@prune.bbn.com> <423@cwjcc.CWRU.Edu> <425@cwjcc.CWRU.Edu> <426 Sender: news@tut.cis.ohio-state.edu Organization: Ohio State Computer Science Lines: 84 In-reply-to: edguer@alpha.ces.cwru.edu's message of 14 Jul 89 22:38:41 GMT 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]).