Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site umd5.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!cvl!umd5!zben From: zben@umd5.UUCP Newsgroups: net.mail Subject: Re: Mail routing -- problems showing up Message-ID: <708@umd5.UUCP> Date: Thu, 8-Aug-85 16:49:30 EDT Article-I.D.: umd5.708 Posted: Thu Aug 8 16:49:30 1985 Date-Received: Sun, 11-Aug-85 07:25:50 EDT References: <3018@nsc.UUCP> <2875@topaz.ARPA> <4787@mit-eddie.UUCP> <1022@sdcsvax.UUCP> <1431@peora.UUCP> Reply-To: zben@umd5.UUCP (Ben Cranston) Organization: U of Md, CSC, College Park, Md Lines: 54 Summary: You translate to intermediate net syntax, not final net syntax In article <1431@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >In article ? somebody writes: >> However, why couldn't these two be: >> berkeley!ihnp4!cbosgd!mark >> ihnp4!berkeley!mysite!myname >> >> The first is completely compatible with every UUCP site in the world. > >Because the latter example requires that "berkeley" know how to translate >"mysite!myname" into a routing or addressing format that is correct for >your network. This is especially hard when the destination site is not >on the network the UUCP gateway connects to -- i.e., when an intermediate >network has to be used to get to the final destination network. Maybe I'm missing something here, but it seems that in the case that an intermediate network is used for routing, the first gateway would translate the entire path into the syntax used for the INTERMEDIATE net, and the second gateway would translate FURTHER to get the format required by the third (final) network. As an example: Message starts out sent to: seismo!rlgvax!umcp-cs!umd5!umd2!umuc!luser Message transfered via UUCP until it gets to site umd5, where the remaining address string is: umd2!umuc!luser Umd5 realizes that its link to umd2 is ARPA Internet, and it rewrites the address to be: @umd2:luser@umuc When umd2 gets the message, it realizes that its link to umuc is BitNet, so address is rewritten as: luser@umuc Actually, that's not a good example. How about a UUCP-ARPA-UUCP one: Message starts out sent to: left1!left2!gatea!arp1!gateb!rite1!rite2!luser Message transfered via UUCP until it gets to site gatea, at which point the remaining address string is: arp1!gateb!rite1!rite2!luser gatea realizes that its link to arp1 is ARPA Internet, and so gatea rewrites to ARPA form: @arp1,@gateb,@rite1:luser@rite2 By the time gateb gets it, the address string has been reduced to the much simpler string: @rite1:luser@rite2 Realizing that its link to rite1 is UUCP, the gate back translates the remaining string to UUCP: rite1!rite2!luser And the rest is just UUCP again. Other than what kind of back-path this would generate, it looks like it would work... What am I missing here? -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA