cjsv@cs.adfa.oz.au (Christopher JS Vance) (04/11/90)
We are an Internet site which has no uucp connections. We receive the pathalias maps in comp.mail.maps and have the IDA version of Sendmail 5.61 which would allow us to use these maps. Small-scale testing shows the feasibility of doing this. We were wondering whether the following was a reasonable approach, and if not, why not: 0) Definitions used below: FQIDN means a fully qualified domain name whose last component is a known top-level Internet domain. FQKNDN means a domain name whose last component is known, but where that component is not a registered Internet domain (e.g., bitnet, junet). 1) Any mail addressed to a FQIDN will be delivered via SMTP using MX records (or A if no MX). Any mail addressed to a FQKNDN will be handed to an appropriate gateway using SMTP or some other protocol. This much is obvious and not controversial. If a FQIDN site doesn't have MX or A records, the mail will bomb, but we have no intention to use pathalias to make this work. 2) Any mail to user@host.uucp or to host!path!user (where host is neither a FQIDN nor a FQKNDN) call for the use of pathalias at some site. 3) We don't have any UUCP links, so our first hop will have to be via SMTP (or within Australia, possibly SunIII, which is otherwise irrelevant to this article, but we're trying to avoid extra hops). 4) Given this fact, is it reasonable to claim a low cost connection to (the FQIDN of) those Internet hosts in d.Top which advertise routing to all of .uucp, run pathalias locally, and use those routes, making the first hop via SMTP? I assume the envelope will contain the generated route, but should we make any alterations to the headers inside the mail? If pathalias fails to find a match, or was not used, I'd expect to forward to one of these sites anyway, so I've merely saved some effort for them and done my best to select one of them is the best first hop for a particular destination. It also shares the load among them, rather than picking arbitrarily on one of them, as would otherwise be likely. But then, if our maps failed to generate a route to the site, it seems likely that these routing sites would also fail, neh? 5) Is it reasonable to optimise this by truncating routes through multiple FQIDN sites by routing straight to the last site in the generated path which has a FQIDN? This would be most easily done by claiming medium cost connections to all sites in the original pathalias input data which have a FQIDN, and running pathalias with the new data. Provided the pathalias data specifying connections from our site only mention the FQIDN (and not the shorter non-domain name), the pathalias output has only FQIDNs as first hops. The cost should be higher than the sites in step 4 because we don't know whether the FQIDN is a site directly on the Internet or whether there will be some routing via an MX record and some intermediate hops. 6) We could tighten this up by checking whether the FQIDN has MX or A records, giving a lower cost connection if there are A records, and not claiming the connection at all, if there are neither MX nor A records. This checking would stop us generating routes whose first hop will bomb, but requires a lot of DNS lookups the first time the data is assembled. Clearly the mechanism to be used should not keep checking such things each time we regenerate the pathalias database, but should remember the known goodies, so only new ones need be checked. Is there a good reason why the connection cost to a FQIDN site with A records should be any different from the cost in step 4? (Remember that we actually use MXs for delivery.) 7) Is there any reason, when the original path includes a FQIDN or a FQKNDN in a position other than at the beginning why we should not remove all path components before that FQIDN/FQKNDN, and start the whole process from there? By definition, such names are unambiguous anyway. The only disadvantage I can see here is if the previous non-domain site is the gateway for an unregisted FQIDN, but FQIDNs shouldn't be used before registration anyway, should they? 8) And if it all gets too hard, we'll just pass it all to our Australian gateway which will probably pass it all to uunet... Which is what happens now. -- Christopher