Xref: utzoo comp.mail.uucp:1606 comp.mail.headers:386 Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!gatech!purdue!decwrl!vixie From: vixie@decwrl.dec.com (Paul Vixie) Newsgroups: comp.mail.uucp,comp.mail.headers Subject: more on rutgers and rerouting Message-ID: <27@volition.dec.com> Date: 11 Aug 88 23:35:52 GMT References: <3674@palo-alto.DEC.COM><3732@palo-alto.DEC.COM> Organization: DEC Western Research Lab Lines: 44 In ron@topaz.rutgers.edu writes: # The first point that I would like to make is that as Associate Directory # here responsible for the expenditures on this machine, if you don't like the # way it runs, you can feel free to route your mail elsewhere. I'm going to assume that you havn't seen my "THANK YOU" article yet, Ron, because I agree with you completely and have already done so, netwide. # [...] The machine, being much more intelligent [...] than your average # random UUCP site, needs the facility to optimally route mail rather than # constraining it to follow the news paths [...]. I've explained several times in the last week, in these forums, that the place to avoid having mail travel over news paths is in the news user agents, not in gateway MTAs. If the mail were auto-routed at the source, or bumped up to Rutgers or another smart host for delivery, this problem would not exist. The netnews and RN installation documents explicitly recommend against hoping that a reverse news-path will get your reply delivered. I echo that recommendation. # The alternative to doing rerouting is to drop mail transiting through # Rutgers that isn't using a path that specifies the correct next hop (or # giving up on forwarding mail for people entirely such as ihnp4 has done). My complaint has nothing to do with finding a route to a next-hop that you do not directly speak to. Here, I'll say it again: Smart hosts are good things. A host that will find a route to the next hop in a path if it doesn't speak to it directly is a very nice host to have. What I object to is assuming that all hosts mentioned in the path which are also mentioned in the UUCP database are in fact hosts which are registered with the UUCP Project. This is simply not guaranteed. I object to finding a route to some host _other than_ the first one mentioned in a path, unless the first one mentioned in the path isn't reachable, in which case I can sit quietly while you search (starting from the left) for a host you _can_ reach. But stipping LHS hosts out of a path because you can find them in your UUCP database is not the right thing to do. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013