Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!tut.cis.ohio-state.edu!cwjcc!charlie!edguer From: edguer@charlie.CES.CWRU.Edu (Aydin Edguer) Newsgroups: comp.mail.misc Subject: Re: sigh (was Re: Short-circuiting a route) Message-ID: <425@cwjcc.CWRU.Edu> Date: 14 Jul 89 15:57:39 GMT References: <562@daitc.daitc.mil> <12167@polyslo.CalPoly.EDU> <1888@prune.bbn.com> <423@cwjcc.CWRU.Edu> Sender: news@cwjcc.CWRU.Edu Reply-To: edguer@ces.cwru.edu (Aydin Edguer) Organization: CWRU Dept of Computer Engineering and Science, Cleveland, OH Lines: 78 In article karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes: >Aydin, I'll throw your own argument back at you: If you want to play >in the game, don't skip _some_ of the rules. Karl, I normally would defer to your excellent judgement but in this case, I think I must stand my ground. I do not think I skipped any rules. I admit there were rules I did not explicitly mention. >The rules for source routing are explicit in the syntactic definition >they must use. !-path routes do not constitute a source route. According to RFC822, you are correct. According to RFC822 however, there is no such thing as a "!" path. RFC822 (only) compliant mailers therefore would be unable to process even a "fully.qualified.domain!user" address. That is the reason I also listed RFC976, the UUCP mail specification. >If you hand me <@here,@there,@everywhere:user@elsewhere>, I'll >(probably) obey it. (Right after I clean up the mess I made by >tossing my cookies all over my desk, of course.) Admittedly ugly. Feel free to lose your lunch even if it is valid. >But if you want respect granted a source route... >...PRESENT IT TO ME AS A SOURCE ROUTE. >!-paths don't qualify. Bang paths do qualify in my opinion because of RFC976. RFC976 says that a gateway should change an RFC822 source route into an RFC976 bang path when sending to the next hop via UUCP. This means that if you receive a bang path via UUCP you may be receiving a valid RFC822 source route from another site that is following the rules. This is why I feel that to properly comply with the mail RFC's you should treat ALL bang paths as valid source routes. No active rerouting. The problem of doing a direct translation of a bang path back into an RFC822 source path that would satisfy your request is that RFC822 requires that all the hosts in the source route be fully qualified domain names! If this were not true I would hand you via NSFnet a valid RFC822 source route rather than a bang path. But I am not allowed to unless I validate each "domain" in the bang path. If you do still do not like the idea of a bang route as a source route then consider it in a different light. According to RFC822, anything to the left of the "@" symbol is defined to be local information. It should not be interpreted except at the "destination." If I give you a bang path via the Internet: b!c!d@a then "b!c!d" is local information to the site "a" (you). You should take then path, strip off your name and process the local information. As a first step you should transform it according to RFC976 back into: c!d@b Now there exists a local part "c!d" and a destination "b". Once again there is local information which you should not touch. You should attempt delivery as best you can to domain b. If you follow the rules (at least in my interpretation) you should treat a bang path as a source route. I see the problem as threefold. If all UUCP sites understood RFC822 notation then we could use bang paths as "this is the path I know, reroute as best you know", and RFC822 source routes as source routes. But not all UUCP sites understand "@". If there was a direct mapping from RFC976 to RFC822 then I would hand you an RFC822 source route instead of a bang path. But there is none and trying to mix notations is a bad idea. If there was a perfect set of maps that was always up to date, knew all private links (and when it was allowed to use them) and all internal hosts behind a UUCP gateway and what machines were down for repair or disposal then I would think rabid rerouters were a good idea. Unfortunately these three problems exist and so I feel that active rerouting is bad. I do agree with passive routing. Aydin Edguer +1 216 368 6123 edguer@alpha.ces.cwru.edu Department of Computer Engineering, Crawford Hall, Case Western Reserve Univ.