Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.mail.uucp Subject: Re: More routing question information Message-ID: Date: 2 Jan 91 23:16:12 GMT References: <1990Dec29.182422.8788@kithrup.COM> <1990Dec30.194331.16965@vmp.com> <116623@uunet.UU.NET> <1991Jan01.085110.10170@chinet.chi.il.us> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 94 Nntp-Posting-Host: teachk In-reply-to: les@chinet.chi.il.us's message of 1 Jan 91 08:51:10 GMT On 1 Jan 91 08:51:10 GMT, les@chinet.chi.il.us (Leslie Mikesell) said: les> In article <116623@uunet.UU.NET> revell@uunet.uu.net (James R les> Revell Jr) writes: revell> The problem is that you're now using the internet solely as a revell> transmit medium. That is, neither source nor destination is on revell> the internet. Strictly speaking, this is a internet no no. You revell> might want to reconsider use of such routes. les> And just exactly what is supposed to happen to mail that is sent from les> a uucp site using the DNS-registered addresses for another uucp site? Well, if this is a pure UUCP site its MTA is given something like a!b!c!d!e.f.g!u as destination; There is no reason to assume that any of these is DNS registered, indeed for a pure UUCP site the DNS does not exist. If it is a dumb MTA, the UUCP maps do not exist either, and it just executes something like uux ... "a!rmail 'b!c!d!e.f.g!u'" ... which will fail if 'a' is not a neighbour. Or if it is an "intelligent" MTA, it has maps, and discovers that the site called 'e.f.g' which has a neighbour called 'e' which has a neighbour called 'c' which has a neighbour called 'a' is really called 'z' (because such is its alias in the map) which can be reached more cheaply via 'x' and 'y', and spews out: uux ... "x!rmail 'y!z!u'" ... IMPORTANT NOTES: 1) a properly intelligent UUCP MTA (MUA if you are one fo those that believe that routing ought to be done at the MUA level) shall never, repeat NEVER, assume on its own that a host name with dots in it is on the Internet; it could be on Janet, or on a private TCP/IP network, or an X.400 address, or ...; 2) it should not necessarily assume either that the relative address given by a user is in fact a route, this whether the first hostname on the relative address is a neighbour or not; 3) note that 2) does not mean that "aggressive rerouting" is allowed -- here we are at the *source* site, and this is *routing*, not rerouting. Of course an intelligent UUCP MTA will have a switch to let the user specify a route instead of an address. Those that appear in the envelope of mail in transit are *always* routes, instead, and should be treated as such, and should only be touched to *prepend* to them. Just to insist on the latter point, which is often misunderstood by rabid rerouters: the only time one is allowed to touch a route in the envelope is the following; assume we get a route such as the a!b!c!d!e.f.g!u above. The only transformation allowed is something like uux ... "p!rmail q!a!b!c!d!e.f.g!u" ... if the MTA determines that the best way to get to 'a' from the local site is something like relaying via 'p' and 'q'. This is permissible even if 'a' is listed as a direct neighbour of the local site, because it *may* be cheaper or quicker to go via 'p!q' rather than directly, and this can only be decided locally at the moment of forwarding (for example the direct link to 'a' may be down for a day). One should normally refrain from programming an MTA to do so however, just in the interest of predictable path'ing. After all if people see in the maps that a site is a direct neighbour of 'a' and compute a route thru that site and 'a' based on that information, that ought to be based on the map-induced expectation that the direct 'a' links is the "best" route. If the site instead systematically forwards to 'a' thru an indirect link, that means that the maps are simply wrong and should be updated, so that other sites can also calculate as best the indirect route. les> Even if the machines share common uucp connections, there is no reason les> for anyone but the mx-er and forwarder to know what the DNS name means. Ahhh. We were speaking UUCP to UUCP. If a site can get mx records it *is* on the Internet, and it is thus a gateway between the Internet and the UUCPspace (do you like this better than USENET? :->). Different rules apply, also legal. An Internet site *can* use the Internet to send mail to a UUCP site, because the Internet is not being used solely as as a leg of a non-Internet to non-Internet path. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk