Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!cwjcc!alpha.ces.cwru.edu!edguer From: edguer@alpha.ces.cwru.edu (Aydin Edguer) Newsgroups: comp.mail.misc Subject: Re: sigh (was Re: Short-circuiting a route) Message-ID: <435@cwjcc.CWRU.Edu> Date: 20 Jul 89 15:02:44 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@cwjcc.CWRU.Edu Reply-To: edguer@alpha.ces.cwru.edu (Aydin Edguer) Organization: CWRU Dept of Computer Engineering and Science Lines: 98 In karl@cis.ohio-state.edu (Karl Kleinpaste) writes: >edguer@alpha.ces.cwru.edu writes: >> Hmm. Yes, the RFC974 algorithm may require a reroute of the first >> hop at each relay point along the path to the destination. Note, >> however this is only a reroute of THE FIRST HOP and thus would be >> the same as passive rerouting, not active (rabid) rerouting. >> RFC974 does not say to look down the list trying to find known >> hosts, it merely says to look at the first domain (host) in the >> path and try to reach it. > >If: > I have a connection to system aaaaa; > I advertise the connection to aaaaa as _very_ expensive so > that it doesn't get used by others as a relay much, > in fact, so expensive that my own paths file contains > the line > aaaaa bbbbb!ccccc!aaaaa!%s > I nonetheless expect and accept that the occasional piece of > mail bound for aaaaa should still go straight there, > because it's known to my Systems file... >Then: > An incoming piece of mail specifying > aaaaa!user > will have to be rerouted: > bbbbb!ccccc!aaaaa!user > because of the requirement, with pathalias as MX, that I > reroute the first hop, _before_ a direct attempt. > >This is morally incorrect. Hmm. You have a point, I just don't feel you are addressing it properly. I do not feel that the behavior you described is incorrect (morally or not). I maintain it did exactly what you wanted (or at least what you told it to do). If you wanted mail to go directly to aaaaa rather than bbbbb!ccccc!aaaaa when sent locally, then you should have either: a) Put the system name in brackets in your published map entry to indicate a "terminal link" and that further links are heavily penalized [see pathlias(1)]. Example: (DEMAND) This will cut down on pass through traffic. OR b) Publish "aaaaa (DEAD)" but put "aaaaa (DEMAND)" in your paths.local file. This will over-ride the higher cost entry when generating your local maps (or any of your friends maps). This will allow you to use it to route to other sites also. OR c) Put " (DEMAND)" only in your paths.local file and do not list the connection in your published map entry or list it as (DEAD). This will prevent anyone else (who does not know about it) from using the link, but will permit you to use it for direct mail, and help prevent you from generating paths though it. I would hold that resolving hosts in the L.sys file first and then trying to lookup unknown hosts in the pathalias database file (while not preferred) is OK. All you are doing is "fixing" a problem you created yourself (by not making your local map data better). >Making such a reroute into a requirement is Wrong. >(Making it optional is my business and no one else's, as the >link may be genuinely of high cost.) The requirement is only that your local map entries be correct. Thus it is entirely optional and within your control. If someone really WANTS the behavior you have implied is morally right, they CAN do it. If they do not want it, they can avoid it. >Whatever the reason, I want the connection to be available and >used on demand, without most people actually putting it to such use. >Say, just for my pals, who are "in the know" about the connection. If your local map information is correct then the connection is available on demand. The point is that MX records in SMTP land could cause the same problems. What if I wanted to send to mxed.host.domain directly? I can't within a mailer. The rules don't let me and the program won't let me (yes, I know I can telnet directly to the port. I can also directly put a piece of mail in the UUCP mail queue). But I could make a local change to the Domain Name Server (see RFC974)! I continue to see the parallels between "!" paths and source-routes as being very high. But enough beating a dead horse... To be honest, as with all analogies, pathalias records are only like MX records in some ways. One reason why I cannot say that pathalias records are MX records is that (as Karl has pointed out) they are never _specifically_ mentioned in the RFCs we have been discussing. I can only claim that they logically should be included (thanks to RFC976). The second reason why I cannot say that pathalias records are MX records is that in at least one major mailer (IDA-sendmail), MX records and pathalias paths are used in two different parts of the mailer. MX records are used during the delivery phase and do not affect the address. Pathalias records are used during the name resolution phase and do affect the address. None of the RFCs however contain anything to support active rerouting, (i.e. looking beyond the first hop in a chain), and I will continue to call active (rabid) rerouters, impolite, if not broken. Aydin Edguer +1 216 368 6123 edguer@alpha.ces.cwru.edu Department of Computer Engineering, Crawford Hall, Case Western Reserve Univ.